Eventmachine talk - Mar 2007 - 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/group/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.inxsasia.com/~hemant

On 3/5/07, hemant <gethemant at gmail.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/group/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.inxsasia.com/~hemant

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 <gethemant at gmail.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/group/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.inxsasia.com/~hemant
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

On 3/4/07, hemant <gethemant at gmail.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/group/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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/7b24aae6/attachment.html

On 3/4/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> 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?


I''d add the point that heavy threading can work against you in a
CPU-bound
application too, if the thread scheduler is heavyweight. Ruby''s is
heavyweight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/88e6b4f0/attachment-0001.html

On 3/5/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
> On 3/4/07, hemant <gethemant at gmail.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/group/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.inxsasia.com/~hemant

On 3/4/07, hemant <gethemant at gmail.com> wrote:
>
>
> 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.
>
> -


is it possible to split your statistical processing up into small chunks
that can be chained together with Deferrable? You''re still binding the
CPU
but at least your network processing won''t stop for long periods of
time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/a8bbd778/attachment.html

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 <gethemant at gmail.com> wrote:
> On 3/5/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> > On 3/4/07, hemant <gethemant at gmail.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/group/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.inxsasia.com/~hemant
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

On 3/5/07, Thomas Ptacek <tqbf at matasano.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 <gethemant at gmail.com> wrote:
> > On 3/5/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> > > On 3/4/07, hemant <gethemant at gmail.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/group/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.inxsasia.com/~hemant