[TYPO3-dev] performace of cachingframework

[Bjoern Pedersen]

Am 18.02.2011 20:34, schrieb Christian Kuhn:
> 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


I fully agree.

So to summarize once again:
a) we need an indexed expire column
b) we want to get rid of lifetime=0 as flag for no expiry (actually we
could set expire to int_max, that's anyway the longest lifetime before
wrapround to negative values would occur.
c) i would suggest to make "has()" protected, as it is only useful in
some cache_be implementations.

Björn