Caching thoughts

I've previously written something about caching and it complexity. A short while ago I've heard from Bergie about interesting facts about memcache and also been bitten by it first hand.

It seems that with bigger sites with current MidCOM caching philosophy and level of atomicity are getting more heavier than just serving pages without any cache. It seems that if Memcached is heavily punished and if there's lots of keys in it it start so slow down and also reliability goes down. Basically it means that you don't always get data from cache or be able to store it in there resulting some database punishment and you can imagine what happens next.

This comes again to MidCOM 3 and the way caching should be handled there. I've taken a close look about how Zend Framework does it. They are useing tags as possible cache identifiers. Basically MidCOM's cache works quite same way but in fact every cache entry get's autotagged by lots of guids. So that is basically the problem.

One possible solution that I've pondered would be to give developer some additional tools to control caching in controllers. There could be some hint's for cache's level like if it's same for all users or per user basis. This helps caching to be done more intelligent way

But in addition to this there should be a concept for cache invalidation logic. In some cases you need more atomicity than others and the problem was with too big guid indexes. What if developer has in addition to tagging possibility to attach some callbacks to tags. Basically it means that you have possibility to call cache invalidation per tag but then those callbacks could do some logic whether or not tag entry really needs to be invalidated.

That would enable us to diminish the size of guid cache, put some intelligent invalidation where needed. Bit heavier process it is but if it's lighter than getting data and rendering it, then it's worth to explore.