David Masover wrote:
>> *and* ongoing management and tuning - it handles dynamic pools of
>> processes for you
> 
> So does Unicorn, or maybe I'm not understanding.

http://unicorn.bogomips.org/

From reading this, and the FAQ/Philosophy, it sounds like you configure 
it with a *static* sized pool. They advise you to spit out the request 
as quickly as possible into a buffering reverse proxy, so you can get 
onto handling the next request - then you scale your app to the 
available CPU resources, rather than to the number of concurrent 
clients.

That's a reasonable approach for many apps, whatever server you deploy 
them under. OTOH that won't work for apps which return large or infinite 
streams.

Also, as far as I can tell, to use Unicorn properly requires you to use 
nginx (at least, I don't know if apache can proxy to a unix domain 
socket, and the documentation doesn't seem to mention apache)

On the plus side: you do get very fine-grained control of the 
deployment.

Anyway, it's always good to have alternatives. Projects come and 
projects go, and it's comforting to know there are things to migrate to.
-- 
Posted via http://www.ruby-forum.com/.