The first two layers of the TYPO3 performance onion where about quite common topics valid for every website: (browser) caching and frontend optimization. The next skin level is about TYPO3 rendering and what TYPO3 integrators can do for the performance of the website.
Use static file cache extensions
The best thing is, when TYPO3 is not needed to deliver a web page to the visitor … no TypoScript code, no extensions or any other php code is involved.
You can achieve this using the extension “nc_staticfilecache” for TYPO3 versions up to 7.6.x or “staticfilecache” for TYPO3 version 8LTS and above.
These extensions save a fully cacheable TYPO3 web page to a single html file. Prior to the TYPO3 rendering, it is checked whether the file is there and delivered via a htaccess redirect. If not the request is forwarded to TYPO3 itself.
Cache content elements
But static file caching of pages is only possible, if all content elements on a page can be cached. Just one single plugin with a non-cached action, a single COA-INT or USER-INT content element will make the static file caching impossible.
Typically extensions providing a frontend login or language detection are candidates to break the caching. Also bad designed extension can be a reason for that. I will cover this topic in the next post of this series.
The caching of TYPO3 is not “completely broken” at this stage. It takes two TYPO3 rendering circles: The first one fetches the cached parts of the page. The second one fills in the non-cached content elements.
The solution is to load these content elements via ajax and an own page type.
Optimize TYPO3 Caching
TYPO3 comes with several caching backends. The default caching backends are the file and the database caching backend. But TYPO3 can also use Redis or Memcached. Both services keep the caching data in the RAM of the server. This reduces the need to query the database or to read from the filesystem.
A main difference between Redis and Memcached is, that Redis allows to save the cached data also on disk. This reduces or eliminates the time for the cache warmup after a restart of the server.
Another task is to optimize the caching tables. Per default all caching records are kept “forever” in the caching tables of TYPO3. This reduces the performance of the database queries to the caching tables as the tables grow over time. The solution is to create and activate the scheduler task, who does this job.
Deactivate logging and debugging
On develop and preview stages of a website, it is very convenient to have several logging and debugging possibilities available. After going live, this should not be necessary, as all errors should be tracked and corrected before.
The deprecation log is the one thing, which is activated on many sites. It can grow very quickly, especially if the website faces many requests and some extensions using deprecated functions. Each call of a deprecated function results in an write action on the file system. I saw websites with a 14 GB deprecation log on the live instance. This must not happen!
For TYPO3 V8 the deprecation log was completely rewritten and the requests are now collected in the database. That makes it less visible, but nevertheless harmful.
In the InstallTool (aka System Maintanance Area) the following options can bet set to reduce logging and debugging output:
- sysLogErrorReporting = 0 : No php errors will be logged in the configured syslog Services
- belogErrorReporting = 0 : No php errors will be tracked in the sys_log table
- systemLogLevel = 4 : Only log fatal errors the sys_log table
Another performance threat can be the size of the sys_log and sys_history tables. The larger they are the more time the requests on these tables needs. As with the deprecationlog and the caching tables, these tables can grow very large, unnoticed in the background. Fortunately, there are also scheduler tasks available which do the job to cleanup these tables. They will delete all records older than a certain period of time. This period is set in the scheduler task itself.
The general rule is to keep TypoScript as simple as possible. Especially conditions may harm the performance. They need much rendering time and will increase the the cache size exponentially.
Even if we like the traceability in git commits, it might be the better decision to write the one or the other condition in the database. Examples are
The content object
USER_INT are bad as uncached actions above. They prevent the caching via the static_file_caches mentioned above and will force TYPO3 into a second round of rendering.
Mount points are a page type used to “mount” complete page subtrees below another page. If only one is touched while creating the page tree, the function “initMPmap_create” is called. This function has up to 20 recursions, whether subtree is needed for the rendering or not.
A customer used mount points very often, leading to up to 9.000 additional DB queries per request, for example a rendered menu or the display of a root line. It hurts especially with so called “mega menus”.
So the easiest solution is, to avoid mount points. This needs some (or more) thoughts about the content strategy. If there is no viable solution, try to load the elements via an ajax call to prevent a render blocking of the rest of the website.
The rendering process of TYPO3 is a vital part of the system and as an integrator, you have some screws to optimize and enhance the performance.
The fourth layer will cover topics, which are essential for an extension developer.
In case you are interested in the other articles of this series, here is an overview of all already published posts:
- Layer 4 – Extension Development
- Layer 3 – Caching, TypoScript and more
- Layer 2 – Frontend Optimisation
- Layer 1 – Asset Delivery and Caching
- Introduction – Tools and Overview
I want to thank my supporters via patreon.com, who make this blog post possible. Unfortunately this week there is no new bronze sponsor. If you appreciate my blog and want to support me, you can say “Thank You!”. Find out the possibilities here: