Re: Ruby a good choice for CGI?

David Masover wrote:
> I'm confused. Wasn't mod_ruby the one which restarts the interpreter 
> with each
> request? 

That would be CGI. Each incoming request forks off a new CGI handler, 
which processes one request then terminates.

With the old mod_ruby, each Apache HTTP worker has an interpreter. If 
Apache decides to fire up 20 workers because it's handling 20 concurrent 
connections, that's 20 ruby interpreters. That may be wasteful if there 
are mixed ruby and regular HTTP requests.

Phusion Passenger keeps a pool of Ruby processes, independent of the 
httpd workers/threads, and picks a free worker to dispatch each ruby 
request into. This makes it similar in some ways to fastcgi, but it's 
much easier to set up.

> I also don't know of _any_ Rack handler that restarts the 
> interpreter
> with each request.

You can run rack as a CGI, I belive. You would not be advised to.

> something to do with Ruby Enterprise
> Edition.

That's the fork-friendly garbage collection. Passenger also prepares a 
preloaded ruby interpreter with your app and forks it when it needs to 
increase the size of the pool, rather than starting with a fresh ruby 
instance which would have to read all the libraries in. Advantages: much 
faster startup, and much more RAM sharing between ruby processes, so 
less total RAM used.

> I'm curious, actually... I get why people might choose thin (really 
> quick
> responses, so no real multitasking required -- keep it simple), mongrel 
> (old-
> ish and proven), unicorn (simple, reliable, prefork is proven), ebb (C 
> for
> speed, and threads may be more efficient than forking), etc etc.
> 
> I don't really see the case for Passenger over these, other than 
> simplicity of
> deployment. Am I missing anything?

Well for one thing, many sites are a mixture of static assets and 
dynamic content. It's much more efficient to serve the static assets 
from a webserver tuned for serving this sort of content, rather than 
serving your entire site from a ruby server.

For another thing, Rails is often still best run non-threaded. This 
means you need multiple worker processes. With mongrel/thin/etc this 
means running multiple servers bound to different ports, and that in 
turn means sticking a proxy of some sort in front, and having the bits 
and pieces necessary to start and monitor the required number of 
workers, and sorting out things like proxying the SSL variables.

I bought Ezra's Deploying Rails Apps book and built a system by 
combining Apache, pen, mongrels, monit and capistrano. It works, but is 
complex and a pain to add new apps. With Apache+Passenger it just works 
out of the box, is easy to tweak, is far simpler, and you get the REE 
memory sharing advantages too.

I don't really see the case for deploying Rack or Rails apps using any 
other approach, other than familiarity. Am I missing anything? :-)
-- 
Posted via http://www.ruby-forum.com/.