[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