How we setup Amazon Cloudfront to play nice with Rails 3.0.x on Heroku

Tue, 03 Jan 2012 21:23:30 +0800

As was mentioned in our previous post, we recently started using Amazon Cloudfront for our CDN needs. We wanted the performance benefits that we would gain from the move, we certainly didn’t want it to come at the cost of speed of deployment.

While the CloudFront custom origin server solution takes care of deployment, there is still the problem of expiring stale assets (especially Javascript and CSS).

As they say, the two toughest problems in Computer Science are caching, naming things and off-by-one errors.

Asset Fingerprinting

The problem of expiring stale content for CDN’s (and browsers) is solved by asset fingerprinting as part of Rails 3.1’s Asset Pipelining feature.

Every file in the app/assets directory in Rails 3.1 is “compiled” as part of the rake assets:precompile Rake task and the asset fingerprint is appended to the each file’s path and copied over to public/. The asset fingerprint is an MD5 digest of the contents of each file - so if a file is changed (for e.g. and image is changed or you change something in your CSS), the MD5 of the asset will change, and hence that particular asset will be ‘expired’.

The blog post that I referenced from the Open Government, uses the SHA of the most recent Git commit as the asset fingerprint. While that is a simple solution, it is quite inefficient. Think about it - any time you make a change to your site - (including model code or a change in a Rake task), your assets will be expired, even though technically the assets haven’t changed.

We don’t change our CSS/JS/images that often, but we do make changes to our business logic quite often (and deploy multiple times a day), so this solution won’t fly and defeats the purpose of the CDN, since content will always be expired.

Asset Fingerprinting without Sprockets

What we came up with is a better solution, which takes a digest of the entire public/ directory under Rails.root. It’s still less efficient than Sprockets’ asset fingerprinting, since in our solution the fingerprint is a hash of the entire directory and not each file. So even if you make a change to a single file, an unrelated file under the public/ will also be expired even if it hasn’t changed.

The hash of the public/ directory is stored in a file called assets.fingerprint under Rails.root, and is generated like this. (This is a function of a deploy Rake task which performs pre-flight checks such as these before pushing to Heroku)

We define a constant called REVISION which is defined in config/initializers/asset_fingerprint.rb thusly:

REVISION = File.read(Rails.root.join(‘assets.fingerprint’)).strip

…and in application.rb, the assets path is prepended with the hash as part of the path.

We also make sure that we use Rack::Rewrite to rewrite paths to the assets to ignore the hash and that the assets host points to the Amazon CDN.

Our entire application.rb is here for your reference: https://gist.github.com/1554090.

How moving to Amazon Cloudfront increased our App Store conversion rate by 250%

Fri, 30 Dec 2011 18:16:00 +0800

So as you may know, we’ve been working on Denso for a while now, and our primary source of marketing (after the initial wave of PR via Eduardo) has been our website. We post interesting videos once in a while to Hacker News, Reddit, Twitter and Facebook, thus generating inbound traffic.

The Hacker News story about Jon Stewart’s takedown of scammy iOS games generated a record number of visits to getdenso.com, but unfortunately, that number didn’t correlate well with the App Store downloads for that period. What we noticed was that our site appeared slow (even though New Relic indicated that our website stood up quite well against the onslaught) - and the reason was that our static assets (Javascript and CSS) were taking too long to load and would occasionally even 504.

This, was obviously, unacceptable.

We researched a bunch of ways on how we can improve the speed of the site, and naturally Amazon Cloudfront ranked very high among our options. But we needed a way for it not to interfere with our existing deployment strategy (which is git push heroku master). We chanced upon this excellent resource which basically gives a detailed tutorial on setting up a custom origin server on CloudFront. With Heroku, its not as straightforward as the Open Government tutorial makes it out to be - there will be another blog post coming up on the tweaks that we implemented.

Before and After

We switched over to our shiny new CDN solution on the 16th of December.

Before the 16th, our App-Store-downloads-to-web-visits ratio was hovering around 6-8%

After the CDN deployment, our App-Store-downloads-to-web-visits ratio is now a healthier 21-28%.

Moral Of the Story

Obviously the moral of the story is not for everyone to move over to a CDN. A lot of other iOS app downloads are probably not driven by their web cousins, so it won’t always make sense for you to optimize web performance.

Our biggest takeway is - run experiments, follow up on performance, try to find out root causes for weaknesses, and ruthlessly tackle them.

com.anideo.dev

How we setup Amazon Cloudfront to play nice with Rails 3.0.x on Heroku

How moving to Amazon Cloudfront increased our App Store conversion rate by 250%