Some time ago I wrote about some changes to make large catalogs more performant. Today a second batch of changes got committed (sorry, forgot to push, though!).

What does that mean?

First of all, this was in collaboration with a developer facing issues with a large database, in particular categories. So, talking to me does occasionally help getting your problems solved faster!

Secondly, there is now a new interface ZMSavantCache and a also a simple implementation class thereof. There is also sample code of how to configure Savant to use the cache class and how to configure the cache class itself.

All there is to do is:

1. Change the bean definition of the default view class to set the caching implementation to be used
2. Set up a new setting that lists all the template filenames (for example: ‘boxes/categories.php’) that can be cached
3. Done!

Eventually this should be the default setup with some reasonable defaults (perhaps with a more sophisticated cache implementation, though).

This template file level caching is a great way to complement the existing page cache plugin. In the above example of a catalog with thousands of categories, caching the categories box cut of about 4 seconds of processing (measured inside a VM, to be fair).

In addition I finally managed to get APC working on my dev environment (Windows, go figure…), so there is also a shiny new APC cache implementation to go with that

And, again, all that just because someone started asking questions and suggested solutions and patches.

You are welcome.

One of the perhaps less known services in ZenMagick is caching. ZenMagick knows two types of caches:

• transient
  This type of cache exists for the duration of the request. Some services use this kind of caching, for example the product service. That allows the service to re-use already loaded products should they be requested again to increase performance.
• persistent
  This type of cache will exist across multiple requests. As with all caching it might expire at some stage without warning.
  One good example of persistent cache usage is the page caching plugin.

For each type different implementations might exist, even though only one can be active at a time. The defaults for each type are:

transient -> memory

persistent -> file

To change the mapped implementation the setting cacheMapping can be used. For example, this line would change the persistent cache implementation to memcached:

ZMSettings::set('cacheMapping', array(MCache::PERSISTENT => 'memcache');

Currently, memory is the only transient cache type implemented, while there are a couple alternatives for persistent caching: memcache, xcache.

To add a new provider, you’ll have to implement the interface ZMCache and then register the new type following the example above. The name  of the cache and the class name (and also filename) follow this simple rule:

Name: foo

Class: FooCache

The class/filename ZMFooCache would actually also work, however convention is to leave the ZM prefix to core code/plugins.