The ZURBlog is where we discuss interaction design and strategy.

If you are running a Ruby on Rails app then you have an application that implements the checkout lines at the grocery store, metaphorically speaking of course. Rails ships with one of these applications called WEBrick. Most engineers know not to use WEBrick for production setups because it has only one metaphorical checkout line. One old lady has the potential to hold up the entire store.

If you're using Apache mod proxy with Mongrel then you have multiple lines, but people cannot choose the shortest line. Instead there is a minimum wage teenager named Ralph who assigns you to a checkout line by simply counting from 1 to n (where n is the number of check out lines). This method of load balancing is called round robin. While it's better then having one line, customers are still going to get stuck behind old ladies thanks to Ralph. So reason #1 to switch to Passenger is:

1. No more getting stuck behind old ladies

Passenger has a setting called UseGlobalQueue that is much more intelligent than Ralph. It puts all incoming requests in one queue and sends them one at a time to the next available worker. Your users will never get stuck behind the old lady at the grocery store (unless all your checkout lines get overwhelmed with old ladies, but we'll talk about that in another post).

2. Manage your workers like a boss

With Mongrel anytime you want to add or remove workers you have to edit two configurations files (httpd.conf, mongrel_config.yml), restart apache and your mongrel cluster. This gets to be a real pain when you are constantly adjusting the number of mongrels.

Passenger provides granular control over the number of active workers so you can feel OK about walking away from the keyboard to eat, sleep, or do whatever normal people do.

PassengerMaxPoolSize <integer>

This limits the total number of workers for your entire server. It prevents passenger from creating so many workers that you run out of system resources.

PassengerPoolIdleTime <integer>

Sets the time passenger will wait before shutting down idle workers. Allows you to set a short duration to maximize available resources, or a long duration to minimize the creation of new workers.

PassengerMaxRequests <integer>

If you have a memory leak, you should fix it. But in the meantime use this handy setting to restart the server after a set number of requests. Nice!

3. 60% Less Fat than Potato Chips

Or 33% less memory consumption when used in conjunction with Ruby Enterprise Edition. Plus you get many of the benefits of Ruby 1.9 without breaking all of your existing code and plugins because you upgraded to Ruby 1.9.

4. DHH told me so

You get an Apache that acts as both web server, load balancer, application server and process watcher. You simply drop in your application and touch tmp/restart.txt when you want to bounce it and bam, you're up and running.

Rails is no longer hard to deploy. Phusion Passenger has made it ridiculously easy.

-DHH

5. The maintaining team is named Phusion

Not only is their logo totally bad ass, but the website for Passenger and Ruby Enterprise Edition is well organized and packed with useful doc. This may sound trivial, but being able to quickly find answers without reading source code is a huge time saver.

For example, all the configuration settings for Passenger are clearly explained here. And If you're an operations engineer or admin I highly recommend reading the architecture document here. Seriously, check your twitter later, read this now.

Phusion is also actively maintaining Passenger which is critical since the Rails world is constantly in flux. Version 2.1.2 was just released with all sorts of goodies including support for Ruby 1.9 and Rails 2.3. Zed Shaw, the original author of mongrel walked away from the project last year and we have not seems significant improvements in his absence.

Face it, it's time to put down old yeller and make room for passenger.