The fourth layer of the TYPO3 performance onion is about TYPO3 extensions. Extensions are the major part of TYPO3, when is comes to extend to core functionality. Saying this means, that they have a major impact on the performance of a TYPO3 driven website.

Use cached actions

TYPO3 Extbase provides two types of actions: cacheable and non-cacheable one. The result of a cacheable action is reused in the next call of the page. Non-cacheable actions are rendered each time, when the page is called. The non-cacheable actions take precedence over the cached ones.

All actions are defined in the file ext_localconf.php of an extension. The definition is done by calling the funtcion \TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin. The third and fourth argument is an array defining the actions. If there are duplicates, you should check, whether the non-cached action(s) in the second array are really necessary; if not, just remove them.

But be careful, if you act with personal user data. Caching such actions may lead to unwanted side effects, like showing user names or other personal data for other visitors.

BTW, same is true for the plain old piBase based extensions. There are two types: USER and USER_INT. The USER_INT piBase plugins are not cached, whereas plugins of the type USER can be cached.

Use caching framework

The caching framework is not only a thing, which can be used by the core and system extensions. Every extension can make use of it. 

I would like to write some more lines about it, but I did not use it myself until now. Reason is, that I am not the “Hard Core Extension Developer”. If you want to write an article about that, just contact me. :-)

Nevertheless the documentation is available at https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/CachingFramework/Developer/Index.html. Also the extensions “news” provides a working example, if you want to dig a little bit deeper.

ViewHelpers: CompilableInterface and renderStatic

The TYPO3 Fluid viewhelpers got a major performance enhancement already in TYPO3 version 6.2. Back then, the CompilableInterface was defined, which can improve the performance significantly. So if a viewhelper is used more often, then consider to implement the CompilableInterface and provide a static render method next to the common public render method.
Markus Klein wrote a good introduction and howto on that topic at the reelworx blog.

Code efficiently (RAM and CPU)

Some days ago I read a tweet saying the following:

1969:
-what’re you doing with that 2KB of RAM?
-sending people to the moon

2017:
-what’re you doing with that 1.5GB of RAM?
-running Slack

This shows a development of the last decades quite good: The cost of CPU power and the RAM declined very much, leading to a some kind of reckless handling of both. Additionally the local development environments got more and more capacity for the same reason. The result is, that just another millisecond or another kByte of RAM more do not seem to count. But if the extension is used on a high traffic website (or on a very small hosting package), these small numbers will add up to decent numbers and have great effect on the performance.

It is easy to say: Do that efficiently and have a look at the needed resources. But that does not really help, as those feeling cannot be measured. The good thing is, that there are some tools around that do exactly this job.

XhProf / Tideways

XhProf was released back in 2009 by Facebook to provide a profiling tool for PHP. Facebook dropped the (active) development, because it is running its website on HHVM and not on the Zend core any more, a company tideways stepped in, built a service around it and made it compatible with php 7.x.

This profiler can be can completely independent from the service. The output format is the same as with the old XhProf. So the visualization from back then, will work with the Tideways output.

The home of tideways is https://tideways.com/profiler/features

blackfire.io

Another tool and service is blackfire.io. It provides nice graphical interface to the various performance metrics like wall time, CPU usage or memory or SQL requests.

The good thing is, that there is an official TYPO3 integration. Susanne Moog wrote the TYPO3 specific metrics and recommendations. A recommendation in the sense of blackfire.io is “a built-in performance test, that shows up only when relevant”.

Blackfire.io will only work with an account on their platform. There is a “Hack” service level, which is free of charge.

Details are available on https://blackfire.io/features.

Database recommendations

The last tip in on this layer is to have a look at the database settings of an extension. This is the stuff, which is defined in the file ext_tables.sql.

The main performance win will be to set database indices. Setting these properly can speed up the performance of an extension very much, if it uses many database queries.
On stackoverflow there is a quite good summary of some rules of thumb about this topic. They give a good start for optimizing database tables:
https://stackoverflow.com/questions/687986/what-are-some-best-practices-and-rules-of-thumb-for-creating-database-indexes/688006#688006

Final words

Also as an extension author, you can contribute to the performance of a website easily, if you keep theses recommendations in mind and use at least some of them.

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

Credits

I want to thank all my supporters, who make this blog post possible. This week I want to say thanks to Alexander Kellner (@einpraegsam) from in2code.de, who stepped in as a silver sponsor. BTW, this series of articles is a result of a talk, I held at the TYPO3 University Days in 2017.

If you want to follow his example, have a look at the possibilities to support me. TIA. ;-)

I found the blog post image on pixabay . It was published by jingoba under the CC0 public domain license. It was modified by myself using pablo on buffer.