Ruby on Rails

So I’ve been thinking lately that I should scrap this blog. I so rarely use it any more - instead using my work blog, Twitter, Facebook, Flickr and UncleTomCobleyAndAll.com. Most of the traffic is to a few old posts, whether it’s to the simply_helpful plugin whose functions are now built-in to Rails 2.x, or long-forgotten memes.

Maybe I’ll do something new with this place. In time.

For now, on the subject of expiration, I’m linking to this comment at the base of a post about Rails’ different caching methods, and their expiration techniques.

One very useful way to avoid the dog pile is to expire behind. Similar to a write behind cache, on checking a ttl and finding the content expired, still serve up the stale content for that request, but also asynchronously start rebuilding the content via a queue/background worker. If you randomize your ttl’s a bit this results in very even system load.

To me, this makes great sense, especially in the context of an application I’m working on at the moment. So I’m linking it here not so much so I can find it again, but in the hope that the concept’ll permeate into my subconscious as I’m coding.

Tagged as: action cache, cache, fragment cache, rails, ruby, ttl

{ 0 comments }