Actions
Bug #98964
closed
Menu object caching creates too many records resulting in huge cache_hash table
Start date:
2022-11-01
Due date:
% Done:
100%
Estimated time:
TYPO3 Version:
11
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:
Description
Caching of menu objects causes excessive growth of the cache_hash table on many TYPO3 instances. In many cases, the table is filled with 5 to 10x the amount of records in the cache_pages, and on bigger sites the table can easily grow to several GB's (I have an instance where cache_hash grows to over 3GB, while cache_pages is still at a reasonable 350 to 400MB, with about 10.000 pages in cache). By far, most cache_hash records have an 'ident_MENUDATA' tag.
There are currently multiple problems with the caching of menu objects:¶
- the size of the tables can cause the server to run out of disk space
- many records of the created records are never retrieved, caching is pure overhead in this case (menu caching only plays a role at the first rendering of a page, as soon as the page is cached the menu caches are not used anymore for that page, provided you don't use uncached TS menu's...
- comparing the content of the cache records showed that many stored menu objects are identical, although the hash (field 'identifier') is different. At the mentioned site, SELECT count(distinct content) FROM cache_hash; resulted in 400 with 3200 records! So every object gets stored about 8 times in average.
Causes¶
- it appears that the calculated hash for storing the records has too many variables, causing identical menu objects to be stored. See $this->hash in AbstractMenuContentObject->makeMenu(). I'm not sure this can avoided with the current code.
- menus contain so many states (active, current, etc) that the output of most menus is different for every single page, making caching useless if the page itself is properly cached.
Possible solutions¶
- Benny Mack has created a much better alternative for the current menu objects with the extension b13/menus. This extension solves the issue by not storing all that state information in the menu cache, but adding that later on. This results in menu objects that can actually be re-used on many pages, so caching might actually result in some performance improvement, but of course still only for pages that are not in cache yet.
- I have very good experiences with skipping menu caching altogether, and propose to make it optional. Some quick and dirty benchmarking on my project showed a minor performance improvement on first page rendering, and - of course - no difference for cached pages. The large site where it is applied runs smooth as ever, with a very compact database now and no more disk space issues.
I will supply a patch for the second solution.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by
Actions