Inside TYPO3, entwicklung

Don‘t slow applications with caches

Ok the title is a bit provocative - it could have also been something like „select your caches wisely“ or „caching is easy - but caching right is difficult“

TYPO3 comes with a flexible Caching Framework, backported from FLOW3. The key concept is, that you easily can use caches by selecing a frontend and a backend. With the frontend you decide what you want to save (most likely a variable) and with the backend you decide where to save it.

What the framework does not provide out of the box is some statistics for the caches. But this can easily be achieved by using a cache frontend that is able to provide some logs. Read on if you want to know more :-)

New functionalities in the „cachemgm“ extension.


Maybe some know this extension already - it was initiated by Kasper and offers functions to check and analyse the cached pages.

In the current version on forge this extension comes with two additional functionalities to check the caches offered by the caching framework:

Overview of the configured caches:

This module should be self explaining, it simply shows all configured caches and you can check further details.

Analyse your caches with the cache log:

The extension comes with an extended VariableFrontend. In addition to the standard frontend it logs all operations for potential evaluations. Inspired by varnish, the logging is happening as fast as possible by using an OS message queue or shared memory. This way it shouldn‘t have significant impact on cache times. But it needs PHP shared memory functionalities compiled into PHP.

To use this frontend you need to configure it in your localconf.php like this:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['extbase_object']['frontend'] = 'Tx_Cachemgm_Cache_Frontend_LogableVariableFrontend';

Then of course you need some tools to read the log (since the log is not persited). You can use the cachemgm_log cli command for this:

php cli_dispatch.phpsh cachemgm_log


And you should get something like this:



And after terminating the log reader ( Ctrl+C) - you should get a summary like this:


By using the parameters „--cache“ and „--filterUrl“ you can limit the logs that are evaluated to a certain cache and/or request url.


Dependency Injection Caching Analysis:

Lets take a small example: A website with an extbase USER_INT object. In this case there are around  150 objects that need to be created by the DI-Container per request.What do you think is faster? Using the „NullBackend“ or the default „DbBackend“ for the „extbase_object“ cache?I did a (really small and not representative) benchmark to that Url (20 requests) with running cachemgm_log - and here are the results:


Using Database Backend I got the following result
:
Time per request:       2223.411 [ms] (mean)

And the cachemgm_log showed:

Cache "extbase_object":
-------------------------
 get method:
   Hits:2997
   Misses:
   Hit-Rate:0.996
   Average GET-Hit time:935ns
   Overall Hit Time:2.8sec
 has method:
   Hits:2966
   Misses:
   Overall Time:3.35sec
 set method:
    Sucess Writes:
    Failed Writes:0
    Overall Write Time:0ns

Using no cache at all I got the following result:
Time per request:       2147.321 [ms] (mean)

And the cachemgm_log showed:

Cache "extbase_object":
-------------------------
 get method:
   Hits:
   Misses:
   Overall Hit Time:0ns
 has method:
   Hits:
   Misses:2844
   Overall Time:954ms
 set method:
    Sucess Writes:2823
    Failed Writes:42
    Average Write time:364ns
    Overall Write Time:1.03sec
    Sucess Writes:
    Failed Writes:0
    Overall Write Time:0ns


To summarize this: Using the database cache backend we had a total of over 6 seconds spend for reading something out of the cache. The overhead of using the Nullbackend was only 2 seconds (some of this might only because of the cache log actions). That means for the above test szenario its slower to read the informations from cache than to build the information from scretch.

This is a general downside of the Database Cache Backend - when used for high frequented caches! Especially when used on high traffic sides or even worse on load balanced environments with a single database this effect could be much bigger.

What this shows is, that selecting and benchmarking different Caches is crucial for a high performance application. And of course there are more numbers to watch at - than only the cache times.

blog comments powered by Disqus
blogroll