For an introduction to caching with Rails, check out this post: Caching With Rails: An Overview

The Appearance That Caching Works

Here is what I mean by giving the appearance that caching is working:

1. you add caches_page :index to your controller, for example
2. configure and restart your server
3. load the index page
4. check your rails cache directory on your server, and see the index.html
5. it works! (hint: this step is wrong, you’re not quite there yet)

Just because Rails is generating your cached page does not mean that your server is subsequently serving the cached .html file instead of sending the request to Rails again.

Ensure It’s Serving the Cached Page

To make sure it’s subsequently serving the cached page, the easiest method is to look at the created date on the cached file on your server, for instance:

You will get an output similar to this:

Now wait a minute, and then reload the page in your browser. Once again type ls -l myapp/public/cache, and make sure that the file still shows the same created date/time. If it instead shows this:

…then you have a problem. Your server is sending every request back to Rails, where Rails is then re-generating the cached page.

Alternative 1: You can also use Apache’s RewriteLog to watch what is being served. Just add this to your site’s .conf file and then tail -f the rewrite_log:

Alternative 2: You can also use the top command to watch your running processes and make sure the rails process doesn’t rise to the top while reloading your page. This is obviously not very scientific, though, and won’t work if you have any external traffic on the site.

The Solution: Proper Server Configuration

Happy caching! For more tips for getting the best performance out of your server, check out Performance Tuning for Phusion Passenger (An Introduction), and How to Monitor Your Rails/Passenger App with Munin.

Update: Proper Nginx Configuration

For extra completeness, thank you to atambo on Hacker News for pointing me to this proper configuration for Rails caching on Nginx. You can read the comments for an explanation.

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.