Comments on: Client HTTP Caching in Rails

By: Dan Kubb

Dan Kubb — Wed, 21 Nov 2007 03:14:03 +0000

Since this article was published a new plugin called restfully_yours has appeared. It provides a nice clean way to handle Conditional GET within your Rails app.

By: Morning Brew #10

Morning Brew #10 — Thu, 24 May 2007 11:06:09 +0000

[...] Status 304 - send HTTP 304 instead (another take) [...]

By: Ilya Grigorik

Ilya Grigorik — Fri, 23 Mar 2007 02:40:01 +0000

Yeah, I guess that’s true. Come to think of it, even my solution might result in a DB hit with Edge rails and ETag support. I wonder if you can bypass the filter?

By: SRobertJames

SRobertJames — Wed, 21 Mar 2007 18:16:14 +0000

>James, you can take advantage of full ETag support by switching to edge rails. It’s committed and working..

I think Edge Rails will still hit the DB, just not the network… your solution skips even that.

By: Ilya Grigorik

Ilya Grigorik — Wed, 21 Mar 2007 16:21:06 +0000

James, you can take advantage of full ETag support by switching to edge rails. It’s committed and working..

In terms of testing, check out this article by Yahoo guys: Performance Research

By: SRobertJames

SRobertJames — Tue, 20 Mar 2007 19:45:33 +0000

Thanks for this post. Did you ever get etag / if-match / if-none-match working?

Also, is there any simple way to test that browser’s are actually using the cache?

By: Ilya Grigorik

Ilya Grigorik — Tue, 20 Mar 2007 01:55:55 +0000

James, that could work for some apps. Most applications have a layer of ‘personalization’ that makes external caches impractical. If you avoid personalized content, then yeah that could work! In fact, then your suggestion is the ideal case - i.e. just throw some memcached servers between apache and your app server, or get apache to do all the work by itself.

By: SRobertJames

SRobertJames — Fri, 16 Mar 2007 20:14:22 +0000

Perhaps the best approach is to have Rails support etag/ conditional get, and not cache anything itself - and then turn mod_cache on in Apache.

Push the cache storage layer to the web server - keeps the app simple. And Apache’s the expert on HTTP.

By: Ilya Grigorik

Ilya Grigorik — Fri, 16 Mar 2007 15:19:23 +0000

Yep, that’s exactly what I’m thinking. If the DB query is extremely expensive, you could even have a separate sql query:

select created_at from ...

Then you could compare the ETag flags and decide where to go from there. In this case, 7580 could be very useful.

However, I certainly don’t want to make it sound like ETag / Conditional-Get is the way to boost your performance. Any form of an additional caching layer should blow this technique right out of the water. However, even then, conditional-get can serve as a nice fallback technique for cheap optimization. For example, if you can’t cache every single query in memory (limited size), some items will be periodically removed from the cache and have to be re-executed. Hence, cache layer fails, but ETags could take over and tell the client to use the local copy.

By: Dan Kubb

Dan Kubb — Thu, 15 Mar 2007 20:45:16 +0000

Ilya, good catch — I mistyped that, but I couldn’t change it after I submitted it.

Changeset 7580 is great, and I think if you’ve got to actually perform the action and its associated DB work, then setting your own ETag and making use of this is the way to go.

I’ve been thinking that if there was a way for you to “register” the models you’re going to use in the view, you could extract their lock_version and created_at values (assuming they exist) to automatically set the ETag and Last-Modified headers. This would skip rendering of the view and make good use of what 7580 provides.

Still, action_cache is going to blow this technique out of the water (and page caching even more so) since it happens before the action is even run, but it may not always be practical. The earlier in the request chain you can determine if the browser cache is still valid the better the performance will be.