This is Article #4 of a 4-part series. For a good primer, check out the first two articles listed below. For the reasoning and analysis behind the “Recommended” option in this article, check out Part 3, How to Combine GZip + CDN for Fastest Page Loads. Otherwise, jump right in!

• The Importance of Page Load Speed
• Improve Page Load Speed (by 80%) by Improving Component Load Speed
• How to Combine GZip + CDN for Fastest Page Loads
• Caching, Zipping, and (Amazon CloudFront) CDN For A Rails App
  • Prerequisites
    1. Cached stylesheets and javascripts
    2. Creating an Amazon AWS Account
  • Setup S3 Buckets
  • Setup CloudFront Distributions
  • Create CNAME records (optional)
  • Install Rails S3 Synch Plugin
    1. Installing AWS-S3 Gem
    2. Configure S3 Synch Plugin
    3. Add S3 Synch to Deployment
  • Option A: Compressible Assets from App Server, Images from CloudFront (recommended)
    1. Configure Rails Asset Host
    2. Create A-name Record
    3. Configure Apache
  • Option B: Serve Everything from CloudFront (easier, but not recommended)
    1. Configure Rails Asset Host
    2. Pre-compile Cached Stylesheet and Javascript File
  • Conclusion

In this article, we’re going to speed up our Rails application by up to 75%, simply by optimizing our Rails asset host. We’re going to serve our components (stylesheets, javascripts, images, etc.) from a combination of our app’s server and Amazon CloudFront (Option A, recommended), or entirely from CloudFront (Option B – easier).

The best option for you may depend on your specific needs, but I’ll cover both processes below. For a an in-depth analysis of why Option A is recommended over Option B, see the last article in this series, How to Combine GZip + CDN for Fastest Page Loads.

Prerequisites

Cached Stylesheets and Javascripts

Another way to reduce page load time is to combine all of your components into as few files as possible. In other words, combine all of your stylesheets into a single css file, and likewise with your javascripts. Remember from the last article, that each request takes 50-150ms, not including the response and download time. If you have 10 separate javascripts, this equates to 0.5-1.5 seconds just to request the files (not to mention all the time to download them). If you can combine all of the files into one, that means you need just one request to get the same amount of data.

Luckily in Rails, this is easy, simply add :cache => 'cached-file-name' to your stylesheet_link_tag and javascript_include_tag in your application layout. For example:

Now, as long as the following line is set to true in your environment.rb, or more likely in production.rb, Rails will either load your combined files in the layout, or create and load them if they don’t already exist.

Simply packing all stylesheets and javascripts into one file each reduced page load time of one of our production applications from 10.1 to 8.3 seconds (an 18% reduction in load time alone).

Creating an Amazon AWS Account

If you do not yet have an Amazon AWS account, you will need to create that and enable S3 and CloudFront services. See this writeup on creating and setting up an Amazon S3 account. for helpful instructions.

Setup S3 Buckets

Once you’ve signed up for your Amazon AWS account and activated S3 and CloudFront, you’ll want to setup 4 S3 buckets for your application, using Amazons S3 management console.

We’re going to setup 4 buckets and CDN distributions because some old browsers still have an artificial limitation that only allow 2 concurrent connections to each domain, meaning our components will take longer to download from Amazon if they can only be downloaded 2 at a time. By creating 4 different domains pointing to 4 different buckets/distributions, we’re allowing our components to download up to 8 at a time from those browsers that still enforce this limitation.

Setup CloudFront Distributions

Once your S3 buckets are created, click over to the CloudFront tab and create one distribution for each S3 bucket as shown. You can type any comment to help you quickly identify each distribution.

Create CNAME Records (optional)

Once you’ve created your 4 CloudFront distributions, you may create a CNAME record for each distribution. This allows you to serve files from CloudFront using your own asset subdomains, like cdn0.yourapp.com, instead of raNDomString1234.cloudfront.net. We’ll use the following format of cdn%d.yourapp.com, where %d stands for digits 0-3:

Install Rails S3 Synch Plugin

This plugin adds some Capistrano recipes to synch our application’s public directory with our four S3 buckets automatically every time we deploy our app. See Spatten Design’s documentation for more information. I’ve made some updates to their original plugin to properly set the Cache-control and Expires headers for our assets on S3, as well as to properly set the Content-encoding header for Gzipped assets.

Update: I’ve updated the S3 Synch Plugin further; it can now handle unique S3 buckets for different Rails environments (e.g. one set of buckets for production and another for staging). Be sure to update your synch_s3_asset_host.yml file as shown below.

Installing AWS-S3 Gem

The synch_s3_asset_host plugin requires the AWS-S3 gem, so add the following to your environment.rb:

…and then run the following from the terminal to install the S3 Synch plugin’s gem dependency:

Configure S3 Synch Plugin

Create a config/synch_s3_asset_host.yml file like this:

Update: The “production” part in the file above has been added for my latest update of the S3 Asset Synch Plugin.

Add S3 Synch to Deployment

Now, in your Capistrano deploy.rb script, add the following line to the :deploy namespace:

…and then add the :asset_host_syncher => true flag to the :web role:

Option A: Compressible Assets from App Server, Images from CloudFront (recommended)

For more detail about why this method is recommended, see the last article in this series.

Configure Rails Asset Host

Use the following configuration in your production.rb file to configure the way Rails writes the URLs for asset_tags:

Create A-name Record

We will also need to create an A-name record for the cache.yourapp.com subdomain, which points to your application server’s IP address.

Configure Apache

Now we need to configure Apache to accept incoming requests to our “cache” subdomain, setting the appropriate far-future Expires and Cache-control headers. We also need to tell Apache to automatically compress and serve any compressible filetype on the fly. Add this to your site’s Apache conf file:

Now we need to make sure the appropriate Apache modules are enabled and restart Apache.

Option B: Serve Everything from CloudFront (easier, but not recommended)

For more detail about why this is not recommended, see the last article in this series. Basically, though, it’s because it requires you to make one of the following compromises:

• a) Serve all files uncompressed, resulting in file sizes up to 4x bigger than necessary.
• b) Serve Gzipped assets from CloudFront without first detecting whether or not the visitor’s browser support Gzip encoding.

That being said, if this is acceptable for you, this method is simpler to set up and configure.

Configure Rails Asset Host

Add the following to your production.rb:

Pre-compile Cached Stylesheet and Javascript File

If you’re serving every component from CloudFront, you will need to pre-compile your stylesheets and javascripts on every deploy. Otherwise, Rails will try to compile and save the files to your application server, but try to serve them from S3 (where they won’t exist).

To solve this, we’ll add some Capistrano scripts to our deploy.rb to compile our files for us before the synch_s3_asset_host plugin copies our public directory over to our S3 buckets. But this means, we’d have to copy the list of asset files to be compiled into our Capistrano script, as well as having them listed in our application.html.erb layout. To DRY things up a little, we’re going to create some project-wide constants:

lib/assets_for_cache.rb

And then replace your javascript_include_tag and stylesheet_link_tag in your application layout with the following:

Add this to your deploy.rb script:

…and then add this to the :deploy namespace in your deploy.rb file, before calling the s3_asset_host sync script:

Conclusion

Now simply save your project and deploy it! The first deploy will take quite a while, as your entire /public directory will be copied to all 4 buckets on Amazon S3, one at a time. But after that, it’s a painless process.

Whether you chose the “recommended” or the “easier” option, you should immediately notice a significant increase in the performance of your Rails app. Thanks for sticking with me through this 4-part series! Please let me know if you have any thoughts, questions, or feedback in the comments.

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.