The complete guide to caching with Ruby on Rails | Hacker News Reader

The complete guide to caching with Ruby on Rails

ferric.net

50 pointsaditya4 comments

Its good for meat and potatoes description of how to use caching, but not complete by any means.

In particular it seems to not mention a lot of the gotchas: do you have a URL like /sales/report?year=2008 that you want to page cache? Gotcha! That is going to get saved at /sales/report.html and next time someone requests /sales/report?year=1952 they're going to get a report bitwise identical to 2008. Probably not the desired behavior.

The Rails Envy guys have an excellent caching tutorial on their site covering action, page, and fragment caching.

http://www.railsenvy.com/2007/2/28/rails-caching-tutorial

This predates the addition of Rails.cache in 2.1, so it doesn't cover that.

Fun stuff, though. I finally broke down and started using the memcached integration last night, as my new stats pages require repetitive expensive computations once for the page itself and once to produce the JSON for the FlashOpenChart on the page. It positively screams now.

Yep, I was trying to keep the guide short and to the point when the project began, and also more as the most updated version of all the crazy info out there.

I've added the caveat that URL parameters mess with page caching, but, the right way to do URL parameters is probably to make them RESTful and add a route. Except in the case of pagination, which isn't asking for a RESTful resource.

Anyhow, thanks for the feedback -- and would love anything else that I may have left out!

the right way to do URL parameters is probably to make them RESTful and add a route.

I respectfully disagree. REST just means interpreting an HTTP verb as a logical action, it doesn't mean we wage holy war against the heretical question marks. Query parameters remain useful for, e.g., allowing one route to take a number of optional parameters:

/sales/report?year=2008

/sales/report?year=2008&vendor_id=1

/sales/report?year=2008&vendor_id=1&expense_category_id=12

Now if all three of those parameters are optional, that is eight unique RESTful routes you'd have to write (map.sales_report_for_vendor_and_expense_category '/sales/report/vendor/:vendor_id/expense_category/:expense_category_id/'... times eight), which doesn't sound DRY to me at all.

This post is pretty informative. I also wanted to point out that Gregg Pollack and New Relic have been putting up videos in a 13-part series on the topic of scaling Rails.

http://railslab.newrelic.com/

Although the videos offer this information, along with 'live' examples so you can see what's going on with the different cachine mechanisms, I like having something written that I can use as a reference. This blog post is perfect for that.

Reply on news.ycombinator.com