Well, as some of you know, I've been working on improving the caching system for Joomla! 1.6. So far, I've made some interesting progress and would like to share some quick tidbits with you on it...
3 "Levels" of caching
New in this branch, is the idea of having a more granular choice than just on and off. Now, there are 3 options in global configuration.
- Disabled - Disables all caching
- Enabled Default Off
- Enabled Default On
All areas of the core that have a caching option now (yes and no in 1.5), have been replaced with 3 options, "On, Default, Off". This will allow an administrator to choose which level suits him/her best (either enabling it globally and disabling where it's not wanted, or disabling globally, and only enabling where it's wanted).
Module Position Caching
Since we have module parameters that have a caching flag in them, it becomes trivial to then cache an entire module position (tied to Itemid and access level). It will only cache an entire position if all modules under it are cachable. Since position caching uses a "Validate On Store" method of caching, if a position is cached, none of the modules/module parameters need to even be loaded! This cuts about an additional 5 to 10% off the load time when caching is enabled (based on initial tests).
Advancing the Cache Plugin
In 1.5, we were given this beautiful cache plugin which cached entire pages for us. While it really can speed up a site, it does have some limitations. One of these is that you cannot disable page caching for specific pages/menu items. This basically leaves you with an "all or nothing" approach. Something I've done to get around this, is added a pair of menu item parameters which allow you to change cache behavior on a per menu item basis (enable/disable caching of page, as well as alter the lifetime of the page cache). Since the plugin uses "Validate On Store", there is no performance hit to a cached page for this lookup.
About "Validate On Store":
Validate On Store is a caching philosophy I've used extensivly. Basically, the way validate on store works, is you determine if your item is cachable when you store the item in the cache (if it's not cachable, don't store it). That way, a cache read doesn't need to worry about parameters and all that overhead; if the item exists in the cache, it must be cachable! This method can have some minor performance penalties if you have a very high miss rate (most items are not cachable), but the gains to be had with a moderate to high hit rate (most items are cachable) are huge.
That's where I'm at for now
I'll keep updating the progress as it goes...