It’s just data

Tasty Rails Caching

Tim Bray: This matters if your Web app is maxed on some combination of CPU and database, and a noticeable proportion of requests don’t really need a page-rebuild, and your existing caching and last-modified setup isn’t getting the job done.

While I agree with that, I claim that the potential benefits are much more than that.  Much more.  Furthermore, the upcoming Simpler Conditional Get Support is not the only arrow in Rail’s quiver, and not always the best one.

But let’s back up.  One concrete use case for ETags is feeds.  On many servers, feeds don’t change all that often, but are requested very often.  And are requested by very many distinct users.

The approach coming in Rails edge is very welcome, but won’t help much in this case.  Every request will hit the Ruby process.  Every request will hit Rails code.  Every request will (in all but the most degenerate cases) hit the database.  And if a different user requests the same data that you just served up, that exact same representation will be recomputed anew.

If the types of loads you are expecting to deal with are shaped like the typical load profile for feeds, then there are other techniques that will reduce the CPU and database load more substantially.  Page caching will avoid the database, will avoid Rails, and will avoid Ruby entirely for the bulk of the responses to GET requests targeting resources that change much less frequently than they are requested.  Even if the requests come from different users.  And you will get all the same bandwidth savings ETags.

But if this approach isn’t for you, approaches that don’t get the bandwidth savings (but can easily be combined with the Simpler Conditional Get Support) include Action Caching and Fragment Caching.

None of these approaches are as simple as recomputing each and every response if this particular client hasn’t seen the absolute latest representation of the resource in question — and then throwing away that response entirely and starting over with the next user.  Each of these alternatives require managing a cache.  But Rails doesn’t leave you completely on your own on this matter.  With Sweepers you can get a call back on each database operation that may potentially affect the staleness of your cache.


[link] [comments]...

Excerpt from ruby: what's new online at

Database triggered sweepers can cause massive pain if you have any actions that monkey with multiple objects at the same time (especially if they’re cleaning up cached pages). However, Controller/Action triggered sweepers can make life a good deal easier, but it can make for rather too tight coupling as well.

Posted by Piers Cawley at

Enterprise Java

Jim recently blogged about what Enterprise worthy means to him. I agree fully with what he says, if Ruby had the same level of infrastructure that Java does, it might be considered enterprise worthy, just like Java. This won’t happen for a very...

Excerpt from Kick me in the nuts at

Add your comment