[TYPO3-dev] set_no_cache is bad. What's next?

R. van Twisk typo3 at rvt.dds.nl
Tue Apr 3 00:55:56 CEST 2007


Ernesto Baschny [cron IT] wrote:
> John Angel wrote: on 02.04.2007 09:38:
>
>   
>>> Or in other words to a caching on object/extension level instead on page
>>> level. 
>>>       
>> Exactly, something like toi_cache ext approach.
>>     
>
> The functionalty sounds exactly what we already have in core:
>
> t3lib_page::getHash()
> t3lib_page::storeHash()
>
> which has always been available for plugins (table "cache_hash").
>
> What are the benefits of "toi_cache" over that generic caches?
>
> And following the thread of Masi, maybe we just need to enhance that
> core methods a bit for more functionality?
>
> Cheers,
> Ernesto
>   
Actually,

that is a bit to generic, Elmar made a a better example.
But I would like to see a more intelligent way of caching data.

Something that can understand the data structure better.
For example

let's say we store data in a hierarchy:

a-
--1
--2
--3
--b
----4
----5
----6
c
--7
--8
--9
----d
----e
----f
g
--10
--11
--12

You can see the above as a forum (a, b, c) with different
posts, or news with categories... It doesn't really matter.

Now when a cache needs to be cleared I would like to tell
the caching API 'clear cache of tree c', or 'clear cache of tree b'
or 'clear cache of item 10'.

That way we can instruct the caching mechanism to only clear
parts of the cache, instead of simply the whole structure.

Above, I am not talking about the page tree, or the cache of pages,
above I am talking about a API where extensions can store data
in a hierarchical way, and teh extension can decide what parts
to purge. Or using auto purge parameters like:
- Clear (part of the) cache at some time
- Clear (part of the) cache at some event..
- Clear (part of the) cache  per instruction made by the extension

A simple 'make hash and retrieve' data system will not work well
for extensions for several reasons outlined in other parts of the thread,
or the danger of flooding the cache when wrongly used (just look
in the mailing list for 'Help my DB is 5Gb big', or similar posts.


I am not sure you what the best solution is (apart from optimized DB
structures and well designed extensions) for extensions caching.

The default caching mechanism works well unless you want to scale high,
and with high I means sites like what dmitry manages (1mil pages hits 
per day)
and sites with many many pages with extensions like tt_board, forums, 
news etc.


RIes
 









More information about the TYPO3-dev mailing list