Cache plugins for Panels module. Currently implemented node based cache plugin. Node based cache is intended for panels/panes which update together with nodes they contain.
- Instant updates. Users don't see old content.
- Granular updates: only panes/panels containing changed nodes are flushed. Highest cache efficiency.
- Works for registered users too and complements anonymous page caching
Supported cache backends: Memcached (both Memcache API and Cacherouter-Memcache should work). Other cache backends are not supported because of the way Namespice module works.
This module is not recommended for production use yet: because of undecided status of Namespice module, Advanced Panels Cache remains experimental too.
Node Based Cache
Node based cache uses CTools context system to propagate node updates to panels using them, so cache invalidation happens automatically on hook_nodeapi('update ..). With the help of Namespice module each cache entry is marked with one or several tags containing node id. When a node updates, only cache entries tagged with the node id are flushed.
- Invalidation source selection
You may choose exactly which contexts serve as "invalidation sources". That means Panel (or pane) may contain several nodes (contexts), but only some of them will trigger Panel cache invalidation.
- Context granularity
- Argument granularity
- Role granularity
- Cache lifetime
Cache can be context granular (per combination of contexts).
Cache can be argument granular (per arg. combination). Note that it isn't related to "context granularity" directly: your contexts may be derived from arguments or not - we don't assume anything about it. You may want to use one of them or both, depending on your setup.
Cache can be role granular (per combination of user roles). For stock Drupal that means you will have 2 different caches: for anonymous and registered users. In most cases you want to have this turned on.
Same as with simple time based cache plugin, you can enforce cache lifetime. When enabled, cache will also expire depending on it's age, in addition to node update events. This can be useful during testing: you can ensure that stale cache entries don't live forever. For production you may want to store cache entries as long as you can and disable this feature.
Installation and requirements
- Install Namespice module.
- For privileged users you need to have separate roles (e.g. "administrator", "moderator").
- You must have separate "cache_panels" bin set up, to have serious gain from using this module.
Otherwise your privileged users will have same cache as your ordinary registered users.
If you use bin shared with other modules, it will be less efficient. Consult Memcache API docs for information on how to setup separate Memcache bin for every cache table.
Problems and limitations
- Views panes
- Node cache works for nodeapi "update" events. There are modules that do silent updates without triggering "update" events. Also sometimes node itself doesn't update directly but some part of it's look updates, such as theming code or external data
You can cache View pane if it shows "related" content, but it may require additional work to propagate cache invalidation using relationship. If it's node relationship, and it's implemented as CTools relationship, you can try to use it as "invalidation source".
In other cases, Views panes can't be effectively cached by this module (unless you use it as time based cache). With additional code, though, it may change.
There are 2 ways to fix that: either fix the problematic module, so it invokes 'update' event, or use function ns_cache_clear_all('*', $table, $tags, $serial_table) in your own module, which will basically flush cache tagged with $tags. For exact syntax of this function, look at the module code. Ap_cache module uses tags of form "node$nid".
As last resort, you can use cache_clear_all('*', 'cache_panels', TRUE) which will clear whole Panels cache bin (all cache data). You can do this also using Memcache Admin interface.
Example of performance gain
On my dev. site, for heavy Panel consisting of 4 minipanels, 2 Views, several nodes (one of which is very complex), page with cached Panel is rendered in ~300-400ms compared to ~700-800ms uncached (measured by Devel module). These numbers should give hints about how much is cache important for complex sites.
Better measurement would be to compare this module with default time based cache of Panels: Advanced Panels Cache won't give higher speed but should give much better cache usage (hit vs miss ratio). If you want to help, use built-in Memcached statistics to make such comparison and report your results to the issue queue. It will be especially helpful if you test this module on copy of production site (or on the production site itself, if you are brave enough) with many nodes.
If you have any ideas of common cache invalidation patterns, please share, and I may implement them.