

The complete guide to caching with Ruby on Rails - aditya
http://ferric.net/articles/2009/02/22/caching-with-ruby-on-rails/

======
patio11
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.

~~~
aditya
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!

~~~
patio11
_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.

------
dennmart
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.

