Eventmachine talk - Mar 2007 - using eventmachine from rails

I''ve got a need to use eventmachine in two different ways and use it
from a rails app.

1. Use eventmachine to do a non-blocking POST to a website.
2. Use eventmachine as a server that manages some client programs that connect
to it.  Have the rails app provide an interface to the client server.

I don''t suppose I can just stick something like this in a
controller/model file?  (And similar for the POST)

EventMachine::run {
  EventMachine::start_server "127.0.0.1", 8081, ClientServer
}

Any tips you can provide would be greatly helpful!  My rubyfu is still weak so
I''m drawing a blank here.

Thank you

I figured out an easy way to do a non-blocking post from rails.

`curl -d "parameterstring" http://site &`

But I''m still very curious about the second part, running a standalone
eventmachine server yet interacting with it from the rails app.

On Thu, 1 Mar 2007 08:09:09 -0700
James Robey <jrobey at stripemobile.com> wrote:
> I''ve got a need to use eventmachine in two different ways and use
it from a rails app.
>
> 1. Use eventmachine to do a non-blocking POST to a website.
> 2. Use eventmachine as a server that manages some client programs that
connect to it.  Have the rails app provide an interface to the client server.
>
> I don''t suppose I can just stick something like this in a
controller/model file?  (And similar for the POST)
>
> EventMachine::run {
>   EventMachine::start_server "127.0.0.1", 8081, ClientServer
> }
>
> Any tips you can provide would be greatly helpful!  My rubyfu is still weak
so I''m drawing a blank here.
>
> Thank you
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

"Non-blocking" does not necessarily mean "non-error
checking" - unless
you really want to forego it (as your example below does).

Best regards,

--Michael

On 3/1/07, James Robey <jrobey at stripemobile.com>
wrote:
> I figured out an easy way to do a non-blocking post from rails.
>
> `curl -d "parameterstring" http://site &`
>
> But I''m still very curious about the second part, running a
standalone eventmachine server yet interacting with it from the rails app.
>
> On Thu, 1 Mar 2007 08:09:09 -0700
> James Robey <jrobey at stripemobile.com> wrote:
>
> > I''ve got a need to use eventmachine in two different ways and
use it from a rails app.
> >
> > 1. Use eventmachine to do a non-blocking POST to a website.
> > 2. Use eventmachine as a server that manages some client programs that
connect to it.  Have the rails app provide an interface to the client server.
> >
> > I don''t suppose I can just stick something like this in a
controller/model file?  (And similar for the POST)
> >
> > EventMachine::run {
> >   EventMachine::start_server "127.0.0.1", 8081, ClientServer
> > }
> >
> > Any tips you can provide would be greatly helpful!  My rubyfu is still
weak so I''m drawing a blank here.
> >
> > Thank you
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
>

Yeah in this particular case, I''m not concerned about error checking.

I''ve figured out a ruby way to do it:

Thread.new { WWW::Mechanize.new().post("http://site", paramsend) }

On Thu, 1 Mar 2007 08:26:15 -0800
"Michael S. Fischer" <michael at dynamine.net> wrote:
> "Non-blocking" does not necessarily mean "non-error
checking" - unless
> you really want to forego it (as your example below does).
>
> Best regards,
>
> --Michael
>
> On 3/1/07, James Robey <jrobey at stripemobile.com> wrote:
> > I figured out an easy way to do a non-blocking post from rails.
> >
> > `curl -d "parameterstring" http://site &`
> >
> > But I''m still very curious about the second part, running a
standalone eventmachine server yet interacting with it from the rails app.
> >
> > On Thu, 1 Mar 2007 08:09:09 -0700
> > James Robey <jrobey at stripemobile.com> wrote:
> >
> > > I''ve got a need to use eventmachine in two different
ways and use it from a rails app.
> > >
> > > 1. Use eventmachine to do a non-blocking POST to a website.
> > > 2. Use eventmachine as a server that manages some client programs
that connect to it.  Have the rails app provide an interface to the client
server.
> > >
> > > I don''t suppose I can just stick something like this in
a controller/model file?  (And similar for the POST)
> > >
> > > EventMachine::run {
> > >   EventMachine::start_server "127.0.0.1", 8081,
ClientServer
> > > }
> > >
> > > Any tips you can provide would be greatly helpful!  My rubyfu is
still weak so I''m drawing a blank here.
> > >
> > > Thank you
> > > _______________________________________________
> > > Eventmachine-talk mailing list
> > > Eventmachine-talk at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> > >
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
> >
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

On 3/1/07, James Robey <jrobey at stripemobile.com>
wrote:
>
> Yeah in this particular case, I''m not concerned about error
checking.
>
> I''ve figured out a ruby way to do it:
>
> Thread.new { WWW::Mechanize.new().post("http://site", paramsend)
}


Sounds like you have solutions to your problems. For future reference, there
is an EM HTTP client intended for use within servers (such as when a server
needs to make a REST request somewhere else). It has some limitations which
we''re working on. (See the recent threads from Tony Arcieri on this
list.)

The problem with Rails is always that it''s not thread-safe.
It''s probably
not the best idea to try to embed advanced systems into a Rails app. You can
always do it outboard, though. I''d be hesitant to try to make Rails do
things it''s not good at.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070302/fdbf6b66/attachment.html

Actually I''m still trying to figure out how to have my rails app manage
several client programs that expect to be able to connect to a port and
communicate via that.  I was told EM would be good for that, so I''m
wondering how to integrate EM into the rails app.

Would I be able to run EM from within rails somehow? Or would I have to use
something like backgroundrb? (apparently it provides messaging capabilities)


On Fri, 2 Mar 2007 12:01:13 -0500
"Francis Cianfrocca" <garbagecat10 at gmail.com> wrote:
> On 3/1/07, James Robey <jrobey at stripemobile.com> wrote:
> >
> > Yeah in this particular case, I''m not concerned about error
checking.
> >
> > I''ve figured out a ruby way to do it:
> >
> > Thread.new { WWW::Mechanize.new().post("http://site",
paramsend) }
>
>
>
> Sounds like you have solutions to your problems. For future reference,
there
> is an EM HTTP client intended for use within servers (such as when a server
> needs to make a REST request somewhere else). It has some limitations which
> we''re working on. (See the recent threads from Tony Arcieri on
this list.)
>
> The problem with Rails is always that it''s not thread-safe.
It''s probably
> not the best idea to try to embed advanced systems into a Rails app. You
can
> always do it outboard, though. I''d be hesitant to try to make
Rails do
> things it''s not good at.
>

Not really enough information to make a coherent suggestion. The thought
that comes immediately to mind is to "manage the several client
programs"
(whatever that means) from a standalone EM application that accepts
connections from the Rails app.

You can easily run an EM event loop from a Rails handler but I don''t
see
what good it does you. Rails is always single threaded so you have to start
and stop the EM loop before you can feed a result back into Rails.

Unless you''re thinking that *each* individual Rails request needs to
access
a bunch of different client programs and aggregate the results. EM might be
a very good fit for that.

On 3/2/07, James Robey <jrobey at stripemobile.com>
wrote:
>
> Actually I''m still trying to figure out how to have my rails app
manage
> several client programs that expect to be able to connect to a port and
> communicate via that.  I was told EM would be good for that, so
I''m
> wondering how to integrate EM into the rails app.
>
> Would I be able to run EM from within rails somehow? Or would I have to
> use something like backgroundrb? (apparently it provides messaging
> capabilities)
>
>
> On Fri, 2 Mar 2007 12:01:13 -0500
> "Francis Cianfrocca" <garbagecat10 at gmail.com> wrote:
>
> > On 3/1/07, James Robey <jrobey at stripemobile.com> wrote:
> > >
> > > Yeah in this particular case, I''m not concerned about
error checking.
> > >
> > > I''ve figured out a ruby way to do it:
> > >
> > > Thread.new { WWW::Mechanize.new().post("http://site",
paramsend) }
> >
> >
> >
> > Sounds like you have solutions to your problems. For future reference,
> there
> > is an EM HTTP client intended for use within servers (such as when a
> server
> > needs to make a REST request somewhere else). It has some limitations
> which
> > we''re working on. (See the recent threads from Tony Arcieri
on this
> list.)
> >
> > The problem with Rails is always that it''s not thread-safe.
It''s
> probably
> > not the best idea to try to embed advanced systems into a Rails app.
You
> can
> > always do it outboard, though. I''d be hesitant to try to make
Rails do
> > things it''s not good at.
> >
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070302/1e441193/attachment.html

