On Thursday, February 7, 2013 9:34:26 PM UTC+1, Gitted wrote:
Does unicorn work like phusion in that it automatically forks based on
Or is that what thin does also?
At present, and as far as I know, Phusion Passenger is the only *working*
server that supports forking more worker processes based on traffic.
Apache's FastCGI module is supposed to be able to do that, but it's broken
in various ways so nobody uses it.
As others mentioned, Unicorn is single-threaded, multi-processed. It cannot
adjust the number of processes automatically based on traffic, but require
you to command it to do so.
Thin is a single-thread, single-process, evented server. It does not fork
worker processes for you at all, and does not manage worker processes like
Unicorn and Phusion Passenger does. Since Rails and most Ruby frameworks
are not very suitable to the evented I/O style of programming, one
usually needs to run multiple Thin processes in parallel to achieve
concurrency. The number of processes is defined by the user, and can be
adjusted while Thin is running, but not automatically based on traffic.
Puma does not support forking more worker processes based on traffic
either. That's because Puma is a multithreaded server: it creates threads,
not processes. I do not know whether Puma can create or shutdown threads
on-the-fly based on traffic, but since threads are lightweight there is
relatively little advantage in adjusting the number of threads on-the-fly
compared to adjusting the number of processes.
Phusion Passenger Enterprise has, and Phusion Passenger 4 will, introduce
all kinds of new features that you may be interested in. Phusion Passenger
4 *also* support multiple threads, on top of supporting multiple processes.
It will allow the user to choose the I/O model, number of threads and
number of processes. Here's a short comparison between Phusion Passenger
and Unicorn/Thin: http://news.ycombinator.com/item?id=5097667
 I mention this for completeness sake. There are ways to get around it,
e.g. using fibers, but I dislike that solution because I think they're
error prone and can introduce concurrency issues worse than even
multithreading. With fibers you still have to worry about concurrency but
now you suddenly don't have mutexes anymore that can help you. You have to
be very careful about where to yield, and also where *not* to yield.