Power is nothing without control
—Pirelli ads.
As we've seen so far, eZ Publish is a much advanced and powerful CMS and it needs to be well configured to work at its best. Like many other enterprise software applications, this CMF possesses an advanced caching system that is complex to set up and configure, but very powerful in the end. Configuring the caching system will help eZ Publish to perform better and reveal its strength.
In this chapter, we will see in detail, how such systems work, and will look at how to shape our site in order to make it the "Ferrari" of websites.
Whenever we make a web request to a CMS that does not have a serious caching system, the web server is put under a severe test, as it has to perform the following things:
- Read the settings
- Query the database to retrieve the data requested
- Load the template
- Replace parsed variables with the required data
- Send everything to the client
The process, depending on the page complexity, could be very simple, or very heavy to perform.
A famous site with many concurrent requests, maybe even a powerful machine filled with RAM and CPUs will not be able to support so much work and cause the web server to hang.
The caching system is born to help the server to deploy applications more effectively.
Note
You can find some documentation on caching on Wikipedia at http://en.wikipedia.org/wiki/Cache.
Usually the bottleneck is caused by the query and template complexity. eZ Publish provides a system for caching at several levels:
- Template cache
- Template compile
- View cache
We will learn about each of these in detail in the coming sections.
The template caching system provides the ability to cache static blocks of content and layout by using the {cache-block} template operator:
{cache-block [ keys=keys]
[ expiry=expiry]
[ ignore_content_expiry]
[ subtree_expiry=subtree_expiry]}
...
{/cache-block}
This solution makes it possible to reduce the processing time of the main template (pagelayout.tpl), which often contains a lot of dynamic elements. It can be used to instruct the system to store and reuse cached blocks of template code based on different conditions.
- Cache keys: The
keysparameter can be used to define the uniqueness of a cache block. - Time-based expiration: The
expiryparameter makes it possible to manually specify how long a cache block can live (as a number of seconds). - Content expiration: By default, all the cache blocks expire when an object is published. If the
ignore_content_expiryparameter is used, the cache block will not expire when an object is published. - Subtree expiration: The
subtree_expiryparameter can be used to bind the expiration of a cache block to a certain part of the content node tree.
eZ Webin provides a layout that is already set up with the correct cache-block. There are two large blocks, one for the header and another for the footer.
As we can see in this image, as recommended, there is a nested block inside the header that contains the logo, the menu, and a breadcrumb navigation menu.
Note
Breadcrumbs—or a breadcrumb trail—is a navigation aid used in user interfaces. It gives users a way to keep track of their location within programs or documents. The term comes from the trail of breadcrumbs left by Hansel and Gretel in the popular fairytale. For more information, go to http://en.wikipedia.org/wiki/Breadcrumb_(navigation).
It's important to not put the $module_result.content variable in the cache block because it contains the main content of our pages. This is because the content of the actions of the modules are cached through other mechanisms.
To enable or disable the template cache system, you need to edit the TemplateCache setting of TemplateSettings section in the global or siteaccess site.ini.append.php file. If we enable the setting on the global setting file, it will be enabled for all our siteaccess. But if we enable it only in the siteaccess file, it will be enabled only for the related siteaccess.
[TemplateSettings] ... TemplateCache=enabled ...
This code will enable the template cache. As a result, all of the cache block will be saved in var/[siteaccess]/cache/template-block.
The eZ Publish template language, as with any meta language, needs to be parsed and interpreted by the CMS engine for any requests.
After activating the template compile functionality, all eZ Publish templates are processed and converted into real PHP language. In this way, the template can be directly interpreted without being parsed first.
To enable or disable this feature, we need to edit the TemplateCompile settings in the TemplateSettings section of the global siteaccess site.ini.append.php file, as shown below:
[TemplateSettings] ... TemplateCompile=enabled ...
All compiled templates are saved in the var/[siteaccess]/cache/template/compiled folder.
If the TemplateCompile configuration is enabled, we can also enable the TemplateOptimization configuration. With this setting, eZ Publish will attempt to optimize the PHP code created, wherever possible.
Finally, there is another feature that greatly enhances the performance of CMS. This feature must be set via the TemplateCompress setting in the TemplateSettings section, as we can see in the following code:
[TemplateSettings] ... TemplateCompress=enabled ...
Through this approach, it is possible to compress the PHP code into a binary code that interprets PHP much more rapidly.
The most important level of caching after the cache and compiled templates for layout is the view cache engine. This caching system is used to cache the output of the content module that is stored in the $module_result.content variable.
As mentioned above, this variable should never be placed inside the cache block, as it uses a different engine to cache the content.
To enable or disable this feature, we need to edit the ViewCaching setting in the ContentSettings section of the global or siteaccess site.ini.append.php file.
[ContentSettings] ... ViewCaching=enabled ...
If we disable this setting, eZ Publish will never cache the content module output anymore.
This caching system works only for the "view" and "pdf" actions of the content module.
All cached content files are saved in the var/[siteaccess]/cache/content folder, and more than one file is created based on different parameters such as:
- User preferences
- User session
- View mode
- Language
- View parameters
- Layout
The CachedViewModes setting located in the ContentSettings section of the site.ini configuration file (or an override), controls view modes for which the caching will be enabled. The default value of this setting specifies that the view cache should be stored for the full and sitemap view modes, and the pdf view:
If you need to disable view caching for a specific page, add the following line to the beginning of the template that is used:
{set-block scope=root variable=cache_ttl}0{/set-block}
This will set the cache_ttl global variable to zero (0) for the current template. The cache_ttl variable contains the TTL (Time to Live) value in seconds. The value 0 means that the result should not be changed. The value -1 means that the view cache should never expire.
{set-block scope=root variable=cache_ttl}-1{/set-block}
Often, there is some relationship between the various caching siteaccesses. For example, if we delete the content cache of the administration panel, it's most likely that we would also want to delete the cache content of the frontend site.
To do this, we need to use the RelatedSiteAccessList setting in the SiteAccessSettings section of the site.ini global file (or override) setting, which controls what other siteaccesses must remove the cache content when emptying the cache. If this setting is not set, the system will use the AvailableSiteAccessList.
For example, we have the following RelatedSiteAccessList in our project directives:
[SiteAccessSettings] ... RelatedSiteAccessList[]=ezwebin_site RelatedSiteAccessList[]=eng RelatedSiteAccessList[]=fre RelatedSiteAccessList[]=ita RelatedSiteAccessList[]=ezwebin_site_admin ...
Every time you publish a new object or modify an existing one, the system automatically deletes the cache of some of the objects related to the published object including:
- All of the nodes associated with the published object
- All of the parents of the published object
- All of the nodes that contain the same keywords, if the "keywords" datatype is used on the published object
- All of the related nodes of the published object
- All of the related nodes of the published object with an "embed" tag
You can set the default behavior of deleting the caching system through the ClearRelationTypes setting on the ViewCacheSettings section of the viewcache.ini.append.php global (or override) file.
You can manually clear the cache of a node or a subtree either from the control panel, or via a shell script.
From the administration panel, navigate to the node for which you want to delete the cache, and then click on the icon near the name.
A pop-up window with a context menu will appear. Click on the Delete view cache link if you want to delete the cache for this node, or click on the Delete view cache from here link if you want to delete the cache for all of the subtree.
With the exception of the control panel, you can also delete the cache via the shell script.
For example, if you made changes to the template of the node with ID 81, which is equivalent to the Issue-archive/2009/January object, and the view cache is enabled, you will not be able to see the new changes until you clear the cache. To do this:
- Navigate to the directory of your eZ Publish installation
- Run the command
./bin/php/ezcontentcache.php clear-node=81
or
./bin/php/ezcontentcache.php clear-node=/Issue-archive/ 2009/January
If you want to remove multiple nodes, they must be separated by commas, for example:
./bin/php/ezcontentcache.php clear-node=81,82,83
To delete everything under the tree run the command:
./bin/php/ezcontentcache.php clear-subtree=81
or
./bin/php/ezcontentcache.php clear-subtree=/Issue-archive/2009/January
The smart cache system is a system developed to delete the cache between related objects. Using this system, you can define deleting rules in order to extend the default deleting system.
When we install a "white label" version of eZ Publish, this directive is turned off. But in our case, if we install a package as eZ Webinar, it is already enabled and configured for the custom package classes.
To enable or disable this configuration, you need to use the SmartCacheClear setting in the ViewCacheSettings section of the global (or override) viewcache.ini.append.php file. You can find this file in the settings/override/ or settings/siteaccess/<your_siteaccess> directory.
[ViewCacheSettings] ... SmartCacheClear=enabled ...
Once enabled, you can configure the custom .ini sections with custom-caching directives.
Let's take an example. In our project, when we publish a new issue, we want the issue archive page automatically to be updated to show the latest issue inserted and updated in the issue archive box, and its thumbnail in the right-hand sidebar.
As there is no direct relationship between the issue archive that belongs to the folder class and the new issue that belongs to the same class, it would not be possible to empty the issue's cache archive when we create or edit a new issue. This happens because the issue is not the issue's parent, a related object, or a class that shares the same keywords with the published issue.
Instead, through the mechanism of smart cache, we can set a custom section in our viewcache.ini global file in the settings/override/ directory, as follows:
[folder] DependentClassIdentifier[] DependentClassIdentifier[]=folder MaxParents=2 ClearCacheMethod[] ClearCacheMethod[]=object
In this way, when we empty the cache of a folder object, the system will also empty the cache of all of the folders that are its parents (to a maximum of two levels) or children. This will raise the content object tree, starting from the path_string level node attribute.
For our project, all of the eZ Webin settings we talked about so far are sufficient to meet our requirements for cache cancellation.
The following table depicts all of the rules that we can set in the custom smart cache section.
|
Name |
Type |
Description |
|---|---|---|
|
|
An array of class identifiers (not ID numbers) |
Specifies which content classes will be considered as "dependent classes". If a node encapsulating an object of such a class is listed in |
|
|
An array of strings |
Defines which method(s) to use when clearing the view cache for additional nodes. This setting is an array of strings, where only six predefined values can be used. These are: Object: Clears the view cache for all of the locations (nodes) of the object. Parent: Clears the view cache for the parent node(s) of the object. Relating: Clears the view cache for related and reverse-related objects that have relations of the "common" type, and reverse-related objects that have relations of the "XML embedded" type (according to the "ClearRelationTypes" configuration setting). Keyword: Clears the view cache for the objects that have the same keyword as this object. Siblings: Clears the view cache for all of the siblings of this node/object. All: Clear the view cache for all of the listed methods above. |
|
|
An array of object ID numbers |
If specified, the view caches will only be cleared for those additional nodes that encapsulate the objects with these identifiers. If not specified, all of the additional nodes will have their view cache cleared. |
|
|
Integer |
Sets how many parents in |
|
|
An array of object ID numbers |
Makes it possible to clear the caches for a set of arbitrary objects, regardless of whether their locations are listed in the node's |