Does unicorn work like phusion in that it automatically forks based on traffic levels?
Or is that what thin does also?
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?
I think puma just added in some new features along this line.
~Spaceghost
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.
