RailsWay 2009: Rails performance

Notes from RailsWay 2009 on perceived performance, HTTP caching, and Rails caching.

Published

2009-05-27

Reading time

1 min read

• #ruby
• #rails
• #performance
• #caching
• #conference

Perceived performance matters more to a user than an isolated application benchmark. These were my main notes from the talk:

• Use YSlow to find browser-facing performance problems.
• Send ETag and Last-Modified validators together.
• Send Expires headers where long-lived caching is safe, such as for batch-generated pages.
• Consider HTTP-cache tools such as Squid, Varnish, Akamai, and Rack::Cache.
• After exhausting HTTP caching, use Rails caching where application work remains expensive.
• Use fragment caching for expensive partials.
• Use action caching where a complete action response can be reused.
• Use model caching, available at the time through several plugins.
• Memcached can evict and rebuild entries, which makes the cache comparatively self-healing.
• Treat cache-key design as seriously as cache generation. A useful key combines a name, a unique identifier, and a version.

def handle_etag
  fresh_when :etag => [@user.id, @user.updated_at]
end

The following example uses Last-Modified explicitly:

def handle_last_modified
  fresh_when :last_modified => last_updated_time
end