For really long running methods in EM loop

Hello,

My understanding is, if any of the callback handlers take
long time to
execute, they are going to block the event loop, till that
handler
finishes execution. Am i right?

So, I have a method which basically upon a fresh request
from the
client, connects to a external server for some stock data
and using
certain financial algorithms, plots a chart and calculates
certain
statistical parameters. Now, this can be a time taking
operation, so
originally i thought that, I will have seperate Drb process
doing this
and using Slave library
(http://groups.google.com/gr
oup/ruby-talk-google/browse_thread/thread/e6de9b7d9f9fb645)
i would connect the forked processs, with current process.
Now, forked
process will be running a EM loop essentially, Drb and Slave
library
are just for IPC.

Another thought was to make use of "EventMachine.defer(
operation,
callback )", so my first question is:
  * does making use of above function blocks the Event loop?
I guess
no, but please confirm.
  * Which approach would be better and more scalable?
scalable and fast .



-- 
gnufied
-----------
There was only one Road; that it was like a great river: its
springs
were at every doorstep, and every path was its tributary.
http://people.inxs
asia.com/~hemant
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk

On 3/5/07, hemant <gethemantgmail.com> wrote:
> Hello,
>
> My understanding is, if any of the callback handlers
take long time to
> execute, they are going to block the event loop, till
that handler
> finishes execution. Am i right?
>
> So, I have a method which basically upon a fresh
request from the
> client, connects to a external server for some stock
data and using
> certain financial algorithms, plots a chart and
calculates certain
> statistical parameters. Now, this can be a time taking
operation, so
> originally i thought that, I will have seperate Drb
process doing this
> and using Slave library
> (http://groups.google.com/gr
oup/ruby-talk-google/browse_thread/thread/e6de9b7d9f9fb645)
> i would connect the forked processs, with current
process. Now, forked
> process will be running a EM loop essentially, Drb and
Slave library
> are just for IPC.
>
> Another thought was to make use of
"EventMachine.defer( operation,
> callback )", so my first question is:
>   * does making use of above function blocks the Event
loop? I guess
> no, but please confirm.
>   * Which approach would be better and more scalable?
scalable and fast .
>

Just an update, my application doesn't connect to the
external server
upon a new request from the client, rather its always
connected to
this external server for fresh data.


-- 
gnufied
-----------
There was only one Road; that it was like a great river: its
springs
were at every doorstep, and every path was its tributary.
http://people.inxs
asia.com/~hemant
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk

DRb isn't async-safe (you're blocking while Ruby uses IPC to
send a
message to a stub in another process and get the result),
although if
your app is low-throughput you can "cheat" if
you're using localhost
IPC --- just make sure socket buffers don't fill up, or your
event
loop locks up hard.

That said: in a typical async application, an operation like
"connect
out to a remote server and get data" would be
integrated into the
event loop; the only socket calls you'd ever make would be
through the
evented API.

Unless your financial algorithms and plotting code take
hundreds of
milliseconds, this should scale perfectly, shouldn't it? If
they do
take a really long time, you have basically the same problem
as the
HTTPS accelerators do; you're CPU bound: event loops excel
at IO bound
apps, and threading excels at CPU bound apps.

What I'd have done in this situation is, I'd have a
synchronous worker
process and an evented front-end/dispatcher process; I'd
link the two
of them over a Unix domain socket and have them exchange
Marshalled
message objects. I wouldn't use DRb.

I keep saying this here, but DRb scares the crap out of me.
Am I
wrong? Is there an easy way to event it?

On 3/4/07, hemant <gethemantgmail.com> wrote:
> Hello,
>
> My understanding is, if any of the callback handlers
take long time to
> execute, they are going to block the event loop, till
that handler
> finishes execution. Am i right?
>
> So, I have a method which basically upon a fresh
request from the
> client, connects to a external server for some stock
data and using
> certain financial algorithms, plots a chart and
calculates certain
> statistical parameters. Now, this can be a time taking
operation, so
> originally i thought that, I will have seperate Drb
process doing this
> and using Slave library
> (http://groups.google.com/gr
oup/ruby-talk-google/browse_thread/thread/e6de9b7d9f9fb645)
> i would connect the forked processs, with current
process. Now, forked
> process will be running a EM loop essentially, Drb and
Slave library
> are just for IPC.
>
> Another thought was to make use of
"EventMachine.defer( operation,
> callback )", so my first question is:
>   * does making use of above function blocks the Event
loop? I guess
> no, but please confirm.
>   * Which approach would be better and more scalable?
scalable and fast .
>
>
>
> --
> gnufied
> -----------
> There was only one Road; that it was like a great
river: its springs
> were at every doorstep, and every path was its
tributary.
> http://people.inxs
asia.com/~hemant
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talkrubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk

