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

[Ernesto Baschny [cron IT]]

Hi,

why is speed only an "alternative"? Why would anyone use a "slow
alternative"? Any drawbacks your implementation has? Why not implement
the speed improvements in the original db_backend? After all, we can
change the fields of that table on a minor release (4.6), right?

Cheers,
Ernesto

Bjoern Pedersen schrieb am 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)
>