[TYPO3-core] RFC #17693 performace of cachingframework: alternative dbbackend

[Peter Russ]

--- Original Nachricht ---
Absender:   Bjoern Pedersen
Datum:       23.02.2011 14:15:
> Hi,
>
> This is a SVN patch request.
>
> Type: Performance
>
> BT reference: http://bugs.typo3.org/view.php?id=17693
> Branches: trunk
>
> Problem:
> as dicussed in some length on the typo3-dev mailing list,
> the cachingframework is not optimized with respect to query indices.
>
> this patch provides an alternative db_backend with expires-column and
> indices for better db usage.
>
> Solution:
> this patch provides an alternative db_backend with expires-column and
> indices for better db usage.
> I have choosen a second cache_be class, as otherwise extension using CF
> would break due to different table layout.
>
> How to test:
> a) cache working
> b) in mysql:
>
>
> mysql> explain extended select * from cachingframework_cache_pages where
>  expires>=now();
> +----+-------------+------------------------------+-------+---------------+---------+---------+------+------+----------+-------------+
> | id | select_type | table                        | type  |
> possible_keys | key     | key_len | ref  | rows | filtered | Extra       |
> +----+-------------+------------------------------+-------+---------------+---------+---------+------+------+----------+-------------+
> |  1 | SIMPLE      | cachingframework_cache_pages | range | expires
>   | expires | 4       | NULL |    1 |   100.00 | Using where |
> +----+-------------+------------------------------+-------+---------------+---------+---------+------+------+----------+-------------+
> 1 row in set, 1 warning (0.12 sec)
>
>   
> ------------------------------------------------------------------------
>
> _

Frankly speaking I don't get the benefit of code dublication as this 
pretty similar to dbbackend.

1) Ever tried to fix slow result by just improving the index?
2) There is STILL the drawback, that the API always query the ->has 
before the ->get: 1query to the db is needless as the first could 
already receive the result and store it in global ;-)
3) Why should I use a very high number to indicate that something should 
last forever instead of 0 ?  Ever checked db directly and tried to 
remember "forever"?
4) From point of service/support it would be a nightmare to change the 
layout for the db design.

-1 for this patch and ALL versions!

Peter