Smerecashe (Smereka cache) is an internal Smereka cache of ready-to-sent pages. It dramatically (hundreds of times) faster sending of documents to the client, so it should be used wherever possible.
There are two variables in the module customsettings.php to control Smerecashe :
$UseSmerecashe – turns on (1) or off (0) pages caching subsystem;
$GzipSmerecashe – turns on (1) or off (0) compression of cached pages.
The procedure of clearing Smerecashe discards all cached pages and force Smereka to regenerate them again. This is necessary after changing the software modules that generate pages, so that the Smereka tracks changes in node data for pages, but not the changes in generation algorithms.
To clear Smerecashe user must login as administrator, then go to Control panel page and click «Clear Smerecashe» link. This link will appear if this command is granted to user.
To switch compression mode follow nest steps: 1, turn Smerecache off, 2, change the value of $GzipSmerecashe; 3, necessarily clear Smerecashe, 4, turn the Smerecashe on.
Reading from Smerecashe
Reading from Smerecashe occurs at the beginning of request processing by Smereka, so if it appears to be successful, the treatment ends quickly, with 3 queries to the database.
For successfull reading the following conditions must be satisfied simultaneously :
– Smerecashe must be activated;
– $_GET['Path'] variable must be setted (this is always takes place with symbolic and virtual addressing);
– $_GET['Node'] variable must not be setted;
– $_REQUEST['Cmd'] variable must not be setted;
– $_POST array must be empty.
Generally speaking, pages with numerical addressing and page receiving POST data can not be cached.
If conditions met, Smereka try to find a cached page. It identified by the current URL.
If this page is not exist in Smerecashe, Smereka follows standard procedure to generate the page.
If the page is found in Smerecashe, access rights of user for this page is checked. If the user can access to this page, it sends the client; if the user has no such right, the standard generation procedure run (for generating an error message or something else).
If Smerecashe contain compressed pages, Smereka check whether the client can accept compressed pages and perform decompressing as necessary.
Writing to Smerecashe
After the standard page generation procedure Smereka tries to write a new page to Smerecashe. To do this all of Smerecashe reading preconditions must be fulfilled and + the following conditions:
– page must be successful (HTTPCode == 200); page error messages are not cached;
– page template must allow caching (variable PageSmerecasheable = 1). With this variable, one can enable / disable caching of pages that use this template or template, inherited from this;
– page must correspond some database node (parametric pages does not cached);
– this node should allow caching (attribute Smerecasheable). With this attribute one can control caching at per-class level (by setting the value of this attribute by default) or at per-node level.
By default, all templates and node classes allow caching. Prohibition for certain node may require, for example, if it contains a form which should be filled dynamically. Prohibition at per-class level can be used, if appropriate pages have purely dynamic content, such as shopping cart in the web shop.
Smerecashe consists of two tables: smerecash contains cached pages and smerecashlnk contains links to the nodes. Each page during the generation uses information from several nodes, and generated page stored in Smerecashe ids of these nodes recorded in the links table. Further, when any of these nodes is changed, all the cached pages linked to this node are discarded, which causes Smereka to regenerate them, reflecting the changed information.
When one move, delete or add nodes, Smereka uses very conservative algorithm: it discard all the pages, depending on all siblings of moved / deleted / added node. This is done to ensure that node aggregators were informed about the changes in the tree structure and update their content respectively.
This automatic discarding of the outdated pages works only if changes were made to the database through the Smereka. Of course, it does not work if the changes made to the database directly, bypassing the Smereka (for example, when restoring a database from a backup). If such changes occurred, one need to completely Smerecashe.
Since version 1.4, Smereka supports delayed Smerecashe update. In this mode the modified nodes only are being marked for the next reset of the outdated pages. The reset itself is not launched automatically after saving each node, and executed only by special command.
What are the benefits? Suppose we have 20 nodes (articles) with the same hierarchical level. We changed places two neighboring articles. This should reset (regenerate) all pages which are dependent on these 20 nodes. Five minutes later we changed places two more articles. If a reset occurs automatically (immediately after moving), the cached pages will be dropped, and during five minutes some of them can be generated again (this is possible if the site is under real stress). After the next editing operation this cycle is repeated again.
With deferred reset we can edit this group of nodes as long as necessary. After the first change of nodes order all of them will be marked for the next reset, and subsequent editing operations, marking them again and again, do not contribute nothing new to the reset plan. Then one command can update all the marked nodes.
This mode has particular advantages when multiple editors working on data editing. Chief editor from time to time perform updates of marked nodes, resetting cached pages.
Another benefit of such mode – a possibility to configure automatic periodic updating Smerekesh using task scheduler (such as cron), which enables even forget about the need to update Smerecash.