Alfa Jango Blog Engineering, Software, and Entrepreneurship

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.

(more…)

In my last post, I discussed why it’s becoming increasingly important to ensure your website loads quickly for users (and Googlebots). At the end of the article, I mentioned a quote from Yahoo!’s article, Best Practices for Speeding Up Your Web Site:

80-90% of the end-user response time is spent downloading all the components in the page: images, stylesheets, scripts, Flash, etc. This is the Performance Golden Rule.

In other words, you can get the most “bang for your buck” when it comes to page load optimization by speeding up the loading of your site components (a.k.a. “assets”, such as javascripts, CSS stylesheets, images, etc.). In this post, I’ll discuss the 3 main techniques used to improve asset load speed.

Asset load optimization often results in a reduction in asset-load-time by 75-90%. Since asset-load-time accounts for 80-90% of your total page-load-time, this equates to an overall reduction in page-load-time by up to 80%!

Below are graphs showing the load time of RateMyStudentRental.com before and after (respectively) implementing the asset-optimization shown here. Using Google’s Speed Tracer extension, we can see that total load time decreased from 40 milliseconds down to 15ms.

(more…)

We recently worked on a Rails application that had page and action caching set up, only to find that it was not actually working. It occurred to me that many Rails/Passenger/Apache applications may have caching set up in a way that it appears to be caching, when it is not actually caching. Searching through the interwebs for various Passenger/Apache configurations, such as this snippet on Github or this discussion on Google Groups, I found that many did not work with the most recent version of Phusion Passenger. What’s more, these configurations give the appearance that they are working.

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:

(more…)

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.

(more…)