Magento Caching Internals
Caching with Magento is a challenge. There are many classes and interfaces spread over the Magento core, the Varien lib and the Zend Framework. All those classes are used in combination and have their own set of methods and configuration parameters. Almost every class seems to have a load() and a save() method and even if they class name does not tell that, they have different purposes as cache frontends, backends, slow backends, fast backends or wrapper classes. I took some time to dig into all those classes and here is an overview on all those classes, how they belong together and how they are used.
Mage_Core_Model_Cache
Let's begin with Magento's model class. It's the class Mage_Core_Model_Cache. It does not inherit from any other class and is Magento API to the caching framework.
The object instanciated from this class is a property $_cache of Mage_Core_Model_App. (even if the comment at the property says it is from class Zend_Cache_Core. That's simply wrong).
The Mage_Core_Model_Cache has methods to handle cache operations (save, load, remove, clean) but only acts as proxy and passes all request to the cache frontend that is returned when calling getFrontend().
A confusing fact is that not this Mage_Core_Model_Cache wrapper class is returned when calling Mage::app()->getCache(), but its frontend:
class Mage_Core_Model_App {
public function getCache() {
return $this->_cache->getFrontend();
}
}
So basically Mage_Core_Model_Cache's cache methods are never called because everyone requesting the cache from Mage::app()->getCache() directly operates on the cache frontend.
Cache Frontends
The cache frontend ist the object, that receives all cache commands and controls the attached backend. The Zend Framework comes with a base class Zend_Cache_Core that contains the basic functionality and also offers some more frontends Zend_Cache_Core_* that inherit from this classfor special purposes. There is no interface defining what methods a cache frontend must have. All frontends need to inherit from Zend_Cache_Core.
Magento comes with a custom frontend in the Varien lib: Varien_Cache_Core. This class does only some little additions (mostly "tag"-related). This class is the class that every Magento code lines that uses the cache is communicating with.
Cache Backends
Now let's have a look to the cache backends. The cache backends are the classes that actually store your data somewhere and allow you to read them at some later point in time. For every storage type there is an own cache backend class and you can configure Magento (in local.xml) which one(s) too use in this specific installation.
Again we have some confusing elements: On the one hand there is an interface Zend_Cache_Backend_Interface that defines the basic cache operations the cache backend needs to implement. Additionally there is another interface Zend_Cache_Backend_ExtendedInterface that extends the previous one and adds some more feature definitions to the cache backend. On the other hand there is a base class Zend_Cache_Backend, that isn't abstract and also does not implement one of the mentioned interfaces. But still every cache backend must inherit from this class to be able to be used by a frontend. The interfaces are not used for checking the validity of a backend cache class.
Zend Framework comes with ready to use cache backends for
- apc (Zend_Cache_Backend_Apc),
- files (Zend_Cache_Backend_File),
- memcached (Zend_Cache_Backend_Memcached)
- and some more..
Magento adds two more for storing data
- in the database (Varien_Cache_Backend_Database)
- and for the eaccelarator (Varien_Cache_Backend_Eaccelarator).
Additional there is a special backend that is also supported by Magento and can be configured in local.xml: The two-level backend (Zend_Cache_Backend_TwoLevels). It allows you to use two other backends - a fast but small one (e.g. apc) and a slower but bigger one (e.g. files or database) - and handles all the logic to read and store data efficiently.
Problems and restrictions
Every cache backend has its specific behaviour and some cache operations are not always available or are really slow on some backends:
- Cleaning the cache by tag is very slow when using a file backend, because every file needs to be read to see if the cache entry is matching the tag. When having a lot of files in the file cache this might also block you some minutes from accessing the backend, because while a clean-by-tag operation will be executed during the login process.
- The file cache gets slow when it contians a lot of files. Try increasing the hashed_directory_level value.
- The apc cache backend does not support cleaning cache entries by tag at all. It simply doesn't do anything. Keep that in mind when you're using apc (also as part of a two-level cache setup) and expect cache entries to be invalidated immeditately.
- APC operations called from a command line environment (e.g. within a cron scheduler task) do not effect the cache in the frontend. Also cleaning the cache is not possible from cli.
- By default every entry that is read from apc will be written into it directly after when using it in a two-level setup. Switch off this behaviour with the auto_refresh_fast_cache option.
Additionally there are some more problems with caching. You'll find some solutions in my previous articles:
Recent Comments