I started out with exactly the same problem (EM does --- let''s just
say --- LDAP for me, and handles demand-queries from Rails actions).

I have two solutions, neither optimal:

1. BackgrounDrb, with EM queuing up Marshalled Ruby objects and then
doing its own dispatch.

2. Just serializing objects in Rails myself, blitting them out to a
localhost socket EM listens on, and having the EM server dump results
into ActiveRecord.

What sucks about 1 is Drb, which is a synchronous API; I had to go
into the guts of its marshalling code to figure out how to fake out
the server stubs from EM.

What sucks about 2 is that it''s not really safe to have EM dump
results to a database, SQLite or otherwise, because on most systems
(1) the filesystem IO is blocking and can stall the event loop and (2)
the SQL interface is blocking, etc etc.

The "best" answer to this question is probably "use YAML to do
lightweight messaging over HTTP POST to EM, and have EM POST back the
results to another Rails action".

I am amused by, and share, Francis'' opinion of Rails as primitive, at
least in scalability/concurrency terms. On the other hand, Twisted is
extremely advanced and its API is a debacle.

I would love to see some kind of agreement about what the "Right" way
is to interface an EM loop to Rails is, and then a shared effort to
come up with one extensible implementation of that way.

On 3/2/07, James Robey <jrobey at stripemobile.com>
wrote:
> Actually I''m still trying to figure out how to have my rails app
manage several client programs that expect to be able to connect to a port and
communicate via that.  I was told EM would be good for that, so I''m
wondering how to integrate EM into the rails app.
>
> Would I be able to run EM from within rails somehow? Or would I have to use
something like backgroundrb? (apparently it provides messaging capabilities)
>
>
> On Fri, 2 Mar 2007 12:01:13 -0500
> "Francis Cianfrocca" <garbagecat10 at gmail.com> wrote:
>
> > On 3/1/07, James Robey <jrobey at stripemobile.com> wrote:
> > >
> > > Yeah in this particular case, I''m not concerned about
error checking.
> > >
> > > I''ve figured out a ruby way to do it:
> > >
> > > Thread.new { WWW::Mechanize.new().post("http://site",
paramsend) }
> >
> >
> >
> > Sounds like you have solutions to your problems. For future reference,
there
> > is an EM HTTP client intended for use within servers (such as when a
server
> > needs to make a REST request somewhere else). It has some limitations
which
> > we''re working on. (See the recent threads from Tony Arcieri
on this list.)
> >
> > The problem with Rails is always that it''s not thread-safe.
It''s probably
> > not the best idea to try to embed advanced systems into a Rails app.
You can
> > always do it outboard, though. I''d be hesitant to try to make
Rails do
> > things it''s not good at.
> >
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

On 3/2/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> I started out with exactly the same problem (EM does --- let''s
just
> say --- LDAP for me, and handles demand-queries from Rails actions).
>
> I have two solutions, neither optimal:
>
> 1. BackgrounDrb, with EM queuing up Marshalled Ruby objects and then
> doing its own dispatch.
>
> 2. Just serializing objects in Rails myself, blitting them out to a
> localhost socket EM listens on, and having the EM server dump results
> into ActiveRecord.
>
> What sucks about 1 is Drb, which is a synchronous API; I had to go
> into the guts of its marshalling code to figure out how to fake out
> the server stubs from EM.
>
> What sucks about 2 is that it''s not really safe to have EM dump
> results to a database, SQLite or otherwise, because on most systems
> (1) the filesystem IO is blocking and can stall the event loop and (2)
> the SQL interface is blocking, etc etc.
>
> The "best" answer to this question is probably "use YAML to
do
> lightweight messaging over HTTP POST to EM, and have EM POST back the
> results to another Rails action".
>
> I am amused by, and share, Francis'' opinion of Rails as primitive,
at
> least in scalability/concurrency terms. On the other hand, Twisted is
> extremely advanced and its API is a debacle.
>
> I would love to see some kind of agreement about what the "Right"
way
> is to interface an EM loop to Rails is, and then a shared effort to
> come up with one extensible implementation of that way.
>
> On 3/2/07, James Robey <jrobey at stripemobile.com> wrote:
> > Actually I''m still trying to figure out how to have my rails
app manage
> several client programs that expect to be able to connect to a port and
> communicate via that.  I was told EM would be good for that, so
I''m
> wondering how to integrate EM into the rails app.


I''m starting to get interested again in the idea of  doing an
event-driven
implementation of the DBMS protocols. We know that postgres has been done in
pure Ruby so maybe this isn''t as hubristic as it sounds.

How about running Rails *inside* an EM event loop? You''re always stuck
with
Rails being single-threaded, meaning in this case that if you kick off some
high-latency operation (like a DB call or a REST call to some external
server), and then try to dispatch another Rails request while waiting for
the first one to complete, Rails will probably become very angry. Although I
don''t know that for sure! EM''s Deferrable (identical
conceptually to
Twisted''s Deferred) can easily handle this kind of thing without
threads,
and it would be worth seeing if Rails can tolerate it.

Kirk may have the ultimate answer: use EM to build a clustering proxy and
run it in front of multiple single-threaded Rails processes, all of which
will block while handling each request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070302/c11259ed/attachment.html

On 3/2/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> Kirk may have the ultimate answer: use EM to build a clustering proxy and
> run it in front of multiple single-threaded Rails processes, all of which
> will block while handling each request.
See also HAProxy <http://haproxy.1wt.eu> if you don''t need to
reinvent
the wheel.

--Michael

An asynchronous Postgres or MySQL driver would be a solution to the
problem, because it''d allow an EM system to exchange data, at speed,
with a Rails app. Don''t you foresee an API problem binding this
implementation to ActiveRecord though? AR is (obviously) synchronous.

I''m not sure I see how the clustering server is a solution.
I''m not
sure the problem that needs to be solved is "using EM to speed up
Rails". I mean, do you really care? If you wanted a fast web app,
you''d use Python.

The problem as I see it is, you want to seperate your app into
user-speed Rails front end and systems-speed EM backend, with the
backend handling, say, transactional protocols, messaging, streaming,
or bulk data transfer. How do you link the two of them up, so that
Rails can "drive" the EM engine?

On 3/2/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
> > I have two solutions, neither optimal:
> >
> > 1. BackgrounDrb, with EM queuing up Marshalled Ruby objects and then
> > doing its own dispatch.
> >
> > 2. Just serializing objects in Rails myself, blitting them out to a
> > localhost socket EM listens on, and having the EM server dump results
> > into ActiveRecord.
> I''m starting to get interested again in the idea of  doing an
event-driven
> implementation of the DBMS protocols. We know that postgres has been done
in
> pure Ruby so maybe this isn''t as hubristic as it sounds.
>
> How about running Rails *inside* an EM event loop? You''re always
stuck with
> Rails being single-threaded, meaning in this case that if you kick off some
> high-latency operation (like a DB call or a REST call to some external
> server), and then try to dispatch another Rails request while waiting for
> the first one to complete, Rails will probably become very angry. Although
I
> don''t know that for sure! EM''s Deferrable (identical
conceptually to
> Twisted''s Deferred) can easily handle this kind of thing without
threads,
> and it would be worth seeing if Rails can tolerate it.
>
> Kirk may have the ultimate answer: use EM to build a clustering proxy and
> run it in front of multiple single-threaded Rails processes, all of which
> will block while handling each request.
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

I''m considering using merb instead of rails.  Hopefully I can do the
serializing in a non-blocking way in merb, or I could run merb inside EM.

Using EM w/ mongrel''s http parser + erb might be the best way to go
about this.

EM/mongrel hybrid + erb = memerb? emmerb? ;)