On 3/5/07, Francis Cianfrocca <garbagecat10gmail.com> wrote:
> On 3/4/07, hemant <gethemantgmail.com> wrote:
> > Hello,
> >
> > My understanding is, if any of the callback
handlers take long time to
> > execute, they are going to block the event loop,
till that handler
> > finishes execution. Am i right?
> >
> > So, I have a method which basically upon a fresh
request from the
> > client, connects to a external server for some
stock data and using
> > certain financial algorithms, plots a chart and
calculates certain
> > statistical parameters. Now, this can be a time
taking operation, so
> > originally i thought that, I will have seperate
Drb process doing this
> > and using Slave library
> >
> (http://groups.google.com/gr
oup/ruby-talk-google/browse_thread/thread/e6de9b7d9f9fb645)
> > i would connect the forked processs, with current
process. Now, forked
> > process will be running a EM loop essentially, Drb
and Slave library
> > are just for IPC.
> >
> > Another thought was to make use of
"EventMachine.defer ( operation,
> > callback )", so my first question is:
> >   * does making use of above function blocks the
Event loop? I guess
> > no, but please confirm.
> >   * Which approach would be better and more
scalable? scalable and fast .
>
>
>
> Hi, Hemant. Yes, I remember your application.
EventMachine#defer uses a
> thread pool managed by EM. You need to be aware that
anything running in a
> #defer will need to be thread-safe with the rest of
your program. #defer
> handles all the thread joining, etc, and the block you
pass to #defer for
> execution on completion of the blocking operation will
run on the *main* EM
> thread, not the #defer thread. This is all documented
pretty carefully.
>
> For what you're trying to do, I would consider
Deferrable. I don't remember
> what protocol is used by your external server. If it's
HTTP, consider using
> EventMachine::Protocols::HttpClient, which is a fully
> event-compatible HTTP client. If a different protocol,
you can look in
> HttpClient to learn the pattern.
>
> I recently added a sugaring to Deferrable called a
"Future." Sorry, no docs
> yet, but it's supposed to be easier to understand and
use. It's supposed to
> remind you of the "futures" that appear in
some of the more recent
> functional languages. Alice, for example.
>

great, Francis. but my problem is that task is CPU-bound
intensive
too. so computing those statistical parameters and plotting
takes
sometime. So, while its doing this, rest of the EM loop
would be
blocked, and thats my main concern.

-- 
gnufied
-----------
There was only one Road; that it was like a great river: its
springs
were at every doorstep, and every path was its tributary.
http://people.inxs
asia.com/~hemant
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk

Francis will probably disagree, but you should get that
CPU-intensive
bit out of your EM process and away from your event loop; if
you wire
it up with evented IPC (on the EM side --- use whatever you
want on
the compute side), you'll get cleaner code and event loop
integration
for free.

On 3/4/07, hemant <gethemantgmail.com> wrote:
> On 3/5/07, Francis Cianfrocca <garbagecat10gmail.com> wrote:
> > On 3/4/07, hemant <gethemantgmail.com> wrote:
> > > Hello,
> > >
> > > My understanding is, if any of the callback
handlers take long time to
> > > execute, they are going to block the event
loop, till that handler
> > > finishes execution. Am i right?
> > >
> > > So, I have a method which basically upon a
fresh request from the
> > > client, connects to a external server for
some stock data and using
> > > certain financial algorithms, plots a chart
and calculates certain
> > > statistical parameters. Now, this can be a
time taking operation, so
> > > originally i thought that, I will have
seperate Drb process doing this
> > > and using Slave library
> > >
> > (http://groups.google.com/gr
oup/ruby-talk-google/browse_thread/thread/e6de9b7d9f9fb645)
> > > i would connect the forked processs, with
current process. Now, forked
> > > process will be running a EM loop
essentially, Drb and Slave library
> > > are just for IPC.
> > >
> > > Another thought was to make use of
"EventMachine.defer ( operation,
> > > callback )", so my first question is:
> > >   * does making use of above function blocks
the Event loop? I guess
> > > no, but please confirm.
> > >   * Which approach would be better and more
scalable? scalable and fast .
> >
> >
> >
> > Hi, Hemant. Yes, I remember your application.
EventMachine#defer uses a
> > thread pool managed by EM. You need to be aware
that anything running in a
> > #defer will need to be thread-safe with the rest
of your program. #defer
> > handles all the thread joining, etc, and the block
you pass to #defer for
> > execution on completion of the blocking operation
will run on the *main* EM
> > thread, not the #defer thread. This is all
documented pretty carefully.
> >
> > For what you're trying to do, I would consider
Deferrable. I don't remember
> > what protocol is used by your external server. If
it's HTTP, consider using
> > EventMachine::Protocols::HttpClient, which is a
fully
> > event-compatible HTTP client. If a different
protocol, you can look in
> > HttpClient to learn the pattern.
> >
> > I recently added a sugaring to Deferrable called a
"Future." Sorry, no docs
> > yet, but it's supposed to be easier to understand
and use. It's supposed to
> > remind you of the "futures" that appear
in some of the more recent
> > functional languages. Alice, for example.
> >
>
> great, Francis. but my problem is that task is
CPU-bound intensive
> too. so computing those statistical parameters and
plotting takes
> sometime. So, while its doing this, rest of the EM loop
would be
> blocked, and thats my main concern.
>
> --
> gnufied
> -----------
> There was only one Road; that it was like a great
river: its springs
> were at every doorstep, and every path was its
tributary.
> http://people.inxs
asia.com/~hemant
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talkrubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk

