eZ Community » Learn » eZ Publish » eZ Publish Cache In Details: View Cache

eZ Publish Cache In Details: View Cache

Friday 12 April 2013 6:01:50 pm

  • Currently 3 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

The view cache expiry triggers & the associated expiry modes

The previous chapter explained the various modes of view cache expiry (by set or complete), this chapter describes the different trigger events that can cause this expiry (by set or complete), in a voluntary manner or in spite of your will.

These two notions of “voluntary” or “dispite you” are crucial since:

  • The "voluntary" expiry of the view caches can be misused, such as attempting to solve a problem unrelated to the view cache or underestimating the impact of a massive dump of the view cache, which does in fact only imply a single set of cache (we often expire the entire cache because it’s easier, or because we do not know any other way to proceed, without considering the impact of this action)
  • The "despite you" expiry of the view caches means that the cache has expired due to an action / event that may seem trivial and not impacting for the caches: you simply did not know that this action causes a complete expiry of the view cache. Thus, the addition of a content class causes the expiry of the entire view cache, with no direct deductible link, which can cause an unbearable load on the server depending on the context (high traffic, no Varnish cache...)

 

 

Complete expiry of the view cache using a script

The total expiry of the INI cache is done as follows:

The script « bin/php/ezcache.php --clear-id=content »
Result: Display content cache

The script « bin/php/ezcache.php --clear-tag=content »
Result: Display content cache, Classes identifiers cache, Sorting keys cache, URL alias cache, Template block cache, RSS cache, Content tree menu, Limitations of states cache.

Running these scripts do not target a particular node or node list.
The expiry of the view cache is therefore global:
Update of the {VarDir}/cache/expiry.php file, and change of the value 'content-view-cache' => timestamp update

 

 Partial expiry of the view cache using a script

This action is necessarily « voluntary»:

  • bin/php/ezcontentcache.php –clear-node=2
  • bin/php/ezcontentcache.php –clear-node=2,46,63
  • bin/php/ezcontentcache.php –clear-node=/company/about
  • bin/php/ezcontentcache.php –clear-subtree=/company/about
  • bin/php/ezcontentcache.php –clear-subtree=/company/about,/news

Documentation of the ezcontentcache.php script:
http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Features/View-caching/Clearing-the-view-cache

Warning: the partial removal of the content cache can automatically transform itself into an entire removal of the view cache if the number of nodes involved (for any node of the list or subtree) is greater than the CacheThreshold (250 by default), see the chapter of CacheThreshold.

Warning: Currently, an expiry of the view cache from a list of nodes or a subtree reproduces the whole process (smartviewcache, CacheThreshold, expiry of the template-blocks associated with a relative expiry subtree, etc.) for each involved nodes (list of nodes or nodes of the subtree). Thus, as a simple example, a smartviewcache rule on the siblings could result in a “squared” view cache expiry (nodes expires as many times as the number of sibling nodes), and make the system unstable.

 

Partial expiry of the view cache by viewcache.ini

The mechanism of viewcache.ini is already widely detailed in other tutorials, this article focuses in particular on the critical configurations or recommendations for high traffic websites.

It is in fact quite frequent that the rules of the viewcache.ini regulary cause expiry of the entire view caches, in spite of you, without real relevance or functional need. Indeed, partial removal of the content cache can automatically turn into a complete removal of the view cache if the number of involved nodes is greater than the CacheThreshold (250 by default), see the CacheThreshold chapter.

It is therefore important to control the number of nodes affected by an update of the content, and for this to work in “Smart view cache” mode, taking a lot of care to:

  • Not use the « all » directive
  • Not use the « siblings » directive if the content is heavily stored under the same location (siblings)
  • Configure the KeywordNodesCacheClearLimit to 0 if you use keywords heavily

Documentation of the KeywordNodesCacheClearLimit in the viewcache.ini file
# The maximum number of linked keyword nodes to go trough
# when looking for objects that needs to have its cache cleared.
# Set to integer to activate, 0 to disable keyword clearing globally
# or disabled to not have any limit at all (default value)
KeywordNodesCacheClearLimit=0

Documentation of Smart view cache:
http://doc.ez.no/eZ-Publish/Technical-manual/4.x/Features/View-caching/Smart-view-cache-cleaning

 

Voluntary expiry of the view cache in the Back Office

"Voluntarily" expiring the view cache in the Back Office, whether through a node, a subtree or the entire view cache (/setup/cache/ tab) is a bad practice that should be reserved exclusively for development versions of the website.

This tutorial is not intended to promote this practice (unfortunatly too common) and will therefore not say anything anymore on this subject but this: a content provider or webmaster shall in no case have access to the cache management features, which may in all cases:

  • be automated and secure without requiring manual actions
  • cause huge system instability / server crash on a high traffic website

Warning: currently, a view cache expiry from a node (back office or ezcontentcache.php script), implies the recursive expiry of all the nodes of the selected location. This expiry reproduces the whole process (smartviewcache, ChacheThreshold, expiry of the template-blocks linked to a relative subtree expiry, etc.) for each node involved. Thus, as an example, a smartviewcache rule of the siblings could result in a “squared” view cache expiry (each node expires as many times as the number of sibling nodes), and make the system unstable.

 

Unvoluntary expiry of the entire view cache after an action in the Back Office

A certain number of operations can expire the entire view cache in the Back Office, in spite of the user or administrator, who don't necessarily know the link between an action in the Back Office and the expire of the view cache. Here's a list, that we hope comprehensive, of the actions in the Back Office that can expire the entire view cache:

  • Roles: modification / removal of a role, modification / removal of the assignation of a role
  • Sections: assignation of a section
  • Handling of ezshop: handling of discount rules, discount groups, affectation of users to the groups, edition / removal of currencies etc.
  • Content class: creation of a new class (even without an associated object), the modification and removal of a class
  • Languages: add / removal of a language

Apart from the create functionality of a class (without object by default), others Back Office actions logically expire all view cache. As we’ll see in another chapter, these informations are used “by default” in the hash key of the view cache (but without regard to possible deactivation of some keys by the use of the ViewCacheTweaks parameter).

 

CacheThreshold, a partial expiry of the view cache that becomes complete

When a view cache expires for X reasons (update of an article, ezcontentcache.php script...), it affects generally a list of nodes having a cache to expire : the node of the article itself, and related nodes of the article, siblings, parents or nodes using the same keywords, etc. (as directed by the viewcache.ini).

In the end, eZ Publish is capable of calculating the number of nodes involved in the triggered cache dump. To stabilize the system and prevent for example to order the alteration of too many cache files on the server (unlink, touch, update SQL... Depending on the filehandler used), eZ Publish uses a limit, the CacheThreshold:

  • If the number of impacted nodes in lower than the CacheThreshold: eZ Publish “invalidates” the cache files depending on the used filehandler (delete, by default). See the chapter that details the various alter modes (unlink, touch, update SQL...)
  • If the number of involved nodes is greater than the CacheThreshold: eZ Publish then switches to full expiry of the view cache by changing the value 'content-view-cache' (update timestamp) of the {VarDir}/cache/expiry.php file

 

 

Printable

Printer Friendly version of the full article on one page with plain styles

Author(s)

Proudly Developed with from