Rails caching presentation

Posted by Scott Laird Wed, 28 Sep 2005 15:53:57 GMT

I gave a short talk on caching with Rails last night at the Seattle.rb meeting. The short version is “the page cache is going to hurt a lot worse then you’d expect,” but anyone who read my previous article on caching should already know that. I did the slides for the talk with S5, which was new to me–I had planned on using Keynote, but it seems to have died in the year and a half since I last had a use for it. S5 worked well enough, although there were some formatting issues that kept popping up as the browser window size changed. By and large it was easy to use, and it’s nice to have a HTML version of the talk that doesn’t look like a nasty afterthought.

About halfway through preparing for the talk, I realized that I really need to add a new action cache option, something like caches_action_with_params, so we can explicitly say how query strings and other parameters affect the cache. Here’s a bit of sample code:

class ArticlesController < ApplicationController
  caches_action :index
  caches_action_with_params :read, :id
  caches_action_with_params :permalink, :year, :month, :day, :title

  def index
    @pages, @articles = paginate(
      :article, 
      :per_page => config[:limit_article_display], 
      :conditions => 'published != 0', 
      :order_by => "created_at DESC"
  end

  def read  
    @article = Article.find(
      params[:id], 
      :conditions => "published != 0", 
      :include => [:categories])    
  end

  def permalink
    @article = Article.find_by_permalink(
      params[:year], 
      params[:month], 
      params[:day], 
      params[:title])
  end

  ...
end

At least as of Rails 0.13.1, calling /articles/read?id=10 will create a cache entry for /articles/read, which is wrong, and then asking for /articles/read?id=20 will return the cached entry for id=10. Yes, the user is supposed to use routes for this, but explicit query params still work, and there are times when you really need to use them. Fortunately, this is really only 20 lines of code, so it shouldn’t be too hard to write.

Tags caching, ruby, rubyonrails, typo | 2 comments

Comments

nuke edit
topfunky said about 1 hour later:

Great talk last night, Scott. Clear, focused, and relevant.

It would be nice to see some hard stats on the benefits of caching, since some large sites such as 43things don’t use it (they use memcached instead). Maybe that really needs to be done case-by-case since its part of an overall optimization strategy.

At any rate, it would be much more useful if some of these small (but significant) problems were solved.
nuke edit
wac said about 3 hours later:

Yeah, I second the need for some objective numbers about page vs. action vs. fragment vs. memcached and other stuff. On the other hand, everyone has their own needs (and agenda).

At least some of the tool choice also has to do with what the sysadmin is familiar with. If you’ve used apache httpd or lighttpd or memcached or reverse squid or some other tool before, you’re more inclined to go back to it in the future, rather than exploring alternatives. And that’s back to the “do only what you know you immediately need and do that right but quickly” approach.

Switching from apache-prefork to apache-worker was a bit of a leap for me, just due to “if it ain’t really broke, don’t fix it” inertia, even though was ample reason to do so earlier.

RSS feed for this post

Comments are disabled

scottstuff