Caching and Rails

2009-03-25

Here’s the slides from my AOR talk last night: Caching, Memcached and Rails (600KB).

I was a little unhappy with my wrapup – the one thing I wanted to teach people was when to use each different caching mechanism provided by Rails and I didn’t really revisit and summarize that content. So here’s a quick summary:

• HTTP caching – prefer this over all other mechanisms. This is really the only mechanism that prevents the request from ever hitting Ruby. This topic is big enough for a book so I won’t cover it here but review the Expires, Etag and Cache-Control headers to understand how HTTP caching works. You’ll need to configure Varnish, Squid, mod_cache or some other HTTP caching proxy.
• Page caching – I believe this is really legacy from before Rails supported HTTP caching properly. Stick with HTTP caching and proper headers.
• Action caching – useful when the entire page contents can be cached but you need to run before_filters (e.g. to ensure the user is logged in). Use AJAX/javascript to do minor customization to the cached content.
• Fragment caching – useful when various boxes of content on the page can be cached, but have different dependencies and need to be expired at different times
• Object caching (the Rails.cache.fetch method) – the most granular mechanism. Good for caching the results of intensive logic or queries.

I hope this helps demystify the myriad of caching mechanisms Rails supports. If you want to learn even more, Gregg Pollack has an amazing set of videos on Scaling Rails which covers caching in great depth. Happy Caching!