On Fri, 2 Mar 2007 18:22:18 -0500
"Francis Cianfrocca" <garbagecat10 at gmail.com> wrote:
> On 3/2/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> >
> > I started out with exactly the same problem (EM does ---
let''s just
> > say --- LDAP for me, and handles demand-queries from Rails actions).
> >
> > I have two solutions, neither optimal:
> >
> > 1. BackgrounDrb, with EM queuing up Marshalled Ruby objects and then
> > doing its own dispatch.
> >
> > 2. Just serializing objects in Rails myself, blitting them out to a
> > localhost socket EM listens on, and having the EM server dump results
> > into ActiveRecord.
> >
> > What sucks about 1 is Drb, which is a synchronous API; I had to go
> > into the guts of its marshalling code to figure out how to fake out
> > the server stubs from EM.
> >
> > What sucks about 2 is that it''s not really safe to have EM
dump
> > results to a database, SQLite or otherwise, because on most systems
> > (1) the filesystem IO is blocking and can stall the event loop and (2)
> > the SQL interface is blocking, etc etc.
> >
> > The "best" answer to this question is probably "use
YAML to do
> > lightweight messaging over HTTP POST to EM, and have EM POST back the
> > results to another Rails action".
> >
> > I am amused by, and share, Francis'' opinion of Rails as
primitive, at
> > least in scalability/concurrency terms. On the other hand, Twisted is
> > extremely advanced and its API is a debacle.
> >
> > I would love to see some kind of agreement about what the
"Right" way
> > is to interface an EM loop to Rails is, and then a shared effort to
> > come up with one extensible implementation of that way.
> >
> > On 3/2/07, James Robey <jrobey at stripemobile.com> wrote:
> > > Actually I''m still trying to figure out how to have my
rails app manage
> > several client programs that expect to be able to connect to a port
and
> > communicate via that.  I was told EM would be good for that, so
I''m
> > wondering how to integrate EM into the rails app.
>
>
>
> I''m starting to get interested again in the idea of  doing an
event-driven
> implementation of the DBMS protocols. We know that postgres has been done
in
> pure Ruby so maybe this isn''t as hubristic as it sounds.
>
> How about running Rails *inside* an EM event loop? You''re always
stuck with
> Rails being single-threaded, meaning in this case that if you kick off some
> high-latency operation (like a DB call or a REST call to some external
> server), and then try to dispatch another Rails request while waiting for
> the first one to complete, Rails will probably become very angry. Although
I
> don''t know that for sure! EM''s Deferrable (identical
conceptually to
> Twisted''s Deferred) can easily handle this kind of thing without
threads,
> and it would be worth seeing if Rails can tolerate it.
>
> Kirk may have the ultimate answer: use EM to build a clustering proxy and
> run it in front of multiple single-threaded Rails processes, all of which
> will block while handling each request.
>

On 3/2/07, Michael S. Fischer <michael at dynamine.net> wrote:
> See also HAProxy <http://haproxy.1wt.eu> if you don''t need
to reinvent
> the wheel.
It isn''t reinventing the wheel.  I have some very specific needs and
goals in mind with this that aren''t addressed by HAProxy.


Kirk Haines

On 3/2/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> How about running Rails *inside* an EM event loop? You''re always
stuck with
> Rails being single-threaded, meaning in this case that if you kick off some
> high-latency operation (like a DB call or a REST call to some external
> server), and then try to dispatch another Rails request while waiting for
> the first one to complete, Rails will probably become very angry. Although
I
> don''t know that for sure! EM''s Deferrable (identical
conceptually to
> Twisted''s Deferred) can easily handle this kind of thing without
threads,
> and it would be worth seeing if Rails can tolerate it.
Running Rails inside of an EM event loop is easy.  It should be no
more than a few hours hacking to build an EM based Rails runner.

However, running one Rails request while waiting for another to return
from some high latency action is asking for trouble.
> Kirk may have the ultimate answer: use EM to build a clustering proxy and
> run it in front of multiple single-threaded Rails processes, all of which
> will block while handling each request.
This is the basic clustering mode that Rails uses now.

The most popular option is to run multiple Rails processes behind some
sort of proxy, which itself, depending on the proxy, often sits behind
a web server.


Kirk

On 3/2/07, Kirk Haines <wyhaines at gmail.com>
wrote:
> On 3/2/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> > Kirk may have the ultimate answer: use EM to build a clustering proxy
and
> > run it in front of multiple single-threaded Rails processes, all of
which
> > will block while handling each request.
>
> This is the basic clustering mode that Rails uses now.
>
> The most popular option is to run multiple Rails processes behind some
> sort of proxy, which itself, depending on the proxy, often sits behind
> a web server.
Any pointers to said proxies?

--Michael

On 3/2/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> An asynchronous Postgres or MySQL driver would be a solution to the
> problem, because it''d allow an EM system to exchange data, at
speed,
> with a Rails app. Don''t you foresee an API problem binding this
> implementation to ActiveRecord though? AR is (obviously) synchronous.

Something I''ve wanted to do for a long time (which I''m sure
would be slow as
molasses) is stick a synchronous API on top of the Reactor pattern using
continuations.  That is to say, you''d expose some synchronous
read/write
routines which would continue the inner EventMachine loop.  Or in the case
of an SQL library, you''d expose synchronous calls to run queries, which
would run EventMachine''s inner event loop until the query completes,
then
the results could be returned in bulk.

It''d allow you to program as if you''re writing a multithreaded
application
which makes blocking I/O calls, but these calls just continue an inner event
loop.

With an API like that, you could implement ActiveRecord on top of
asynchronous database drivers.  The only problem is continuations could kill
your performance.

- Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070302/260a4ec6/attachment.html

On 3/2/07, Michael S. Fischer <michael at dynamine.net> wrote:
> See also HAProxy <http://haproxy.1wt.eu> if you don''t need
to reinvent
> the wheel.
Just FYI, I just installed haproxy and did some very quick benchmarks with it.

Proxying through my clustering proxy, I get, with 2 IOWA backends,
about 2800 reqs/second for a small static file.  Using haproxy I get
1500/second.

Going to a dynamic hello world rendering, I average around 900/second.
 With haproxy, that''s about 700/second.

Just a few quick factlets.


Kirk Haines

On 3/2/07, Michael S. Fischer <michael at dynamine.net> wrote:
> > The most popular option is to run multiple Rails processes behind some
> > sort of proxy, which itself, depending on the proxy, often sits behind
> > a web server.
>
> Any pointers to said proxies?
The common configurations are, I believe, covered somewhere on the
Mongrel site.  However, they seem to be, in no particular order:

nginx + mongrel (seems to be one of the faster options, though nginx''s
proxying will keep throwing work at mongrels whichb are already bogged
down, further drowning them)

apache 2.2/mod_proxy_balancer + mongrel

apache 2.0(or 2.2) + pound or pen or haproxy + mongrel

lighttpd 1.5 + mongrel

I also imagine that one could run haproxy right to a group on mongrels
on the backend, though I haven''t seen much about doing that.


Kirk Haines

On 3/2/07, Kirk Haines <wyhaines at gmail.com> wrote:
> Just FYI, I just installed haproxy and did some very quick benchmarks with
it.
>
> Proxying through my clustering proxy, I get, with 2 IOWA backends,
> about 2800 reqs/second for a small static file.  Using haproxy I get
> 1500/second.
>
> Going to a dynamic hello world rendering, I average around 900/second.
>  With haproxy, that''s about 700/second.
>
> Just a few quick factlets.
Interesting.  To what do you attribute the difference in speed?  In my
experience HAProxy is blisteringly fast.

--Michael

What about spawning Rails processes dynamically and invoking
Dispatcher.dispatch through something like DRb?

I guess the fundamental problem here is thunking between DRb and
EventMachine.  I heard at one point people were doing EM-based
implementations of DRb.  What happened with that?

- Tony

On 3/2/07, Kirk Haines <wyhaines at gmail.com>
wrote:
>
> On 3/2/07, Michael S. Fischer <michael at dynamine.net> wrote:
>
> > See also HAProxy <http://haproxy.1wt.eu> if you don''t
need to reinvent
> > the wheel.
>
> Just FYI, I just installed haproxy and did some very quick benchmarks with
> it.
>
> Proxying through my clustering proxy, I get, with 2 IOWA backends,
> about 2800 reqs/second for a small static file.  Using haproxy I get
> 1500/second.
>
> Going to a dynamic hello world rendering, I average around 900/second.
> With haproxy, that''s about 700/second.
>
> Just a few quick factlets.
>
>
> Kirk Haines
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
(970) 232-4208
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070302/54df1df7/attachment.html

This won''t be slow as molasses; it''s a good idea. My friend
Danny and
I designed something like this 7 years ago in Tcl:

http://www.ishiboo.com/~nirva/Projects/phasemachines/

You could do much, much better in a language with better scoping and
typing rules.

This is why async is so interesting in Ruby: you have a much better
shot of making it painless here than you do in Python.

