mod_rails aka mod_rack aka mod_ruby

[Alexander Staubo]

On Wed, Jun 11, 2008 at 9:30 AM, Ed W <lists at wildgooses.com> wrote:
> Have a look at "Passenger" for apache - this kind of came at the problem
> from a different direction, but they seem to be building a mod_rack module
> in a roundabout kind of way.  Performance appears to be higher than mongrel
> with the added benefit that the host webserver is completely aware of
> queuing and can do much better load balancing and scaling up/down of cgi
> instances.
> All those other features are the main reasons for putting CGI straight into
> the webserver - anyone can simply proxy to a mongrel cluster...

Phusion Passender, aka mod_rails (http://www.modrails.com) is based on
the same principle as Lighttpd and mod_fcgi, where the web server
spawns Rails in multiple worker processes that are child processes of
the web server. The web server itself manages the lifetime of these
workers.

Unlike Lighttpd and mod_fcgi, however, Passenger optimizes memory
usage by forking every worker off a "spawn server" that preloads Ruby
and Rails, meaning that thanks to kernel copy-on-write, the worker
processes will share much of the code and data with the parent
process.

Since Ruby's garbage collector is not copy-on-write-friendly, these
guys maintain a fork of Ruby that's patched with a bunch of
copy-on-write optimizations.

http://www.modrails.com/documentation/Architectural%20overview.html

I think the idea of running an interpreter inside Nginx is ridiculous,
but having the web server spawn child processes is a good idea -- as
long as it's stable. My experience with using Lighttpd + FastCGI +
Rails for a year or so was pretty grim, but I'm sure it's technically
doable.

Alexander.