Rails Caching (content vs. page/action/etc)

Question

What's content caching (like this plugin here: http://blog.codahale.com/2006/04/10/content-only-caching-for-rails/ ) vs page/action/fragment caching that Rails has built in?

I'd like to do caching on my Rails application, but I don't quite know which type to use. My application has mostly dynamic, user specific data on every page. Is caching even possible with this?

Answer 1

This guide provides a great overview of Rails' built in caching alternatives. But in summary:

---

Page caching: the first time a controller action is requested a copy of the entire generated page is written to a static .html file so that next time someone requests the same action it can be served by the web server without hitting your Rails application at all. This is super fast but has limitations eg a request for a cached page doesn't go via your application so you can't use filters to do authentication and restrict page access.

Action caching: the request always goes from the web server to your Rails application so that your filters run but if the request passes the filters and the action is cached then the cached copy is servered instead of actually running the code in your controller action. Limitation: the same cached content is served to all users so the page can't have any personalised data (such as showing the logged in username in the header)

Fragment caching: the controller action's code runs but within the view individual blocks of the page can be cached. eg if we have something in the sidebar that is computationally intensive.

---

The plugin that you linked to adds an extra layer of granualarity. The action content is cached but not the layout content so if the layout contains <%= curent_user.full_name %> for example then this will still be personalised for each user.

If you have lots of user specific data but it still stays constant per user for a reasonable period of time then you could look at caching at the ActiveRecord query level instead of at the view level.