[TYPO3-core] RFC: #11271: Use 2 level cache for BEgetRootLine

[Rupert Germann]

hi

I wrote some "is-it-worth-caching-this?" codelines which might be helpful in
this and other cases.

insert this at the beginning of the function you want to test:

$s = microtime(TRUE);
$tmpCI = debug_backtrace();
$call_info = $tmpCI[1];
unset($call_info['args']);
unset($call_info['object']);

then add something like the following lines at the points where a cache hit
respectively a miss occurs:

debug(array(
  'HIT time: '=>number_format(floatval((microtime(TRUE)-$s)*1000),5). ' ms',
  'caller'=>$call_info,
  'BEgetRootLine_cache'=>$GLOBALS['T3_VAR']['BEgetRootLine_cache'],
  '$uid'=>$uid,
  '$clause'=>$clause,
  '$workspaceOL'=>$workspaceOL), ' ('.__CLASS__.'::'.__FUNCTION__.')',
__LINE__, __FILE__, 3);

that should give you some information about how often the method is called,
how long does it took and who called it.

in our current case it shows that the page module seems to produce the most
activity in BEgetRootLine. The function is called 7 times causing 2 misses
(because the $workspaceOL value changes) and 5 hits.
(the list module produces only 2 misses and one hit)

since BEgetRootLine searches the rootline upwards until page 0 the amount of
executed queries is quite limited - honestly, how deep are your pagetrees? 
It's not comparable to the caching in getTreeList which can save thousands
of queries with one cache request.

I suggest to leave it as it is because the amount of testing for possible
sideeffects of not correctly cleared cache entries and also the possible
speed gain does not justify the effort.

greets
rupert
 

Steffen Kamper wrote:

> Hi,
> 
> Rupert Germann schrieb:
>> when I made the patch to connect the treelist-cache to the caching
>> framework I first made it the easy way by simply using the cache_hash
>> table for tree lists, too.
>> Then I "devlogged" the actual amount of cache gets and sets in this table
>> when rendering pages in FE and found that 20 queries to the treelist
>> cache (for an uncached page) are not that uncommon.
>> So I decided to stay with a seperate table and initialize an own cache
>> for this.
>> every additional function putting load on the caching framework should be
>> benchmarked somehow before actually adding it to the code.
>> 
> 
> my intention was the same, as the function does a lot of recursiv SQL
> queries. As fist level cache was implemented it's called only one per
> session, but if you don't change/update pages it's processed on every BE
> request again.
> 
> It's quite obvious that reading one cache entry is much faster than a
> loop containing complex SQL.
> 
> For sure as Masi mentioned there has to be a "clear" mechanism in
> tcemain, but before hacking this in it would be good to have a general
> strategy for doing this, means "Clear which identifiers after
> create/move/delete/update".
> 
> vg Steffen