On 3/5/07, Thomas Ptacek <tqbfmatasano.com> wrote:
> Francis will probably disagree, but you should get that
CPU-intensive
> bit out of your EM process and away from your event
loop; if you wire
> it up with evented IPC (on the EM side --- use whatever
you want on
> the compute side), you'll get cleaner code and event
loop integration
> for free.
>
> On 3/4/07, hemant <gethemantgmail.com> wrote:
> > On 3/5/07, Francis Cianfrocca <garbagecat10gmail.com> wrote:
> > > On 3/4/07, hemant <gethemantgmail.com> wrote:
> > > > Hello,
> > > >
> > > > My understanding is, if any of the
callback handlers take long time to
> > > > execute, they are going to block the
event loop, till that handler
> > > > finishes execution. Am i right?
> > > >
> > > > So, I have a method which basically upon
a fresh request from the
> > > > client, connects to a external server
for some stock data and using
> > > > certain financial algorithms, plots a
chart and calculates certain
> > > > statistical parameters. Now, this can be
a time taking operation, so
> > > > originally i thought that, I will have
seperate Drb process doing this
> > > > and using Slave library
> > > >
> > > (http://groups.google.com/gr
oup/ruby-talk-google/browse_thread/thread/e6de9b7d9f9fb645)
> > > > i would connect the forked processs,
with current process. Now, forked
> > > > process will be running a EM loop
essentially, Drb and Slave library
> > > > are just for IPC.
> > > >
> > > > Another thought was to make use of
"EventMachine.defer ( operation,
> > > > callback )", so my first question
is:
> > > >   * does making use of above function
blocks the Event loop? I guess
> > > > no, but please confirm.
> > > >   * Which approach would be better and
more scalable? scalable and fast .
> > >
> > >
> > >
> > > Hi, Hemant. Yes, I remember your application.
EventMachine#defer uses a
> > > thread pool managed by EM. You need to be
aware that anything running in a
> > > #defer will need to be thread-safe with the
rest of your program. #defer
> > > handles all the thread joining, etc, and the
block you pass to #defer for
> > > execution on completion of the blocking
operation will run on the *main* EM
> > > thread, not the #defer thread. This is all
documented pretty carefully.
> > >
> > > For what you're trying to do, I would
consider Deferrable. I don't remember
> > > what protocol is used by your external
server. If it's HTTP, consider using
> > > EventMachine::Protocols::HttpClient, which is
a fully
> > > event-compatible HTTP client. If a different
protocol, you can look in
> > > HttpClient to learn the pattern.
> > >
> > > I recently added a sugaring to Deferrable
called a "Future." Sorry, no docs
> > > yet, but it's supposed to be easier to
understand and use. It's supposed to
> > > remind you of the "futures" that
appear in some of the more recent
> > > functional languages. Alice, for example.
> > >
> >
> > great, Francis. but my problem is that task is
CPU-bound intensive
> > too. so computing those statistical parameters and
plotting takes
> > sometime. So, while its doing this, rest of the EM
loop would be
> > blocked, and thats my main concern.

There is one more downside actually, I also must keep
refreshing some
frequently requested charts, so a add_periodic_charts.

And that frquently requested number goes into 100 charts
almost, and
that was the main reason for putting thought about having a
mutiple
process based archiecture.

-- 
gnufied
-----------
There was only one Road; that it was like a great river: its
springs
were at every doorstep, and every path was its tributary.
http://people.inxs
asia.com/~hemant
_______________________________________________
Eventmachine-talk mailing list
Eventmachine-talkrubyforge.org
http://rubyforge.org/mailman/listinfo/eventmachine-talk