Fragment caching is used for caching various blocks within templates without caching the entire action as a whole. This is useful when certain elements of an action change frequently or depend on complicated state while other parts rarely change or can be shared amongst multiple parties. The caching is doing using the cache helper available in the Action View. A template with caching might look something like:

  <b>Hello <%= @name %></b>
  <% cache do %>
    All the topics in the system:
    <%= render_collection_of_partials "topic", Topic.find_all %>
  <% end %>

This cache will bind to the name of action that called it. So you would be able to invalidate it using expire_fragment(:controller => "topics", :action => "list") — if that was the controller/action used. This is not too helpful if you need to cache multiple fragments per action or if the action itself is cached using caches_action. So instead we should qualify the name of the action used with something like:

  <% cache(:action => "list", :action_suffix => "all_topics") do %>

That would result in a name such as "/topics/list/all_topics", which wouldn’t conflict with any action cache and neither with another fragment using a different suffix. Note that the URL doesn’t have to really exist or be callable. We’re just using the url_for system to generate unique cache names that we can refer to later for expirations. The expiration call for this example would be expire_fragment(:controller => "topics", :action => "list", :action_suffix => "all_topics").

Fragment stores

In order to use the fragment caching, you need to designate where the caches should be stored. This is done by assigning a fragment store of which there are four different kinds:

  • FileStore: Keeps the fragments on disk in the cache_path, which works well for all types of environments and shares the fragments for all the web server processes running off the same application directory.
  • MemoryStore: Keeps the fragments in memory, which is fine for WEBrick and for FCGI (if you don’t care that each FCGI process holds its own fragment store). It’s not suitable for CGI as the process is thrown away at the end of each request. It can potentially also take up a lot of memory since each process keeps all the caches in memory.
  • DRbStore: Keeps the fragments in the memory of a separate, shared DRb process. This works for all environments and only keeps one cache around for all processes, but requires that you run and manage a separate DRb process.
  • MemCacheStore: Works like DRbStore, but uses Danga’s MemCache instead. Requires the ruby-memcache library: gem install ruby-memcache.

Configuration examples (MemoryStore is the default):

  ActionController::Base.fragment_cache_store = :memory_store
  ActionController::Base.fragment_cache_store = :file_store, "/path/to/cache/directory"
  ActionController::Base.fragment_cache_store = :drb_store, "druby://localhost:9192"
  ActionController::Base.fragment_cache_store = :mem_cache_store, "localhost"
  ActionController::Base.fragment_cache_store = MyOwnStore.new("parameter")
Show files where this module is defined (1 file)
Register or log in to add new notes.
May 31, 2010
4 thanks

Naming fragment cache

One of the common ways of using fragment caching is to cache content that’s shared across the site (eg. left navigation, menus, widgets etc.) that looks and works the same regardless of the name of the action or controller calling it. In such cases it’s very easy to just use named fragment caching eg.:

<% cache('left_nav') do -%>
  <%= display_left_nav -%>
<% end -%>
August 24, 2013
1 thank

expires_in option

@concept47 do you really need to check the fragment in the controller?

ActiveRecord will execute the query when its used

cars = Car.where(:colour => 'black') # No Query
cars.each {|c| puts c.name } # Fires "select * from cars where ..."

“Lazy Loading” - http://m.onkey.org/active-record-query-interface

October 2, 2013
0 thanks

You have explain well

You have explain well about fragment caching as I was in need of this information. http://autobodycarparts.com

August 15, 2013 - (v3.2.1 - v3.2.13)
0 thanks

expires_in option

You can actually pass in an expires_in option that sets how long Rails should show the fragment before deleting it so as an example …

<% cache('homepage_sidebar', :expires_in => 10.minutes) do %>
<% end %>

This only used to work with memcached but it now works with other types of Rails stores, MemoryStore, FileStore (had to use a plugin to get this behavior before) etc etc

So in your controller. You’d just do …

@posts = Posts.all if fragment_exists?('homepage_sidebar') 

to avoid performing a pointless SQL query.