On 3/2/07, Tony Arcieri <tony at clickcaster.com>
wrote:
> On 3/2/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> > An asynchronous Postgres or MySQL driver would be a solution to the
> > problem, because it''d allow an EM system to exchange data, at
speed,
> Something I''ve wanted to do for a long time (which I''m
sure would be slow as
> molasses) is stick a synchronous API on top of the Reactor pattern using
> continuations.  That is to say, you''d expose some synchronous
read/write
> routines which would continue the inner EventMachine loop.  Or in the case
> of an SQL library, you''d expose synchronous calls to run queries,
which
> would run EventMachine''s inner event loop until the query
completes, then
> the results could be returned in bulk.
>
> It''d allow you to program as if you''re writing a
multithreaded application
> which makes blocking I/O calls, but these calls just continue an inner
event
> loop.
>
> With an API like that, you could implement ActiveRecord on top of
> asynchronous database drivers.  The only problem is continuations could
kill
> your performance.
>
> - Tony
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

Well, that''s great.  Would you be willing to work on an API like that,
built
on top of EventMachine?

I haven''t ever used continuations in Ruby myself (I''ve used
similar
constructs like Win32 Fibers and Unix ucontexts in C) and my only real
impressions of them are all based on hearsay.  I''ve heard that
continuations
are slow and going away in 1.9/2.0, but I don''t know if either of these
are
really the case.

This is certainly an approach I''d like to investigate.  If
you''re willing to
work on an implementation I''d certainly be willing to help.

- Tony

On 3/2/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> This won''t be slow as molasses; it''s a good idea. My
friend Danny and
> I designed something like this 7 years ago in Tcl:
>
> http://www.ishiboo.com/~nirva/Projects/phasemachines/
>
> You could do much, much better in a language with better scoping and
> typing rules.
>
> This is why async is so interesting in Ruby: you have a much better
> shot of making it painless here than you do in Python.
>
> On 3/2/07, Tony Arcieri <tony at clickcaster.com> wrote:
> > On 3/2/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> > > An asynchronous Postgres or MySQL driver would be a solution to
the
> > > problem, because it''d allow an EM system to exchange
data, at speed,
> > Something I''ve wanted to do for a long time (which
I''m sure would be
> slow as
> > molasses) is stick a synchronous API on top of the Reactor pattern
using
> > continuations.  That is to say, you''d expose some synchronous
read/write
> > routines which would continue the inner EventMachine loop.  Or in the
> case
> > of an SQL library, you''d expose synchronous calls to run
queries, which
> > would run EventMachine''s inner event loop until the query
completes,
> then
> > the results could be returned in bulk.
> >
> > It''d allow you to program as if you''re writing a
multithreaded
> application
> > which makes blocking I/O calls, but these calls just continue an inner
> event
> > loop.
> >
> > With an API like that, you could implement ActiveRecord on top of
> > asynchronous database drivers.  The only problem is continuations
could
> kill
> > your performance.
> >
> > - Tony
> >
> > _______________________________________________
> > Eventmachine-talk mailing list
> > Eventmachine-talk at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/eventmachine-talk
> >
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
(970) 232-4208
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070302/e5cc133c/attachment-0001.html

On 3/2/07, Michael S. Fischer <michael at dynamine.net>
wrote:
> On 3/2/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> > Just FYI, I just installed haproxy and did some very quick benchmarks
with it.
> >
> > Proxying through my clustering proxy, I get, with 2 IOWA backends,
> > about 2800 reqs/second for a small static file.  Using haproxy I get
> > 1500/second.
> >
> > Going to a dynamic hello world rendering, I average around 900/second.
> >  With haproxy, that''s about 700/second.
>
> Interesting.  To what do you attribute the difference in speed?  In my
> experience HAProxy is blisteringly fast.
I get slightly faster speed, particularly with static files, by
switching from the http mode to the tcp mode on haproxy.

The speed difference is probably mostly just because haproxy has a
pile of features, so it''s doing a LOT more work.  When one looks at
all of the different things that can be configured and then looks at
that speed, it''s not too bad.  I have some specific goals in mind for
this proxy, though; it''s not a general purpose proxy for any sort of
network traffic.  So I don''t need to implement most of those features.


Kirk Haines

On 3/2/07, Tony Arcieri <tony at clickcaster.com> wrote:
> I haven''t ever used continuations in Ruby myself (I''ve
used similar
> constructs like Win32 Fibers and Unix ucontexts in C) and my only real
> impressions of them are all based on hearsay.  I''ve heard that
continuations
> are slow and going away in 1.9/2.0, but I don''t know if either of
these are
> really the case.
I''d love to see this work well.  Ruby''s continuations are not
fast,
and in the past they also tended to leak RAM (no idea if this was ever
fixed), so I have some skepticism that it will work, but I would love
to be wrong.


Kirk Haines

On 3/2/07, James Robey <jrobey at stripemobile.com>
wrote:
>
> I''m considering using merb instead of rails.  Hopefully I can do
the
> serializing in a non-blocking way in merb, or I could run merb inside EM.
>
> Using EM w/ mongrel''s http parser + erb might be the best way to
go about
> this.
>
> EM/mongrel hybrid + erb = memerb? emmerb? ;)


I don''t think Ezra follows this list but it might be worth throwing out
an
email to him, to see about fronting merb with EM. There already is an
EM-ready HTTP parser, no need for mongrel. As I promised Tony, I''ll try
to
get it published this weekend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070303/a059a5cd/attachment.html

On 3/2/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> An asynchronous Postgres or MySQL driver would be a solution to the
> problem, because it''d allow an EM system to exchange data, at
speed,
> with a Rails app. Don''t you foresee an API problem binding this
> implementation to ActiveRecord though? AR is (obviously) synchronous.
>
> I''m not sure I see how the clustering server is a solution.
I''m not
> sure the problem that needs to be solved is "using EM to speed up
> Rails". I mean, do you really care? If you wanted a fast web app,
> you''d use Python.
>
> The problem as I see it is, you want to seperate your app into
> user-speed Rails front end and systems-speed EM backend, with the
> backend handling, say, transactional protocols, messaging, streaming,
> or bulk data transfer. How do you link the two of them up, so that
> Rails can "drive" the EM engine?


I think that''s a pretty coherent analysis, Thomas. And I completely
agree
that there''s not much point in "speeding up Rails." Rails is
what it is, and
it was never designed for speed but rather to minimize development time.
(That Rails greatly advanced the state of the Ruby art is terrific but
doesn''t change the prior statements.)

Integration of an event-driven DB client with AR: I don''t think
I''d even
try. If you want really high-speed database access, you won''t be using
AR in
the first place. And I think I''d rather try to implement the DB
protocol
first just to see if it makes any difference.

The vision you present for splitting the work up between Rails and a
"services" engine makes me think of a fast EM-based RESTful web server
that
presents services to Rails. I still see value in the cluster-proxy in front
of rails, just to get scalability. You''ll never make Rails faster, but
you
can handle more Rails requests per unit of time if you have more Rails
processes. Especially if you can distribute them across several machines.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070303/97fa6e6c/attachment.html

On 3/3/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> The vision you present for splitting the work up between Rails and a
> "services" engine makes me think of a fast EM-based RESTful web
server that
> presents services to Rails.
This is my project, BTW - or, at least a part of it.  (The other
portion presents services to another daemon that talks to Rails
RESTfully.)

--Michael

On 3/2/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> I''m not sure I see how the clustering server is a solution.
I''m not
> sure the problem that needs to be solved is "using EM to speed up
> Rails". I mean, do you really care? If you wanted a fast web app,
> you''d use Python.
On what do you base that?  Every benchmark I have seen has shown
Django to be faster than Rails, but that''s no particular achievement.
Rails is slow, but don''t judge Ruby web framework speed as a whole
just based on Rails.
> The problem as I see it is, you want to seperate your app into
> user-speed Rails front end and systems-speed EM backend, with the
> backend handling, say, transactional protocols, messaging, streaming,
> or bulk data transfer. How do you link the two of them up, so that
> Rails can "drive" the EM engine?
As I''ve mentioned, it''s not too hard.

Right now Rails will run inside of Mongrel and WEBrick, both of which
are just simple web servers.

One just builds an EM powered web server to receive requests, creating
a request structure that Rails expects, and then calls Rails to handle
the request.

I''ve already done this using both the Mongrel HTTP parser and
Francis''
HttpMachine HTTP parser.  I just haven''t strapped it to Rails.

The performance benefits, with low concurrency, probably aren''t going
to be significant, because Rails is so slow.  However, with
concurrency above 1, there should be some benefit.  Also, because
Rails would be running inside of the EM event loop, it would then be
easy to mix other EM actions into the Rails app.


