Phusion Passenger App Server Gains Node.js Support
Phusion Passenger, a popular web application server originally targeting Ruby, now supports Node.js apps. The feature was introduced in the Enterprise edition of Passenger earlier this year, but has been open sourced as of the recent 4.0.21 release of the free version.
Passenger integrates with the Apache or Nginx web servers, and aims to be a complete solution for serving, monitoring and scaling web applications. The benefits cited by Netherlands-based Phusion of running Node.js apps under Passenger include:
- Multitenancy – the ability to run several apps with minimal configuration
- Supervision – automatically starting Node.jd processes, and restarting them if they crash
- Scaling – increasing and decreasing the number of processes depending on the amount of requests being handled
- Statistics – tools that help expose running processes' status
The Passenger authors also point out that integrating with Apache/Nginx brings benefits like accelerated static file serving and protection against many common attacks and slow clients.
The announcement is a step towards Phusion's self-professed goal of making Passenger "the ultimate polyglot app server". Last year, Passenger's Python support was raised to beta status, and as of recently is considered complete. On the heels of the Node.js announcement, Phusion also unveiled support for Meteor, a Node-based app framework.
Passenger itself is written in C++, and is not tightly coupled with Ruby or any other language. With the release of version 4, several architectural changes were made. Passenger's internal I/O handler is now event-driven, similar to how Node.js works, and the Enterprise edition supports hybrid multiprocessed and multithreaded execution, which is meant to maximize resource usage while allowing features like live streaming over WebSockets.
For Ruby apps, Passenger also provides features like "out of band" execution, which allows for example garbage collection to be deferred until between requests, and integration with Phusion's Union Station product, a subscription-based app monitoring and analysis service.
Among popular Ruby app servers, Puma is similar to Passenger in favoring threading over the evented architecture of servers like Thin and Unicorn. The Phusion team recently published a comparison between Passenger and Puma, with Puma author Evan Phoenix posting a response on HackerNews.
InfoQ spoke with Phusion's CTO, Hongli Lai, about the recent updates to Passenger.
Passenger offers Ruby users unusual features like out-of-band execution, which tightly integrates with the language runtime. Are there similar benefits for Node.js and Python users?
Most features are available for all supported languages, including Node.js and Python. Since day one, we've minimized the dependency on Ruby. Just a few months after the first release, we already supported Python, though this fact wasn't actively marketed. We currently also have Meteor support planned for the next release.
There are only a few features which are not available for Node.js and Python, either because they don't make sense for those languages or because they require simple language-specific support code which hasn't been written yet. Node's and Python's garbage collectors generally don't suffer from long GC pauses like Ruby's does, so we don't expect Node.js and Python users to need out-of-band work.
How stable do you consider Node.js support to be at this point?
We consider it stable. All our test applications pass, all our testers' applications work fine, and there are no known issues.
Passenger's original goal was to make Ruby deployment as simple as PHP deployment, just requiring users to drop their apps in the right directory. Do you think Passenger has delivered on that promise?
Deploying an app involves everything from provisioning the operating system and language runtime to managing library dependencies and supervising the application process. One of the reasons PHP is so easy to deploy is that the web server takes care of running PHP applications automatically through a module, mod_php.
Back when Passenger was first developed, running, supervising and administering Ruby applications was a major pain. You had to run multiple application server processes, let them listen on a local socket, set up the web server to reverse proxy to this cluster of sockets, and set up process supervision tools to restart crashed processes. With Passenger, we solved this part by developing a similar mechanism to mod_php. So in version 1.0, we had already achieved our goal: running a Ruby app by dropping it in the right directory.
The reason that the PHP ecosystem is still perceived as easier to deploy is that many popular PHP applications automatically take care of more than just running the app. For example, Wordpress has no dependencies, does not require the user to edit config files and asks for database credentials through a nice graphical user interface. But if you write your own PHP apps, you will run into the same issues that people writing Ruby, Node or Python apps face.
Do any hosting companies actually offer Passenger out of the box?
High-profile hosting companies that offer Passenger out of the box include Amazon Elastic Beanstalk and Red Hat OpenShift. Most other providers, like Heroku, tend to be agnostic towards the choice of app server, but still allow the user to easily use Passenger. There are also many smaller hosters that use Passenger by default, like BrightBox and SpeedyRails
There are several strong contenders in the Ruby app server space (Thin, Unicorn, Puma). What do you see Passenger's place in the ecosystem as being at this point?
The other app servers for Ruby are more limited in scope than Passenger. They require that the user start one or more processes, set them up to listen to sockets, configure reverse proxy rules, etc. This is not necessarily the wrong aproach for experts who want tight control over the entire system, but it is different from our philosophy. We like software that is simple to install, use and administer while still being stable and flexible.
Having said that, we've all learned a lot from each other. For example, Passenger's "smart spawning" feature predates Unicorn's, while Passenger's out-of-band work feature is based on that of Unicorn, though we've improved on that feature as well. Each server has its own strengths and weaknesses.
Uwe Zdun, Rafael Capilla, Huy Tran, Olaf Zimmermann Mar 09, 2014
Olav Maassen, Liz Keogh & Chris Matts Mar 08, 2014