Phusion Passenger 3.2 Preview Released: Evented I/O, Python Support
Phusion has released a preview release of their upcoming 3.2 version of Phusion Passenger (also known as mod_rails). Passenger is the preferred way to run a Ruby web application on Apache, but it also works with nginx and even has support for Python. Version 3.2 comes with a re-written ApplicationPool, I/O handling is now event-driven and the Python support became a first-class citizen.
Passenger works by forking and pooling multiple instances of the deployed Ruby application. This addresses two problems of typical Ruby web applications: spawning new instances is slow, and they consume a lot of memory. The ApplicationPool handles this caching and pooling of instances:
One of the central subsystems in Phusion Passenger is the ApplicationPool, which spawns Ruby application processes when necessary and keeps track of them. It scales the number of processes according to the current traffic and it ensures that the number of processes do not go over your defined resource limits.
In 3.2 it has been completely re-written in C++, because they "have found that Ruby is not a good language for system software such as Phusion Passenger", resulting in a "much more concurrent and more fault-tolerant" system:
The new code is also much easier to understand and to maintain. This opens the road towards many potential future enhancements. 3.2 also supports multiple Ruby versions at the same time.
Request-response I/O is now handled event-driven using libev (for sockets and timeouts) and libeio (for file I/O) instead of multiple threads, dramatically increasing the amount of concurrent I/O (libev and libeio are also used by Node.js) and more:
It also opens the road towards future support for WebSockets, long polling and other mechanisms which require a connection socket to stay open for a potentially long time.
One of the best features in the new I/O handler is real-time disk-buffered response forwarding. [..] In Phusion Passenger 3.2, if the client is slow then we buffer the response data in memory, or to disk if the data is larger than a certain threshold. In contrast to most web servers we do not wait until the entire response has finished before forwarding the data; we do it immediately!
The third improvement they mentioned is WSGI support to run Python apps, which they say "worked, but wasn’t particularly good. [..] WSGI is now unofficially supported as a first-class citizen. Python processes are managed just like Ruby processes; all the resource limits, response buffering, etc. work exactly in the same way".