mod_rails aka mod_rack aka mod_ruby
grzegorz.nosek at gmail.com
Thu Jun 5 19:01:00 MSD 2008
(sorry for raining on your parade ;))
On Thu, Jun 05, 2008 at 04:22:44PM +0200, =?ISO-8859-2?Q?Micha=B3_Jaszczyk_ wrote:
> Well, speed, hopefully.
> And lower memory/cpu/etc consumption.
Disagreed. You'll have to keep a Ruby interpreter in every nginx worker
process. Also, a Ruby script may block indefinitely (e.g. waiting for a
database or an external resource, or simply sleeping just to piss you
off), so you'll either need to run many more workers (negating the
benefits of the evented programming model), or intercepting sleeping
calls to plug them into the main event loop (might be impossible to do
in a general way and anyway is non-trivial).
Note that you'll also have to keep the interpreter state in sync between
workers (shared memory?).
Another approach would be to spawn a pool of interpreters communicating
with nginx via some pipes but now you've got a sort of in-process proxy.
> And it
> may be easier to create an app an run it under Nginx instead of
> configuring Mongrel, proxying etc. Also a bit less things to take care
Do you envision the possibility of running several independent
applications (keeping state between requests but not mixing e.g. two
vhosts), each under a different UID and with specific rlimits and stuff?
Running a single interpreter may certainly be useful for dedicated
servers but does not address all the needs of the real world.
Also, how would you like to handle detecting code changes and reloading
> of. Basically, reasons for mod_ruby are the same as for mod_wsgi.
AIUI, mod_wsgi isn't a universal module but is mostly useful for
embedding rather simple Python code into nginx.
I remember asking Manlio some time ago about it and he said (more or
less) that embedding e.g. Django via mod_wsgi would be pretty insane,
so I think it would hold twice as true for e.g. Rails.
Of course, I'd like to be proven wrong and hopefully Manlio will step in
to correct me. :)
More information about the nginx