mod_rails aka mod_rack aka mod_ruby

[Michał Jaszczyk]

Hi Grzegorz,

I'll try to defend the idea :).

2008/6/5 Grzegorz Nosek <grzegorz.nosek at gmail.com>:
> Hi Mike,
>
> (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.
>
> Agreed.

Cool :).

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

That's the problem with mod_wsgi too AFAIK. And what does Nginx do
when one of upstream backends takes too long to produce answer? It's
all the same, I think and the solution can be the same.

> Note that you'll also have to keep the interpreter state in sync between
> workers (shared memory?).

Disagreed. I assume the following: Temporary workflow data are kept on
one worker only and if this data has to be kept longer that for one
HTTP request, you can store them in the DB (not very good solution) or
in something like memcached (better). But it's more about how to do
clustering, not about how to run Ruby on Nginx, right?
>
> 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?

I kind of do, I'm doing that kind of stuff using mod_wsgi right now.
Anyway, I'm open to all feature requests :).

> Running a single interpreter may certainly be useful for dedicated
> servers but does not address all the needs of the real world.

What are those then?

> Also, how would you like to handle detecting code changes and reloading
> the application?
>
>> 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. :)

I use mod_wsgi in heavy production environment and it works just fine
:). The Python apps aren't very sophisticated, that's true, but anyway
:). So I think that if Manlio still wants to improve it, Django would
also work smoothly :).

So what do you think about the idea anyway? Are you for or against? :)

Apache is doing mod_php for PHP, mod_python and mod_wsgi for Python.
mod_rails for RoR has just transformed into mod_passenger for Ruby's
Rack/Rails AND Python's WSGI. So it seems like people need this kind
of stuff. So Nginx could also have such module, right? :)

Regards,

Mike