Does unicorn work like phusion in that it automatically forks based on
traffic levels?
Or is that what thin does also?
I see, so is phusion the only one that automatically grows to meet
demand?
On Fri, Feb 8, 2013 at 2:27 AM, Frederick C.
<[email protected]
I think puma just added in some new features along this line.
~Spaceghost
On Friday, February 8, 2013 4:34:26 AM UTC+8, Gitted wrote:
Does unicorn work like phusion in that it automatically forks based on
traffic levels?
No - with unicorn you have a set number of workers (although you can
change
this by sending the appropriate signal to the master process)
Fred
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
traffic levels?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[1], 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: As explained in the article, our Out-of-Band Work mechanism is more general and ... | Hacker News
[1] 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.