Caching is Hard
One part of code optimisation that is relatively easy is to cache the results of expensive operations. It’s really simple. CACHE.set. But it isn’t so simple. There are a seemingly endless possible ways the cache can be used improperly or otherwise fail. Handling these problems is the real work of caching.
The last checkout (around rev 250?) I did of Cache_fu (the acts_as_cached rewrite) it was pretty immature, chiefly in our need: An easy way to do arbitrary key names. n.b., I’m aware that there is a way but it seemed against the flow of this codebase. I use it, still, for the magic :all keyname.
But I need more, to store created JSON (To create what results in 100KB of JSON is a lot of objects and a lot of create time!) with a dynamic key in several distinct situations.
That round of caching improved API calls from 3 req/s to 300 req/s.
For the application most of the data can be cached but it needs to be done smartly: memcache server failures need to be handled (I suspect they are not, currently), server layout needs to be better (One daemon on each app server is not good, long term, IMHO), expiration of caches on data changes across the entire farm need to be smarter, deciding how long to cache data needs to be done.
CACHE.set and CACHE.get is really misleading; there’s a lot of things to consider!
I relish these challenges and look forward to solving them.
