Forum: Ruby on Rails does unicorn fork like phusion?

Does unicorn work like phusion in that it automatically forks based on
traffic levels?

Or is that what thin does also?

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

I see, so is phusion the only one that automatically grows to meet 
demand?


On Fri, Feb 8, 2013 at 2:27 AM, Frederick Cheung 
<frederick.cheung@gmail.com

I think puma just added in some new features along this line.

~Spaceghost

I think these posts might help you Gitter:
http://stackoverflow.com/questions/4113299/ruby-on...
http://tomayko.com/writings/unicorn-is-unix

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: http://news.ycombinator.com/item?id=5097667

[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.