Phusion Passenger (aka mod_rails) allows for easy and scalable deployment of Ruby on Rails applications on Apache or Nginx servers. Part of what makes it so easy is that it comes with suitable default settings right out of the box, so that you don’t need to concern yourself with any of the details when deploying your application to production.

However, once you’ve launched your application and people start actually using it, you may find server experiencing excessive swapping once the traffic begins to pick up. Before getting too deep into scaling, caching, upgrading your server, etc., there are a few Passenger settings you can tune to wring out the best performance your existing stack. I’ll address these settings with a few rules of thumb we’ve gathered from the Passenger documentation and simple trial-and-error.

Before getting started, we highly recommend employing Munin (instructions for Munin with Passenger here) and NewRelic Performance Monitoring for your Passenger/Rails application, so that you can fine-tune your settings for the best performance.

Note: the following settings are specific for Apache, you will need to modify the syntax/file-names for Nginx.

Per-server Settings

These settings are set per-server, meaning if you have multiple applications running on the server, these should be set only once throughout all of your .conf files. If you have only one Rails/Passenger app on the server, then you may set these in that application’s .conf file. On Ubuntu, this may be found at /etc/apache2/sites-available/yourapp.conf.

A more appropriate place for these however would be in Apache’s .conf file.

PassengerMaxPoolSize and PassengerPoolIdleTime

/etc/apache2/apache2.conf:

You can essentially copy and paste this into your apache conf file. I’ve added some notes in there to help you remember how they should be tuned.

PassengerMaxPoolSize: This is the number of Passenger instances that can be spawned at once for your site. This basically relates directly to the amount of RAM that is available to your application. However, it is not a linear relationship. It’s more of an exponential relationship. Numbers that we and others have found to work well are:

Since this depends on available RAM, this will vary depending on what other processes are running on your server, such as MySQL, etc. If you have Munin installed with the Passenger plugins, you can monitor the Passenger Memory Stats and Passenger Status graphs to tweak this as necessary.

PassengerPoolIdleTime: This is essentially the amount of time (in seconds) that each Passenger instance continues to run after it becomes idle (i.e. someone stops clicking around the site). According to the documentation, this should be set to the average time a visitor views a page multiplied by 2. This of course prevents Passenger instances from shutting down (and thus having to re-spawn) while someone is viewing a page.

If your application has been in production long enough to have a few hundred viewers and you have Google Analytics installed, an easy way to get the ideal setting for your application is to take the Average Time on Site, divide by the Average Page Views per Visit, and multiply by 2.

PassengerMaxInstancesPerApp (optional)

If you do have more than one Rails/Passenger application on the server, you may optionally set PassengerMaxInstancesPerApp.

PassengerMaxInstancesPerApp: This is the maximum number of instances each application may use of the total PassengerMaxPoolSize. Therefore, PassengerMaxInstancesPerApp must be smaller than PassengerMaxPoolSize.

For example, if you have 2 applications running on one 256MB server, you may want to set PassengerMaxInstancesPerApp to 1, so that one app may never hog all of the rails instances at the expense of the other app. If you have 2 applications running on a 512MB server (PassengerMaxPoolSize 6), then you may want to set cci]PassengerMaxInstancesPerApp[/cci] to 4 or 5 to allow each app to better handle higher load (hopefully while the other app is under less load).

RailsAutoDetect

To get a little more performance out of your server, you can also turn the RailsAutoDetect setting of Passenger off. This will make it so that each request through Apache does not check to see if it is a Rails request that requires Passenger. However, this will now require that you explicitly tell Apache which requests are Rails and do require Passenger, using RailsBaseURI. This is easy though.

Again, in your apache2.conf file:

Now, within your the Vhost block in your site’s .conf file, you will need to set the RailsBaseURI:

Here is a complete example of the Passenger block in your apache2.conf file:

And a simple sites-available/yourapp.conf may look like this:

More Passenger Configuration Settings

These settings so far only scratch the surface of Passenger configuration. Give the Passenger documentation a good read-through for more information on configuring Passenger.

Further Reading: Apache Settings

At this point, if you still need to squeeze more performance out of your server (and you will eventually), you’ll want to configure Apache to utilize its resources most efficiently with Passenger. I recommend reading through this thread on the Slicehost forums to get a good idea just how much trial-and-error this will take. Keep a close eye on your server when you tweak these settings, you may end up making it slower several times before finding that sweet spot.

You may read the documentation for each setting in the Apache docs (note that these are the Apache 1.3 docs, but they still explain purpose of each setting well). For more information using these settings to reduce the RAM consumed by Apache, see this other Slicehost forum and this blog post on saving RAM with Rails and Passenger.

If you’re impatient and just want to get something better than default, here are some numbers that worked well for us on a recent application running on a 256MB VPS on Slicehost. These settings can be found in your apache2.conf file.

Tags: Apache, memory, mod_rails, passenger, performance tuning, server, swap

This entry was posted on Monday, March 1st, 2010 at 8:54 am and is filed under Apache, Rails, Ruby, Web. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.