-
-
Save DavidBruchmann/cf27eb309e48e0df326b3bafce2b30e3 to your computer and use it in GitHub Desktop.
Some TypoScript in your example is outdated. e.g. sys_language_uid is outdated (since TYPO3 v9). You can use {siteLanguage:languageId}
instead of {TSFE:sys_language_uid}
.
Welcome, glad that it helps!
I almost forgot about this gist
And thanks for the proposition about the adjustment!
I almost forgot about this gist
Yes, that's the thing with stuff you put on the Internet ;-)
There is also the b13 menus extension. I first tested that but could not really get a performance improvement out of it (but might have done something wrong).
I think the B13 menu is primarily for easy usability and perhaps some features but not for performance.
b13/menus is also mentioned here https://forge.typo3.org/issues/57953 and I thought it might also be used to improve performance, but you are right, that is not really mentioned as a feature in the README.
I am still not sure about the caching - the cache entry works - as used in the code snippet above. I can debug it and set a breakpoint in VariableFrontend::get()
/ set()
and can see the menu entry is written and reused. Also, this - in combination with getting rid of the extra states ACT etc. - does improve performance significantly in my site. Not to mention reduces the number of database queries.
However, I am not sure if TYPO3 still writes the menu cache for each page (which would now be obsolete and unnecessary).
I never know where the menu gets cached but couldn't it be found in the database?
Yes, if DB is configured. I use Redis. Is stored in cache_hash.
Do you measure the performance somehow, or is it just a general impression that it's faster after your changes?
Do you measure the performance somehow, or is it just a general impression that it's faster after your changes?
(I wrote how I tested - maybe you have an additional tip or this is helpful for others).
In development, I did a before / after comparison (before and after the change) and tested like this:
- use chromium browser developer tools Network tab and select "Doc" to see just load time for the HTML page
- alternatively use ab (Apache Bench) on command line
- make sure the page is uncached, either by setting
config.no_cache = 1
on a test page. This makes sure page is not fetched from cache, but the other caches, e.g. menu cache apply. Or just flush the cache for a page and make sure the menu cache is left intact.
The load times fluctuate, but the change was considerable.
page | uncached | without ACT etc. | with menu cache |
---|---|---|---|
empty | 1.2s .. 2.4s | 1.25s | 0.581s .. 0.798s |
univers. | 2.8s .. 2.9s | 2.97s | 1.33 .. 1.88 |
This is just the main menu optimization - I have other optimzations too which are not applied yet here. (Also the test site is a bit slow, production is generally faster, so it may not be affected as much).
Also, you can see the number of DB queries in the admin panel (Debug | Query Information). I had compared that previously when deactivating the megamenu and the DB query count dropped significantly. This is how I suspected problem in generating the menu. I did not check again with the fix, but can do that next. That would probably be more reproducible than just measuring the load times.
Also, it is good to see how this plays out in production, but this is a little difficult. The pages are mostly loaded cached in production and this only affects uncached. It may indirectly affect this too (because load on DB etc.), but there are too many variables, based on traffic etc.
But I have a warmup script which also outputs the load times. But this is not recorded currently.
I have a performance log in the monitoring tool (only the start page) and also in Matomo, but - again - this is not as helpful because it mixes cached and uncached results and load time is often affected by other things (such as lots of traffic due to start of semester or courses). But I can monitor performance over time - which is a good thing to do.
Thanks a lot for this insightful explanation, that's very interesting and especially for larger menus quite important!
Concerning any extension creating menus (like b13/menu) I suppose it could be opmizied probably by reducing the db-queries. There are certainly possibilities.
The linked code does concern only rootline menus probably but it's hopefully a clear example: https://stackoverflow.com/a/65613200/1019850
Thanks for providing this. I found it helpful, but a little bit complex and thus dificult to understand (not really a TypoScript friend here). I only used a very simplified version to cache the megamenu (main menu):