[TYPO3-dev] performace of cachingframework

[Peter Russ]

--- Original Nachricht ---
Absender:   Bjoern Pedersen
Datum:       18.02.2011 11:27:
> Am 18.02.2011 11:03, schrieb Peter Russ:
>> Sorry but your answer is not correct. Please check the code HOW it is
>> handled in the dbbackend. Even if only true or false is returned query
>> will always take lifetime into account.
>>
>> Additionally there is an overhead as has and get are similar and always
>> 2 queries are required to receive a cached item. So using dbbackend for
>> caching might even increase the number of queries and slow down delivery
>> on high load sites.
>>
>> If you would consider this in your patch it would help more ;-)
>>
>> Peter.
>>
> 
> Peter,
> 
> we are talking about two different things here. You are talking about
> the handling in php. I am only talking about handling by the database.
> And there is a key on identifier, so the number of records to check for
> expiry is low.
> 
> mysql> explain select * from cachingframework_cache_pages where
> identifier='xxxx' and crdate+lifetime>=now();
> +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+
> | id | select_type | table                        | type | possible_keys
> | key      | key_len | ref   | rows | Extra       |
> +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+
> |  1 | SIMPLE      | cachingframework_cache_pages | ref  | cache_id
>  | cache_id | 130     | const |    1 | Using where |
> +----+-------------+------------------------------+------+---------------+----------+---------+-------+------+-------------+
> 1 row in set (0.03 sec)
> 
> mysql> explain select * from cachingframework_cache_pages where
> crdate+lifetime>=now();
> +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+
> | id | select_type | table                        | type | possible_keys
> | key  | key_len | ref  | rows | Extra       |
> +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+
> |  1 | SIMPLE      | cachingframework_cache_pages | ALL  | NULL
>  | NULL | NULL    | NULL |    1 | Using where |
> +----+-------------+------------------------------+------+---------------+------+---------+------+------+-------------+
> 1 row in set (0.00 sec)

This assumption is correct on your machine. But on high load sites where 
  values are cached for some secs or mins it looks totally different: 
There could be several 100s or 1000s of records with the same key before 
GB....

It would help a lot if developers would realize that TYPO3 claims to be 
an "Enterpise CMS" and this more than just "runs fine on my machine" ;-)

Peter.


-- 
docendo discimus

_____________________________
uon GbR
http://www.uon.li
http://www.xing.com/profile/Peter_Russ