The scope of this document is a first draft of improvements to the JCache class introduced in Joomla! 1.5.
1.2 Objective of the document
The objective is to give a basis for a discussion about an extension/refactor of the JCache class for Joomla! 1.6.
1.3 General remarks
This proposal is based on the functionality of JCache in the Joomla! 1.5 stable versions.
- Cache - Server side storage of data
- Storage Handler - Actual method of storing cache data
- Cache Handler - Class that abstracts caching layer (ex: callback caching)
- Cache Helper - Class that works between cache handler and caller (ex: module caching)
- Cache Hit – Data is stored in the cache, and is returned
- Cache Miss – Data is not stored in the cache, and the lookup fails
- Primed Cache – Common used data exists in the cache.
2. What is the current functionality of JCache
JCache currently can be broken down into two parts, the cache handler and the storage handler. This allows JCache to function independent of the type of cache handler or storage handler used.
JCache currently checks cached items for validity (including time to live calculations, and whether to cache an item or no) on fetch. This involves loading parameters for the item prior to fetching the item from the cache (if it exists).
3. What are the proposed improvements?
3.1 Addition Of JCacheHelper Classes
JCacheHelper classes will abstract cache related solutions unique to different areas of the core. One example of this occurs with modules. Some modules never change output on the entire site, whereas others change depending on the page. JCacheHelperModule would generate 2 cache ids for each module (one for the current page, and one that's site wide. This would allow caching of modules and module positions if the modules do not change.
3.2 Addition of Additional Cache Handler Classes
JCacheRaw will provide direct access to the cache so an extension can send raw data to the cache. This would allow an extension to handle the id and data generation on its side for abstract use. This would be useful in such areas as JRegistry to cache internal variable data.
JCacheObject will provide storage for instances of objects. The variables passed to the handler would be class name, and any constructor arguments. This will allow the caching of objects such as JUser, JLanguage, and JACL.
JCacheQuery will provide a mechanism to cache the results from queries. As parameters, it would accept the query string, the expected result set as a string (the function to call in the JDatabase object), and the known lifetime if it exists (for queries dependant on publish times, this would be stuck to around 60 seconds). The handler would check the cache to see if the result exists. If it does not, it executes the query and stores the result.
3.3 Change of JCache Methodology
Validation will occur when data is stored in JCache. This includes any time to live or enabled calculations. This is because a cache request is significantly faster than the time it takes to build the parameters needed to determine cachability. The tradeoff is that every load results in a check to the cache regardless of if the item is cacheable. However, a cache hit will be significantly faster than the current validation check.
3.3.2 Extending Validation
Validation will be able to be extended by the individual extensions (in the case of view and page handlers). This allows for disabling caching (or adjusting TTL) of items before they go into the cache. This will be realized by attaching a callback to the cache class. When JCache validates data (before storing it), it will call the callback and adjust the validation results before storing the data.
4. Technical Realization
4.1 Core Changes
Every place in the core that has data that could be cached would need to be altered to use the new system.
4.2 Global Parameter Additions
New global parameters would need to be added that would disable or alter the TTL for their respective cache items (For example, to disable page caching for a specific menu item).
4.3 Module Parameter Additions
New Module parameter (or xml definition) would be added which would define whether the module changes depending on the page or not (such as a menu module changing the active menu item versus a newest content module).
The current framework for Joomla 1.5 and 1.6, while being quite powerful and flexible, can be significantly slower than past and competing technologies. The core needs aggressive caching with a robust system which will compensate for the added weight of the framework.
6. Effects on...
Proper implementation should have no negative effect on users
6.2 3P extensions
While these changes should have no negative effect on extensions, they should allow for an easier to use, and more flexible cache system.
6.3.1 Cache Disabled Globally
There should be no effect on performance when the global cache is disabled
6.3.2 Global Cache Enabled, Not Primed
A request for an item which is not in the cache should be no slower than the current implementation (since the same steps are taken, just in a different order).
6.3.3 Global Cache Enabled, Primed
A request for an item which is in the cache should be significantly faster than the current implementation due to the elimination of loading the parameters and checking the validity of that item.
6.3.4 Global Cache Enabled, Local Cache Disabled
When caching is disabled for specific items (such as a module), it will be a little bit slower than the current implementation due to the additional check for cache data (the cache is still checked, but never stored for a disabled item).
6.4 System Requirements
Due to the fact that aggressive caching can significantly lower the respective load on a server, a physical server should be able to serve significantly more requests with the proposed improvements.