Kirk Haines

On 3/3/07, Kirk Haines <wyhaines at gmail.com> wrote:
> Right now Rails will run inside of Mongrel and WEBrick, both of which
> are just simple web servers.
Why aren''t more people using the FastCGI interface?  Any thoughts on
that?

--Michael

On 3/3/07, Michael S. Fischer <michael at dynamine.net>
wrote:
> On 3/3/07, Kirk Haines <wyhaines at gmail.com> wrote:
>
> > Right now Rails will run inside of Mongrel and WEBrick, both of which
> > are just simple web servers.
>
> Why aren''t more people using the FastCGI interface?  Any thoughts
on that?
It''s harder to get it up and running than it is to throw a bunch of
processes behind a proxy.  That''s a major factor.  The other issue is
that it doesn''t really seem to perform enough better than running
through a proxy does for people to want to mess with the complexity
they perceive from it.


Kirk Haines

> > Rails". I mean, do you really care? If you wanted a fast web app,
> > you''d use Python.
> On what do you base that?  Every benchmark I have seen has shown
> Django to be faster than Rails, but that''s no particular
achievement.
This would be an incredibly boring argument. However, if you''ve got a
Ruby-driven app server that beats Nevow, which is pure async and
full-featured (excepting the fact that it relies on a sync database),
I''d really like to know about it.

On 3/3/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
> > > Rails". I mean, do you really care? If you wanted a fast web
app,
> > > you''d use Python.
> > On what do you base that?  Every benchmark I have seen has shown
> > Django to be faster than Rails, but that''s no particular
achievement.
>
> This would be an incredibly boring argument. However, if you''ve
got a
> Ruby-driven app server that beats Nevow, which is pure async and
> full-featured (excepting the fact that it relies on a sync database),
> I''d really like to know about it.
Eh.  That''s like saying, "If you know of a Python Foo that runs
faster
than the Bar written in C, I''d like to hear about it."

I just looked, and I came up empty on any sort of performance
information for nevow.  In looking at nevow itself, I have no doubt
that it is fast.  But that alone hardly invalidates wanting to write
fast apps with Ruby.  I''ll download nevow and compare their example
hello world app on my server with mine in IOWA (which provides a lot
more tools for the app writer than it appears that Nevow does), using
an EM powered run mode for the IOWA side of things, just to see.


Kirk Haines

On 3/3/07, Kirk Haines <wyhaines at gmail.com> wrote:
> > This would be an incredibly boring argument. However, if
you''ve got a
> > Ruby-driven app server that beats Nevow, which is pure async and
> > full-featured (excepting the fact that it relies on a sync database),
> > I''d really like to know about it.
Alright.

Running on the latest Nevow (0.9.0) with the latest Twisted (2.5.0).

I used the Hello World example out of the Nevow getting started doc
(which is also in the examples dir), and compared it to an identical
Hello World app in IOWA.

I just used Apache Bench for these tests (compared with httperf, and
the numbers are nearly identical).  In all cases, I ran sample runs
with 5000 requests.

Concurrency of 1:
Nevow: 470/second
IOWA: 533/second

Concurrency of 10:
Nevow: 590/second
IOWA: 685/second

Concurrency of 50:
Nevow: 625/second
IOWA: 755/second

Concurrency of 100:
Nevow: 25/second
IOWA: 760/second

That last number for Nevow is not a typo.  Things completely fall
apart for it at high concurrencies (looks like right around 60
concurrent requests it''s performance goes to pieces).

So it appears that IOWA is at least comparable to Nevow in speed.  In
the IOWA tests, it was running using the EM based run mode that uses
Mongrel for the http parser.  In early benchmarks, it looked like
Francis'' http parser might be a bit faster than the Mongrel one, but I
didn''t test with that one because it still needs some work before it
passes my tests.


Kirk Haines

My point was, if you''re talking about using Rails, speed has already
gone out the window. Right now, if you want "full featured",
"proven"
and "fast", I don''t know of anything in Ruby that suffices
--- but I''d
love to be educated.

I wouldn''t be yapping on a Ruby event loop mailing list if I though
writing fast Ruby was a waste of time.

So what I understand is, you can run Rails out of an evented web
server. What I don''t understand is, what''s the reliable,
persistent,
async-safe way of sharing data between a Rails app and an EM app,
regardless of whether they''re in the same process or not?
Don''t say
ActiveRecord, because that''s not async-safe.

Right now, my answers are "something similar to DRb, async in EM and
sync in Rails; or, async post-back queries to Rails from EM".
> I just looked, and I came up empty on any sort of performance
> information for nevow.  In looking at nevow itself, I have no doubt
> that it is fast.  But that alone hardly invalidates wanting to write
> fast apps with Ruby.  I''ll download nevow and compare their
example

So this gets back to my original suggestion of using EM to do DRb...

- Tony

On 3/3/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> My point was, if you''re talking about using Rails, speed has
already
> gone out the window. Right now, if you want "full featured",
"proven"
> and "fast", I don''t know of anything in Ruby that
suffices --- but I''d
> love to be educated.
>
> I wouldn''t be yapping on a Ruby event loop mailing list if I
though
> writing fast Ruby was a waste of time.
>
> So what I understand is, you can run Rails out of an evented web
> server. What I don''t understand is, what''s the reliable,
persistent,
> async-safe way of sharing data between a Rails app and an EM app,
> regardless of whether they''re in the same process or not?
Don''t say
> ActiveRecord, because that''s not async-safe.
>
> Right now, my answers are "something similar to DRb, async in EM and
> sync in Rails; or, async post-back queries to Rails from EM".
>
> > I just looked, and I came up empty on any sort of performance
> > information for nevow.  In looking at nevow itself, I have no doubt
> > that it is fast.  But that alone hardly invalidates wanting to write
> > fast apps with Ruby.  I''ll download nevow and compare their
example
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>


--
Tony Arcieri
ClickCaster, Inc.
tony at clickcaster.com
(970) 232-4208
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070303/54e860bc/attachment.html

On 3/3/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> My point was, if you''re talking about using Rails, speed has
already
> gone out the window. Right now, if you want "full featured",
"proven"
> and "fast", I don''t know of anything in Ruby that
suffices --- but I''d
> love to be educated.
>
> I wouldn''t be yapping on a Ruby event loop mailing list if I
though
> writing fast Ruby was a waste of time.
>
> So what I understand is, you can run Rails out of an evented web
> server. What I don''t understand is, what''s the reliable,
persistent,
> async-safe way of sharing data between a Rails app and an EM app,
> regardless of whether they''re in the same process or not?
Don''t say
> ActiveRecord, because that''s not async-safe.
>
> Right now, my answers are "something similar to DRb, async in EM and
> sync in Rails; or, async post-back queries to Rails from EM".


I''m going to ask a question that will sound like a really dumb
question, but
I think it''s important to frame the debate.

Why use Rails at all? Exactly what are we getting from using Rails, that we
wouldn''t necessarily get from some faster and more concurrent
alternative?

If the answer is not a large set of functionality, then at least for niche
applications it might make sense to fill that gap with alternative
frameworks like IOWA or merb, would it not?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070303/64331b58/attachment.html

> I''m going to ask a question that will sound like a really dumb
question, but
> I think it''s important to frame the debate.
>
> Why use Rails at all? Exactly what are we getting from using Rails, that we
> wouldn''t necessarily get from some faster and more concurrent
alternative?
>
> If the answer is not a large set of functionality, then at least for niche
> applications it might make sense to fill that gap with alternative
> frameworks like IOWA or merb, would it not?
I''ve just been going through that decision process myself on a new
project.  The conclusion I came to is that it''s really activerecord
and activesupport that I wanted.  So I wrote my code in it''s own
module/namespace outside of rails.  Now I can use it in rails, EM, or
just call it directly from a script if I want.

Rails is really the sum of it''s parts, and you don''t have to
use rails
as a whole to get things like activerecord.  It is much easier in my
case to simply use the parts I need then trying to  make the whole
rails stack run under EM.

Chris

