Julian Tescher Does The Internet so wow

Basic Rails API Caching

27 May 2014

Rails performance out of the box is acceptable for prototypes and small applications with limited traffic. However as your application grows in popularity you will inevitably be faced with the decision to either add more servers, or use your existing servers more efficiently. Complex caching strategies can be incredibly difficult to implement correctly, but simple caching layers can go a long way.

In this post I’ll explain two basic Rails caching mechanisms and explain some of the costs and benefits of each.

HTTP Caching

If your API responses are mostly static content like a list of available products, then HTTP Caching can be a very effective solution. Even something as low as a one minute cache can move the vast majority of your requests to a CDN like CloudFlare or an in-memory store like rack cache.

Specifying the expiration time is simple. In your controller action just call expires_in with the time:

class ProductsController < ApplicationController
  def index
    expires_in 1.minute, public: true
    @products = Product.all
  end
end

This will result in a header being set to Cache-Control: max-age=60, public which any CDN will pick up and serve for you instead of the request hitting your server.

This solution works well when the content is mostly static but it comes with the downside that changes to your content will not be seen for up to one minute (or whichever time you have chosen).

Conditional GET

Another option is using ETags or Last-Modified times to know what version of the resource the client has last seen and returning a HTTP 304 Not Modified response with no content if the resource has not changed.

To set this up in a controller you can either use the fresh_when or stale? methods. Here is an example using the fresh_when method.

class ProductsController < ApplicationController
  def show
    @product = Product.find(params[:id])
    fresh_when(etag: @product, last_modified: @product.created_at, public: true)
  end
end

This method attaches an ETag header and a Last-Modified header to every product response. Now if you make a request for a given product you will see the headers in the response:

curl -i localhost:3000/products/1.json
HTTP/1.1 200 OK
ETag: "91206795ac4c5cd1b02d8fcbc752b97a"
Last-Modified: Mon, 27 May 2014 09:00:00 GMT
...

And if you make the same request but include the ETag in a If-None-Match header, the server can return 304 with empty content and save all the time it would have spent rendering the content.

curl -i localhost:3000/products/1.json \
  --header 'If-None-Match: "91206795ac4c5cd1b02d8fcbc752b97a"'
HTTP/1.1 304 Not Modified
Etag: "91206795ac4c5cd1b02d8fcbc752b97a"
Last-Modified: Mon, 27 May 2014 09:00:00 GMT
...

The other option is to use the If-Modified-Since header in the request, which will have the same result:

curl -i localhost:3000/products/1.json \
  --header 'If-Modified-Since: Mon, 27 May 2014 09:00:00 GMT'
HTTP/1.1 304 Not Modified
Etag: "91206795ac4c5cd1b02d8fcbc752b97a"
Last-Modified: Mon, 27 May 2014 09:00:00 GMT
...

This method still requires a request to be made to the Rails app, and the product still has to be pulled from the database to determine the created_at time. However, rendering the response body can be a substantial portion of each server response so this is a simple way to save a lot of time.

These examples are only the beginning of the caching options Rails offers. As of Rails 4 page caching as well as action caching have been pulled out into their own gems and are worth looking at if you need those options.

Finally if you are ready for something a little more robust you can read about Basecamp’s Russian Doll Caching to see how they solve these problems.

Related Posts