[TYPO3-dev] performace of cachingframework

Christian Kuhn lolli at schwarzbu.ch
Fri Feb 18 20:34:39 CET 2011


Hey.

On 02/18/2011 08:01 AM, Peter Russ wrote:
>> On 02/17/2011 05:11 PM, Bjoern Pedersen wrote:
>>> SELECT identifier FROM cachingframework_cache_hash WHERE crdate +
>>> lifetime< 1297803600 AND lifetime> 0;
>>
>> Those queries are only fired by the garbage collection task, they are
>> no usual production queries from frontend?
>
> But there is no reason that GB is blocking the server ;-)
> Production or not doesn't really matter.

Sure. My question was only meant to get an idea of the impact.

Taking a look at the code something like 'AND lifetime>0' is used pretty 
often. From db point of view its even more bad if 'OR lifetime=0' is done.
Background is that an entry with infinite lifetime is set to 0 to 
indicate that. It would be better to change this from 0 to 'far in the 
future' to avoid these queries. BTW: starttime / endtime fields in usual 
tables suffer from the same problem, a long standing issue ...

Furthermore, imho 'unlimited' lifetime for cache entries is a bad idea 
in the first place (pretty often done for entries in cf_cache_hash): 
Chances for cache pollution are good this way (entries written once, 
never used, but never invalidated). From my point of view we should take 
a look at all core cache entries with unlimited lifetime and set a lower 
lifetime by default (not more than 4 weeks for example).

The db backend is not a backport of FLOW3, it is v4 only. Patches can go 
to v4 directly.

I'll see if I can come up with patches for the above two things (1. 
remove lifetime=0 queries and 2. maximum lifetime for core cache entries).


Regards
Christian




More information about the TYPO3-dev mailing list