On 3/4/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
> On 3/3/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> > My point was, if you''re talking about using Rails, speed has
already
> > gone out the window. Right now, if you want "full featured",
"proven"
> > and "fast", I don''t know of anything in Ruby that
suffices --- but I''d
> > love to be educated.
> >
> > I wouldn''t be yapping on a Ruby event loop mailing list if I
though
> > writing fast Ruby was a waste of time.
> >
> > So what I understand is, you can run Rails out of an evented web
> > server. What I don''t understand is, what''s the
reliable, persistent,
> > async-safe way of sharing data between a Rails app and an EM app,
> > regardless of whether they''re in the same process or not?
Don''t say
> > ActiveRecord, because that''s not async-safe.
> >
> > Right now, my answers are "something similar to DRb, async in EM
and
> > sync in Rails; or, async post-back queries to Rails from EM".
>
>
> I''m going to ask a question that will sound like a really dumb
question, but
> I think it''s important to frame the debate.
>
> Why use Rails at all? Exactly what are we getting from using Rails, that we
> wouldn''t necessarily get from some faster and more concurrent
alternative?
>
> If the answer is not a large set of functionality, then at least for niche
> applications it might make sense to fill that gap with alternative
> frameworks like IOWA or merb, would it not?
>
Agreed that rails is not thread safe and all, but as  a Web Framework
rails has a lot to offer. Couple of things are excellent
Javascript/Ajax/JSON integration, plugin architecture, REST.

--
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.

On 3/3/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> Why use Rails at all? Exactly what are we getting from using Rails, that we
> wouldn''t necessarily get from some faster and more concurrent
alternative?
I think it boils down to a few things.

1) Evangelism & Visibility & Intertia

Rails attained a tremendous amount of exposure very quickly, and that
helped fuel it, so now people know it as THE way to do web stuff with
Ruby.

2) Documentation, Books, Resources

I know that this has been a barrier towards people trying IOWA in the
past.  The documentation was lousy.  I know that this is a barrier for
people trying Nitro.  To a greater or lesser extent, it''s an issue
with all of the other frameworks.  Rails has a tremendous advantage in
this area, which makes it an easy, safe choice for people.

3) Feature Abundance/Overabundance?

The feature list of Rails is immense.  If someone wants to do
something with Rails, there is probably an implemented way to do it.

4) Performance anti-FUD

One doesn''t have to look very far to find sage advice about how Rails
performance isn''t an issue because hardware is cheaper than developer
time, so it''s OK to just throw thousands of dollars of hardware at the
performance issues.  In some cases that is certainly true, but I don''t
think it''s the truism it is presented as.
> If the answer is not a large set of functionality, then at least for niche
> applications it might make sense to fill that gap with alternative
> frameworks like IOWA or merb, would it not?
I am hoping that with the 1.0 release of IOWA, some people will see it
so, yes.  And tying this all back to EM, the best performance numbers
for IOWA come through the use of EM, and I think there is more to come
in that respect.


Kirk Haines

On 3/3/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
> My point was, if you''re talking about using Rails, speed has
already
> gone out the window. Right now, if you want "full featured",
"proven"
> and "fast", I don''t know of anything in Ruby that
suffices --- but I''d
> love to be educated.
I''ll point you at the IOWA 1.0 release very shortly.  I''ve
been using
it for commercial purposes across dozens of sites and applications
over the last 5 years.
> So what I understand is, you can run Rails out of an evented web
> server. What I don''t understand is, what''s the reliable,
persistent,
> async-safe way of sharing data between a Rails app and an EM app,
> regardless of whether they''re in the same process or not?
Don''t say
> ActiveRecord, because that''s not async-safe.
AR really isn''t the problem there, though, is it?  It''s still
the
interaction with the backend databases that occurs synchronously, and
unless the database API itself offers asynchronous query support, that
limits one''s ability to really work around the issue.
> Right now, my answers are "something similar to DRb, async in EM and
> sync in Rails; or, async post-back queries to Rails from EM".
As I see it, there are two factors in place when talking about db
interaction and the benefits of being able to do that asynchronously
in Ruby.

If one has an external process with asynchronous access that is
performing the database queries, then the main process isn''t blocked
while waiting for those queries.  This is especially valuable when
multithreading, of course, because even if one thread is just waiting
for the query to return, other threads can run.  It won''t, however,
increase query throughput because the external process will still be
processing queries synchronously.

So, how much of a gain would that be for the typical situation?

Then, one could take it one step farther.  Have multiple query
processes and have one''s async queries distributed between them.

None of this is hard to build, but is the gain in any of it worth the
increased complexity?  Am I looking at this incorrectly?


Kirk Haines

Because Rails devs are cheaper than EM/IOWA/hand-rolled Ruby devs,
because Rails projects can be contracted out piecemeal to any of 50
different little consultancies, because interaction designers can stub
out entire Rails UIs for you, and because Rails is more functional,
just by feature count, than the alternatives.

My situation is probably very different from most of yours, in that
the web tier isn''t the core of the application. But again, imagine
applications where there is a huge scalability concern at the engine
layer, which may or may not be HTTP, but minimal scalability concerns
in the user interface. As a third example, imagine any firewall or
router.

If your project is to build a web app that can survive repeated
Slashdotting on a single commodity server, then this conversation
about alternative frameworks or evented Rails makes sense.

On 3/3/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
> On 3/3/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> > My point was, if you''re talking about using Rails, speed has
already
> > gone out the window. Right now, if you want "full featured",
"proven"
> > and "fast", I don''t know of anything in Ruby that
suffices --- but I''d
> > love to be educated.
> >
> > I wouldn''t be yapping on a Ruby event loop mailing list if I
though
> > writing fast Ruby was a waste of time.
> >
> > So what I understand is, you can run Rails out of an evented web
> > server. What I don''t understand is, what''s the
reliable, persistent,
> > async-safe way of sharing data between a Rails app and an EM app,
> > regardless of whether they''re in the same process or not?
Don''t say
> > ActiveRecord, because that''s not async-safe.
> >
> > Right now, my answers are "something similar to DRb, async in EM
and
> > sync in Rails; or, async post-back queries to Rails from EM".
>
>
> I''m going to ask a question that will sound like a really dumb
question, but
> I think it''s important to frame the debate.
>
> Why use Rails at all? Exactly what are we getting from using Rails, that we
> wouldn''t necessarily get from some faster and more concurrent
alternative?
>
> If the answer is not a large set of functionality, then at least for niche
> applications it might make sense to fill that gap with alternative
> frameworks like IOWA or merb, would it not?
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

I''m interested in IOWA but there''s minimal likelihood that
I''ll ever
use it. I say that not to irritate you, but because I think I
represent a (weird little) demographic. Like I said, if web UI
performance was that big of a concern for me, I''d still be using
Python, Nevow, and ctypes. My performance concerns are orthogonal to
my choice of web framework.

You''re right that the async-safety problem with SQL is at the database
layer, but note that MySQL and Postgres live behind sockets, and their
interfaces can be made async-safe by client-side queueing. But you
can''t do that without breaking the synchronous ActiveRecord API, which
expects results from operations to be available before ActiveRecord
methods return to their callers. This is why Tcl has "vwait", which is
(of course) a debacle.

Please correct me if I''m wrong, but an async-safe ActiveRecord-style
API would require block arguments to "find" to accept the results.

I''m not sure I follow the last part of your message. The only reason
you thread in an async application is to take advantage of hardware
concurrency. Nothing ever blocks. There are also more reasons to build
network code async than concurrency; for instance, look at what
blocking connections and gethostbyname does to old web browsers.

In any async engine, you can''t call ActiveRecord''s APIs,
because they
all block on an external process and/or the disk. It doesn''t matter
how ActiveRecord is implemented under the hood. And the reason you
want ActiveRecord is, it allows you to link a very fast network engine
to a very slow, but very featureful web front end.
> I''ll point you at the IOWA 1.0 release very shortly. 
I''ve been using
> it for commercial purposes across dozens of sites and applications
> over the last 5 years.
>
> > So what I understand is, you can run Rails out of an evented web
> > server. What I don''t understand is, what''s the
reliable, persistent,
> > async-safe way of sharing data between a Rails app and an EM app,
> > regardless of whether they''re in the same process or not?
Don''t say
> > ActiveRecord, because that''s not async-safe.
>
> AR really isn''t the problem there, though, is it?  It''s
still the
> interaction with the backend databases that occurs synchronously, and
> unless the database API itself offers asynchronous query support, that
> limits one''s ability to really work around the issue.
>
> > Right now, my answers are "something similar to DRb, async in EM
and
> > sync in Rails; or, async post-back queries to Rails from EM".
>
> As I see it, there are two factors in place when talking about db
> interaction and the benefits of being able to do that asynchronously
> in Ruby.
>
> If one has an external process with asynchronous access that is
> performing the database queries, then the main process isn''t
blocked
> while waiting for those queries.  This is especially valuable when
> multithreading, of course, because even if one thread is just waiting
> for the query to return, other threads can run.  It won''t,
however,
> increase query throughput because the external process will still be
> processing queries synchronously.
>
> So, how much of a gain would that be for the typical situation?
>
> Then, one could take it one step farther.  Have multiple query
> processes and have one''s async queries distributed between them.
>
> None of this is hard to build, but is the gain in any of it worth the
> increased complexity?  Am I looking at this incorrectly?
>
>
> Kirk Haines
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

