From: Brian Candler Date: 2009-11-26T07:17:05+09:00 Subject: 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/.