| As explained in the article, our Out-of-Band Work mechanism is more general and more flexible. The most important points are: - Unicorn's mechanism is limited to garbage collection. Phusion Passenger's allows any arbitrary work. - Unicorn's doesn't work well with multithreaded apps, Phusion Passenger's does. - Unicorn's doesn't spawn additional workers. In certain situations it can happen that all workers are busy garbage collecting. When Phusion Passenger encounters such a situation, it will spawn an additional worker. Phusion Passenger guarantees that, while performing out-of-band-work, there are at least PassengerMinProcesses processes ready to process any requests. Phusion Passenger 4 also introduces features not found in Unicorn and Thin: - Support for multiple Ruby interpreters inside the same instance. But to be fair Unicorn and Thin are designed to be run in a different way so this may or may not be an advantage for you. - JRuby support. - Python support, and in the future more languages. - Real-time disk-backed response buffering, first introduced in 4.0 beta 1. Unicorn relies on web server buffering which tends to buffer the entire response before sending it to the client. Phusion Passenger 4 allows you to use Rails 4 streaming with ease, without blocking the server on slow clients, with good performance and without configuration. - Phusion Passenger Enterprise supports multithreading. Unicorn is strictly single-threaded multi-processing only. Phusion Passenger 3.x also supports these features that Unicorn and Thin do not support or do not support in the same way: - Dynamic number of workers. - Rolling restarts (as implemented in Enterprise) are more automated than in Unicorn. - Deployment error resistance (Enterprise feature). - Live IRB console (Enterprise feature). Phusion Passenger also provides commercial support. I wrote this response quickly so I may have missed some things. If anybody spots any inaccuracies, please let me know. |