On 3/4/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> Because Rails devs are cheaper than EM/IOWA/hand-rolled Ruby devs,
> because Rails projects can be contracted out piecemeal to any of 50
> different little consultancies, because interaction designers can stub
> out entire Rails UIs for you, and because Rails is more functional,
> just by feature count, than the alternatives.
>
> My situation is probably very different from most of yours, in that
> the web tier isn''t the core of the application. But again, imagine
> applications where there is a huge scalability concern at the engine
> layer, which may or may not be HTTP, but minimal scalability concerns
> in the user interface. As a third example, imagine any firewall or
> router.
>
> If your project is to build a web app that can survive repeated
> Slashdotting on a single commodity server, then this conversation
> about alternative frameworks or evented Rails makes sense.



Sounds like you have an application that doesn''t process a large number
of
HTTP requests from clients, but has to do a great deal of work in order to
fulfill each one. Right?

I was intrigued by the statement that Rails allows you to split up the
development of the front end of a web application into fifty (!) pieces that
can be developed independently. I would have thought Rails would make that
uniquely difficult. Do you actually do that on a regular basis?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/671dfd6b/attachment.html

> Sounds like you have an application that doesn''t process a large
number of
> HTTP requests from clients, but has to do a great deal of work in order to
> fulfill each one. Right?
It''s not even that, although there''s another scenario in which
"speeding up Rails" is not the value prop for EM. I don''t
care how
fast my Rails UI is, because it''s only used by administrators, and
only used to get statistics and change configurations. But my Rails UI
does need to see the work product of my evented engine code.
> I was intrigued by the statement that Rails allows you to split up the
> development of the front end of a web application into fifty (!) pieces
that
> can be developed independently. I would have thought Rails would make that
> uniquely difficult. Do you actually do that on a regular basis?
The number 50 was applied to "the number of commodity RoR shops who
can act as human scaffold generators to create reasonably pretty user
interfaces", not the number of components in the application.

I''m not sure how Rails makes it uniquely difficult to carve up an
application into pieces, though; I''m pretty sure the opposite is true.
Given a (stubbed-out) ActiveRecord model interface and a document full
of use cases, you can contract out small portions of a Rails web
interface.

My team is rock solid on engine stuff (we''re systems programmers) but
really bad at getting reasonable, useable HTML interfaces onto a
screen. From experience in the security industry, this is a really
common problem. ;)

That said, we''re doing our own Rails development right now and
wouldn''t trade it for another framework anyways. Most applications can
be divided into a performance critical engine and a
flexibility-critical front end --- take FeedBurner as a Web 2.0
example. EM obviously shines at the former, and Rails at the latter.
Why would I add risk to my project by trying to event the front-end?

I would really like to see a standard off the shelf answer to linking
up Rails and EM, because then EM could be the de facto standard for
writing non-database backend code (forwarding packets, feeding
streams, interfacing with other protocols) for Rails. We could start
building things like, the AIM/OSCAR plugin for Rails.

On 3/4/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
>  I would really like to see a standard off the shelf answer to linking
> up Rails and EM, because then EM could be the de facto standard for
> writing non-database backend code (forwarding packets, feeding
> streams, interfacing with other protocols) for Rails. We could start
> building things like, the AIM/OSCAR plugin for Rails.



If you accept that the event-driven) services engine is a distinct process
or process group from Rails, then the glue that connects Rails to the engine
doesn''t need to know anything about EM at all. It can even be RESTful
calls
using net/http. Rails will block and that''s ok. The backend will not
block.
That''s the easy case. I wouldn''t touch DRb for this because it
doesn''t add
any value.

To support this, we should have a REST engine bundled into the EM package.
Not a deep challenge.

A more ambitious possibility is asynchronous messaging, which will need to
have in EM someday anyway to interface with Java-based enterprise systems.
For the Rails->EM problem, I don''t see immediate value to this,
though.

Would this be a useful pattern to do something like an AIM/OSCAR plugin?
(You''d probably need some kind of server push into the Rails app.)

If you''re that Rails and EM should somehow both be running in the same
process, that''s a different question. I''m still not seeing the
value of
that.

More generally, I think it *should* be our ambition to make EM the platform
of choice for services engines, whether or not they will run in conjunction
with Rails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/31349ba4/attachment.html

REST is a nice answer to this problem, but just like with
ActiveRecord, you''re not going to get ActiveResource for free, because
the Rails interfaces are too simplistic. If I understand REST well
enough, the rationale is still to create RPC-style web services
bindings to HTTP. Again we''re butting into that "RPC Considered
Harmful" paper from 20 years ago.

But, yeah, what you''re saying makes perfect sense. Synchronous Rails,
high-speed EM engine, and the link between them is REST-style HTTP
GET/POST; nothing needs to change in Rails, but we probably need some
EM clientside work to make the XML POST less painful.

Rails doesn''t support Tibco/SmartSockets/JMS-style messaging anyways.
I >heart< message APIs, and burnt up a huge wad of cash on a messaging
startup in the 90''s, but I don''t see the value add.

I like the "Services Engine" branding!

So, if I understand where this is going, we''re probably converging on
this answer to "how to use Rails with EventMachine":

- Stick EM in another Ruby process

- Have EM listen for HTTP requests

- Use HTTP POST/GET to send stuff to EM from Rails

- Use HTTP POST/GET to send results back to Rails

On 3/4/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
> On 3/4/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> >  I would really like to see a standard off the shelf answer to linking
> > up Rails and EM, because then EM could be the de facto standard for
> > writing non-database backend code (forwarding packets, feeding
> > streams, interfacing with other protocols) for Rails. We could start
> > building things like, the AIM/OSCAR plugin for Rails.
>
>
>
> If you accept that the event-driven) services engine is a distinct process
> or process group from Rails, then the glue that connects Rails to the
engine
> doesn''t need to know anything about EM at all. It can even be
RESTful calls
> using net/http. Rails will block and that''s ok. The backend will
not block.
> That''s the easy case. I wouldn''t touch DRb for this
because it doesn''t add
> any value.
>
> To support this, we should have a REST engine bundled into the EM package.
> Not a deep challenge.
>
> A more ambitious possibility is asynchronous messaging, which will need to
> have in EM someday anyway to interface with Java-based enterprise systems.
> For the Rails->EM problem, I don''t see immediate value to this,
though.
>
> Would this be a useful pattern to do something like an AIM/OSCAR plugin?
> (You''d probably need some kind of server push into the Rails app.)
>
> If you''re that Rails and EM should somehow both be running in the
same
> process, that''s a different question. I''m still not
seeing the value of
> that.
>
> More generally, I think it *should* be our ambition to make EM the platform
> of choice for services engines, whether or not they will run in conjunction
> with Rails.
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>

On 3/4/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> I''m not sure I follow the last part of your message. The only
reason
> you thread in an async application is to take advantage of hardware
> concurrency. Nothing ever blocks. There are also more reasons to build
> network code async than concurrency; for instance, look at what
> blocking connections and gethostbyname does to old web browsers.
I was mixing use cases in an unclear manner, and I wasn''t limiting my
thinking to only AR.  There are ORMs besides AR, and there are use
cases where one might have code that is not running insde of an
eventmachine loop, that uses a database, and that wants to somehow
make asyncronous calls to that database.

For example, a Nitro application using Og, running under Mongrel.

Going back and rereading what I wrote last night, though, I can see
how I was very unclear in what I was thinking.
> In any async engine, you can''t call ActiveRecord''s APIs,
because they
> all block on an external process and/or the disk. It doesn''t
matter
> how ActiveRecord is implemented under the hood. And the reason you
> want ActiveRecord is, it allows you to link a very fast network engine
> to a very slow, but very featureful web front end.
In my ideal world, I would have a way to increase the db query
throughput for both event based and threaded software that wasn''t tied
to a single ORM.  I want db actions to be less of a bottleneck than
they are right now.


