The plugin is still useful as I didn’t submit it’s session caching changes to Rails – essentially using Rails.cache for session storage rather than establishing a second connection to MemCache.  This also benefits from the local cache changes.

Where next?  In the next week or so I plan on updating the plugin by removing the local cache functionality to prevent any conflicts with Rails 2.3 when it’s released.

After that, I’m planning on working through the list of changes detailed under Future Plans in the plugins readme, also listed below.

• TESTS! (I wrote a bunch for the patch, just need to do that for the remaining session changes)
• Make this a Gem
• Conditional caching
• Multi-Get
• Dynamic key helpers
• Make the code more awesome

No related posts.

You’ve noticed that your app is doing a lot of repetitive work – calculating and showing the same data over and over again.  This doesn’t fit with your adherence to DRY principles at all.  If you cached repetitive responses your servers could give you way more bang for you buck – and it would only cost your time.

You are about to embark on an exciting journey fraught with hidden dangers, so let me prepare you – cheesy I know but hey.

First, you have actually done some code optimisation haven’t you?  Stopped using the default mysql config?  Checked your slow query log?  Used pl_analyise to parse your production logs?  Fixed the popular, but slow actions?  Done some eager loading so you get everything in a couple of hits from mysql rather than many many many little hits as your views render?  When you dream you see log tailing in the background?  Minified your javascript and css?  Static assets have expire headers?  Don’t have too many Mongrels running?  Sessions are stored in MemCache? Go do all that if you haven’t and only come back here if this are still too slow.  Oh and try to get your yslow score above 75.

Note: I’m assuming that you have read a bit about caching in Rails already and have had a play, reading fragments from actions etc…  If not try googling as there are a number of great articles on it, the Agile book is probably a good start too.

Start at the end

Instead of just saying ‘do this awesome thing’ I’m gonna explain how I’ve gotten to saying that, as you shouldn’t be making blind decisions about these things.  Most of the time when I implement caching for clients I completely skip page caching and action caching and go straight to line item caching, ie caching of small fragments of html.  Sounds completely counter-intuitive doesn’t it, but it’s not.

First off I need to define a typical client’s website so you see where I’m coming from.  It’s a user driven web 2.0 website – so most of the data is user generated and sometimes social networking elements are included, where a user’s data can be restricted to just their friends instead of being publicly available.  Basically the site lists stuff that people put on it.

Why not page or action caching?  As a starting point it’s too hard to manage due to the continually changing nature of the data being presented.  This changing nature means your cache might not actually get used that much.  Additionally when you are logged in your name is typically on the page with other unique to you info – you have x messages etc…  The latter reason completely rules out caching a whole page for anyone that’s logged in.  Don’t restrict caching based speed increases to joe public as logged in people, ie people that give a damn about your site, shouldn’t be second class citizens.

Don’t start with caching lists

Developers still want to jump straight in and cache lists of items (and pages too) rather than the individual line items – basically as much of the page as they can in a single hit – thinking they’ll get great bang for their buck.  When you deploy with that strategy you’re in for a world of hurt.  This is because they’ve not realised they need to take the following into account.

Each time one of the line items changes you have to expire the cache for the whole listing.  If you have pagination then you’ll likely have to expire ALL cached pages unless you can 100% reliably work out which page the item is on.  So yes you have a separate cache entry for each page of the listing.  If someone adds or edits a line item you have to expire the whole lot – and thats what people should be doing all the time on your site right?.  Additionally, if you allow sorting or a filtering mechanism you have to uniquely cache by page and the additional dimension(s), thus further reducing the frequency the cache will be used.

What’s the goal?

What we are trying to achieve with caching is to DRY up the execution of requests, but in a way that doesn’t add complexity.  The idea is to let your servers focus on the unique stuff like processing credit cards and telling Jill’s friends that based on her network and comment history she really doesn’t like doing things with Sarah unless Joe is there too.

Keep this in mind.  With seeking something to cache, you are basically looking for something that has a high ratio of renders/requests of the exact same html in between changes of that html.  So the more content in the cached fragment, the more frequently you’ll need to expire it.  Putting that another way, the fewer data sources, instances of models and display dimensions like pagination, sorting and filtering used to make up the cached html the better.  The simplest you can go is one data source, ie a line item.  Remember, keep it simple.

Put in business speak, it’s a cost / benefit decision.

It’s all about the keys

When you store fragments in your cache you name them with a unique string based key so you can access them later -  exactly like a hash.  So yes, they are important.  Typically they looks like a url, sort of based on the actual url or controller/action and the dimensions involved to make it unique to the html being cached.  So for the above listing situation the key should look something like this:

‘/products/list/sort=price/status=in-stock/page=1′

This actually presents a completely separate reason as to why you shouldn’t do list caching when you start out on this path.  The problem with this key is that to expire it you have to count the number of products to determine how many pages there are and then manually go and expire all possible keys that could have been generated, one at a time – this is because expiring via regex is not supported.  If additional dimensions are involved the problem will compound even further.

Yes, that’s real ugly and will become completely unmanageable.  There are some clever tricks to help out there such as self expiring keys, but that’s a different topic which I’ll get to at a later date.

When to expire

Wait there’s more!  You have to monitor data changes so you can expire those keys when they become stale as it doesn’t happen magically.  Normally you’d setup a sweeper (observer) and just expire things when ‘after_save’ is triggered.  Not a problem.  If you have data from multiple models involved in your cached html fragments then you need to monitor all the models involved.  You can go as far as only expiring particular keys based on the attributes that are changing etc… now much easier in Rails 2.1 with Dirty Objects.

This is all adding yet another layer of complexity.  Ugh.  It should all be documented so that other developers know about it especially new developers – otherwise further work could mess it up and you might start showing stale data to users.  In my book that’s pretty much on par with errors occurring as you could be showing the wrong price or even deleted data to users.  Unless you are careful about it, it can all become some really hard to manage mess which really isn’t going to give much benefit to your users.

Line item caching

As you are not having to worry about other dimensions such as pagination, sort order and filtering, other line items or even if the user is logged in or not, the line item’s cache key should be something like this:

‘/products/#{product.id}/line_item’

To make sure it expires correctly all you have to do is setup a sweeper watching the line item and simply delete it’s key when it changes – use Rails.cache.delete for this.  If the line item is rendered using data from through relationships, you then have to monitor them too.  I’ve seen people putting a ‘last_active_at’ field on a line item and when anything related to it changes they update that time field.  That works nicely and things are kept simple.

Finally

That should set you off in the right direction, remembering though this is a starting point for your first caching strategy.  Later on you’ll actually start doing multiple layers of caching and covering more complex html, such as lists, if your site continues to grow.

Now hopefully I’ve convinced you to start out with caching the html for a single line item – or something just as simple.  If not post a comment and tell me why not.

No related posts.

A enhanced version of and replacement for the MemCacheStore shipping with rails.  It uses a per-request local cache to buffer duplicate memcache reads which can result in halving read requests, and it uses a single connection to memcache for both the cache and session stores.

It doesn’t yet have the awesome key creation and maintenance library that I showed as that has evolved quite a bit and needs a big bunch of love first – which I’m working on.

There is now a dedicated page on this site for the plugin, currently it’s holds a copy of the plugin’s README.  My intention is to update the page with examples etc.. as I extend the plugin.

No related posts.