Template Module Caching
Template Module caching provides the means by which the contents of a content module can be computed and stored for later use. This has the following key benefits:
- faster publishing - commonly computed template code is computed once for
- better database performance - publishing less content needlessly will reduce the load on your database
- memcached support - if memcached is enabled for your installation, Movable Type will automatically store cached content there, further reducing the load on your database.
- event based cache expiration - cached content can be automatically expired in response to specific events, e.g. receiving a new comment or the creation of an entry.
- time based cache expiration - cached content can automatically expire after a designated time interval, e.g. every 60 minutes or once per day.
- simple user interface - users can configure their cache preferences through a simple user interface.
- fine grained control - when more control over your caching preferences is needed, users can utilize template tags to fine tune their installation.
To use template module caching, you will need to enable “Module Caching” on the Preferences > Publishing Settings screen. Click the check box labeled “Module Caching” under the “Module Options” section. Then click “Save Settings.”
Once module caching is enabled users will be able to select on a module by module basis their caching preferences.
There are one of three ways cached data can be cleared or reset by the system:
- Saving a module - if a user saves or makes changes to a template module, then that template modules cache will be cleared.
- On an Event - users can instruct to have the system automatically clear the cache for a module upon a specific event. Users can select from one or more of the following events:
New or modified:
- After a specific time period - users can instruct to cache template module content for a specific period of time. Once this time period has elapsed the template module’s contents will be refreshed upon the next publishing event that involves the associated module.
<mt:Include> template tags has been extended to support additional arguments to give the user even more fine grained control over their caching preferences on an include by include basis.
<mt:Include> arguments take precedence over any other caching preference associated with the included module:
- cache - if set to ‘0’ will forcibly turn off caching for this module. If set to ‘1’ then will turn caching on and Movable Type will assign a cache lookup key automatically if one is not explicitly set.
- ttl - sets the “time to live” in seconds for the cached content
- key - sets the lookup key for the cached content.
The following will cache a version of the “Related Entries” widget on a category-by-category basis.
<mt:SetVarBlock name="cache_key"><mt:EntryCategory></mt:SetVarBlock> <mt:Include widget="Related Entries" key="$cache_key" ttl="3600" cache="1">
Template module caching will work for any Movable Type installation. The use of memcache is optional. If memcache is enabled, Movable Type will store cached content there in lieu of in the database, further reducing database load.
Template module caching can dramatically speed up publishing and reduce database load. Caching is recommended for any and all sites of scale that require a lot of publishing.
The events which cause a cached template to expire (except for time) are associated to blog events, thus template caching is not supported for global templates.
However, a global template module may be included into a blog template module with caching settings. To use this blog level template module in other blogs, use the
blog_id attribute of the
- Almost all widgets could benefit in some way from caching. For example, you can set your “Recent Entries” widget to be cached, and have that cache live for as long as it needs to until a new entry is received, and that widget needs to be updated.
- Don’t cache modules that are trivially small, or have HTML in them exclusively.
- Focus your efforts around finding blocks of code that potentially utilize complex template code. Look specifically for template tag combinations that you might suspect slow down the publishing process, and then place that code inside of a cachable template module.
The template modules options in the user interface represent a simple and flexible way to achieve the vast majority of caching scenarios. However, in the event that you need even more control over how and when things get cached, you can explore a whole new set of arguments added to the
For example, suppose you have a template module that is shared across a number of different templates. And suppose the output from that template module will vary greatly depending upon the template in which it is used. Therefore a simple global cache for that module is inadequate.
key argument in the
<mt:Include> tag will allow you to specify a lookup key for the cached content that is specific to the context in which it is used, thus allowing a single template module to cache 5 or more different versions of itself.
“TTL” stands for “Time To Live” and refers often to the amount of time given to an item in the cache before it expires and must refreshed.
It is quite possible that one of your templates is invoking a template module that has been cached. To clear the cache, find the template being cached, and save it. Saving it, even if you don’t make any changes to it, will force MT to invalidate and clear its cache.
You can also navigate to that blog’s Publishing Settings’ screen and turn off template module caching across the board.
In the event that you want to cache the contents of an entire page or index template, place the entire contents of the page inside a module and have the index template simply include that module.