Kirk Haines

On 3/4/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> If your project is to build a web app that can survive repeated
> Slashdotting on a single commodity server, then this conversation
> about alternative frameworks or evented Rails makes sense.
Bingo.  And that is where I live.  If speed is irrelevant, than many
of those factors that I listed as reasons why people use Rails gain
greater importance.

Piles of docs.  Hordes of people.  A defacto standard.  It makes
perfect sense, and I''d never argue that someone should abandon
something that is working well for them.

However, I''d would argue that any remotely decent framework should be
easy for people to come up to speed with, if they know the language.
I''d have no compunctions about hiring a Rails person to do IOWA work
for me, if I knew that they were also a decent programmer.


Kirk Haines

> However, I''d would argue that any remotely decent framework should
be
> easy for people to come up to speed with, if they know the language.
> I''d have no compunctions about hiring a Rails person to do IOWA
work
> for me, if I knew that they were also a decent programmer.
I''m with you, but would add, I have no compunctions about contracting
a Rails person who was barely even Ruby-literate if they could do a
good job wireframing and stubbing out an entire UI for me at a
commodity rate.

That person exists for Rails, but totally doesn''t exist for IOWA. =)

On 3/4/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
>  I''m with you, but would add, I have no compunctions about
contracting
> a Rails person who was barely even Ruby-literate if they could do a
> good job wireframing and stubbing out an entire UI for me at a
> commodity rate.
>
> That person exists for Rails, but totally doesn''t exist for IOWA.
=)


This argument makes complete sense for the (large and important) universe of
applications that don''t place stringent requirements on the front-end.
We
ought to have an answer for both that world, and for Kirk''s world.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/8c462501/attachment.html

On 3/4/07, Thomas Ptacek <tqbf at matasano.com>
wrote:
>
> REST is a nice answer to this problem, but just like with
> ActiveRecord, you''re not going to get ActiveResource for free,
because
> the Rails interfaces are too simplistic. If I understand REST well
> enough, the rationale is still to create RPC-style web services
> bindings to HTTP. Again we''re butting into that "RPC
Considered
> Harmful" paper from 20 years ago.
>
> But, yeah, what you''re saying makes perfect sense. Synchronous
Rails,
> high-speed EM engine, and the link between them is REST-style HTTP
> GET/POST; nothing needs to change in Rails, but we probably need some
> EM clientside work to make the XML POST less painful.
>
> Rails doesn''t support Tibco/SmartSockets/JMS-style messaging
anyways.
> I >heart< message APIs, and burnt up a huge wad of cash on a
messaging
> startup in the 90''s, but I don''t see the value add.
>
> I like the "Services Engine" branding!
>
> So, if I understand where this is going, we''re probably converging
on
> this answer to "how to use Rails with EventMachine":
>
> - Stick EM in another Ruby process
>
> - Have EM listen for HTTP requests
>
> - Use HTTP POST/GET to send stuff to EM from Rails
>
> - Use HTTP POST/GET to send results back to Rails


My primary rationale for suggesting REST as the pathway to the Services
Engine is so we can avoid making everyone reinvent a new protocol whenever
they do this. HTTP is as good as any, although XMPP might be interesting.
The goal is to have a Services-Engine plugin for Rails that would make
synchronous calls (since anything else is wasted on Rails anyway).

Eventually JMS or Stomp-style (or AMQP) interfaces should appear in the
Services Engine to connect it to the rest of the world. That will make the
SE the gateway from enterprise resources to Rails, and Rails won''t have
to
deal with those interfaces. (Saving the trouble of doing yet another thing
Rails won''t be good at.)

I''m prepared to second the motion of your manifesto! Anyone else?

Now, what about the XML POST massaging? Can you give use cases or a capsule
description of the problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070304/ef721200/attachment.html

> I''m prepared to second the motion of your manifesto! Anyone else?
There is also a need for just doing synchronous http request from
rails to outside services.  Several large ecommerce sites use the same
technique to grab data instead of hitting their databases directly,
with the backend service acting as an aggregator.  It''s a fairly
common technique once you hit a certain scale.

Chris

Just FYI, with a couple hours insomnia fueled hacking, I have a
Mongrel that runs inside an EM loop now.  Testing it now.   Seems to
work mostly as expected except that there are still a few
implementation details to clean up regarding limiting the size of the
header read, pushing large requests to tempfiles, and notifications to
handlers during the read process.

Still, for what it''s worth, after those items are cleaned up, anything
that runs under Mongrel (i.e. Rails, Camping, Nitro, Merb, etc...)
should run inside an EM event loop for free, with no changes to them.


Kirk Haines

On Sun, 4 Mar 2007 17:11:00 -0600
"Thomas Ptacek" <tqbf at matasano.com> wrote:
> But, yeah, what you''re saying makes perfect sense. Synchronous
Rails,
> high-speed EM engine, and the link between them is REST-style HTTP
> GET/POST; nothing needs to change in Rails, but we probably need some
> EM clientside work to make the XML POST less painful.
I''m confused, REST-style HTTP GET/POSTs don''t require XML.  I
wouldn''t use XML between EM and Rails, I think YAML/JSON (if at all)
would be better.  I think in the long run we''re gonna get away from
XML.

YAML or JSON both work, but XML is what the REST-style code in Rails wants.

On 3/5/07, James Robey <jrobey at stripemobile.com>
wrote:
> On Sun, 4 Mar 2007 17:11:00 -0600
> "Thomas Ptacek" <tqbf at matasano.com> wrote:
>
> > But, yeah, what you''re saying makes perfect sense.
Synchronous Rails,
> > high-speed EM engine, and the link between them is REST-style HTTP
> > GET/POST; nothing needs to change in Rails, but we probably need some
> > EM clientside work to make the XML POST less painful.
>
> I''m confused, REST-style HTTP GET/POSTs don''t require
XML.  I wouldn''t use XML between EM and Rails, I think YAML/JSON (if at
all) would be better.  I think in the long run we''re gonna get away
from XML.
> _______________________________________________
> 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:
>
> YAML or JSON both work, but XML is what the REST-style code in Rails
> wants.


You''re talking about ActiveResource, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070305/0287d988/attachment.html

On 3/5/07, Kirk Haines <wyhaines at gmail.com>
wrote:
>
> Just FYI, with a couple hours insomnia fueled hacking, I have a
> Mongrel that runs inside an EM loop now.  Testing it now.   Seems to
> work mostly as expected except that there are still a few
> implementation details to clean up regarding limiting the size of the
> header read, pushing large requests to tempfiles, and notifications to
> handlers during the read process.
>
> Still, for what it''s worth, after those items are cleaned up,
anything
> that runs under Mongrel (i.e. Rails, Camping, Nitro, Merb, etc...)
> should run inside an EM event loop for free, with no changes to them.

Wow. So that means you could execute an EM Deferrable or EM HttpClient call
within a Rails controller? Sounds very cool. Wouldn''t you still need a
lock
on the code that dispatches requests to Mongrel to keep it from issuing a
new request before the previous one completes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20070305/b2a0bca8/attachment.html

On 3/5/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> Wow. So that means you could execute an EM Deferrable or EM HttpClient call
> within a Rails controller? Sounds very cool. Wouldn''t you still
need a lock
> on the code that dispatches requests to Mongrel to keep it from issuing a
> new request before the previous one completes?
Yeah.  For Rails one would still have to employ a lock if one were
going to use Deferrable (and since this approach means that all of the
handlers run unchanged, the Rails handler would still be imposing it''s
lock anyway), but the threadsafe frameworks should all be fine.

I''ll try to get some simple tests put together for a couple of them to
test that theory.


Kirk

Well, yes, but also the REST scaffolding, which doesn''t stub out
respond_to for JSON or YAML.

For what it''s worth, JSON is a reasonable (wait: better) alternative
to XML, but as a "standard" solution YAML is almost deliberately
exclusionary --- you might as well just use Marshal. =)

Over a socket, I''d use Marshal. Over HTTP, I''d use XML, with
Builder. >shrug<.

On 3/5/07, Francis Cianfrocca <garbagecat10 at gmail.com>
wrote:
> On 3/5/07, Thomas Ptacek <tqbf at matasano.com> wrote:
> > YAML or JSON both work, but XML is what the REST-style code in Rails
> wants.
>
>
> You''re talking about ActiveResource, right?
>
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>