Apache + Passenger -vs- nginx + mongrel

At Engine Yard, we’ve been receiving a lot of inquiries as to whether we support Passenger™.

This uptick in interest seems to be related to support and comments from DHH himself. We’re in 100% agreement and we’ve been living it for 2 years!

However, I think there are some issues that need to be discussed with respect to Passenger. I felt compelled to discuss them at this time due to this post to Twitter today.

First, if you’re running a single Rails application, Passenger in and off itself offers little advantage compared to other common deployment methods such as the nginx + mongrel stack that we’ve been using and developing for two years. It’s certainly not substantially faster or more efficient, thought it does offer simpler configuration, particularly so if you have access to a system where Apache is already up and running.

If you’re running multiple Rails applications, and are using Passenger’s ability to serve more applications than applications processes, you need to be aware of the performance of requests requiring an application process switch from one application to another. First requests are always slow, as a *lot* of code needs to be heated up, etc. Over ten years ago I learned personally that it’s far easier to manage static environments compared to dynamic environments for one simple reason: When things are changing dynamically, it’s hard to understand why things are behaving the way they are. The issues I’m discussing are generally acceptable in a situation where you have many low traffic applications, and you need to run those applications in a very limited environment. At Engine Yard, this is a very rare need for our customers, so this makes us less anxious to switch to something new -vs- something that is proven and works well.

With the additional of Ruby Enterprise Edition, however, it *does* offer the additional advantage of memory savings. Some of those advantages are lost by having to run Apache, which as commonly delivered, is considerably larger and less efficient than nginx. Of course, you can reduce these disadvantages by cuting down a custom build and tweaking the included modules, but once you’re headed down that road, the simplicity advantage has left the building. :-)

The reason that I felt compelled to respond to Pratik’s Twitter post is that it entirely ignores a few issues that prevent Engine Yard, and no doubt other companies from immediately supporting Passenger™ and/or Ruby Enterprise Edition.

First, Engine Yard uses 64 bit environments to allow our customers the highest performance virtual machines and access to large memory spaces when needed. Just today Phusion has introduced a version that should fix these issues. Before *today*, Engine Yard *could not* support this combination, it’s just that simple, no FUD intended.

Second, our customers choose Engine Yard for experience and expertise in hosting Rails applications. At this moment, we have no experience or expertise in Passenger™. That is a fact.

All in all, I think that Phusion’s Passenger and Rails Enterprise Edition products are interesting. So interesting, in fact, that we chose to investigate the same basic strategy with respect to Rubinius. I’m not yet certain that a substantially patched version of the Ruby source code, maintained independent from the core team, is something that can be supported in the near term, though it’s clear from the drumbeat and experiences of users that the trajectory is looking good.

I’m certainly hoping and encouraging the Ruby core team to work with Phusion to accept their GC patches into the mainline.