Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Rails - etags vs. page caching (file cache)

What would be some advantages of using etags/stale?/fresh_when? instead of page caching (on a file cache)?

Apache automatically handles etags for static files, but even if it didn't, page caching would still be better since the Rails app doesn't even get called.

So, in what instances would I use the methods provided by Rails (stale?/fresh_when?)?

like image 569
Ivan Avatar asked May 06 '09 22:05

Ivan


2 Answers

They are really complimentary. Etags/fresh_when etc. help you play nice with downstream caches (like your own Varnish/Squid instances or Rack::Cache or the Browser cache or ISP Proxy Servers…)

Page caching saves you from hitting your rails stack entirely because Apache/your webserver serve the file, so no DB lookups are done. But you have to deal with cache expiration to keep the cache fresh.

Using etags/conditional get, you don't save much processing time since you still need to to get all the records used on the page:

def show
  @article = Article.find(params[:id])
  @feature = Feature.current
  fresh_when :etag => [@article, @feature] 
end

in the case that the user has a current page, it saves you some rendering time and the bandwidth required to send down the page.

like image 144
gerrit Avatar answered Oct 25 '22 10:10

gerrit


Another use that occurred to me was that you could still process some information before letting Rails hand out the "304 Not Modified" header. Like if you want to record hits to a page.

like image 37
Ivan Avatar answered Oct 25 '22 11:10

Ivan