This layer is about the basic services many CMS and web applications are based on: the web server, php and database. TYPO3 is relying on them, too. So it’s worth to have a closer look on the potential in optimizing this layer.
PHP
Much performance can be gained by a good php configuration.
REMOVE UNUSED PHP MODULES
Php provides many modules that add functionality to php. Each additional module increases the needed amount of RAM and CPU power. All modules needed and recommended by TYPO3 are documented in the Documentation for TYPO3 9LTS or in the INSTALL.md for version 8LTS and below. Other php modules than these should be removed (of course only if no other software makes use of them 😉 )
USE OPCACHE
The OpCache is a php module, which caches precompiled code for faster execution. This provides a huge performance improvement. For PHP version 5.6 and below the opcache is available as a module, from 7.0 on the opcache is built into the php core. This leads directly to the next topic:
PHP VERSION 5.6 -> 7.3
The general recommendation is to use the newest php version. Each version has significant performance gains. The biggest one is from 5.6 to 7.0 because the opcache was built into the PHP core. But also other version switches bring better performance. The switch from 5.6 to 7.0 brings a performance gain of 62%. The RAM consumption was lowered by 24%. And PHP 7.1 uses 26% less CPU power than PHP 7.0.
The other thing is that PHP 5.6 loses support and security updates on January 01, 2019. For PHP 7.0 the situation is even harder. The support will end on Dec. 3rd 2018 … this means in about six weeks! If a customer (or you) is still on on of the old versions, you should really consider to update php.
PHP CONFIGURATION
Even the php configuration will have impact on the performance. The three config settings, I want to mention here, are memory\_limit, pm.max_children' and max\execution\_time. The product of the memory_limit and the pm.max_children must always be below the size of the available RAM (reduced by the necessary RAM for the operating system and servers). If the memory limit is too high and one or more processes are “going wild”, these will block other requests being processed. Same is true for the execution time. It is better to have such requests killed, than having them block other requests.
PHP-FPM VS MOD_PHP
There are two installation methods for PHP: mod_php and php_fpm. The first one is the most common installation method, because it is quite simple to install and configure. It is started automatically within the Apache web server as a module.
The alternative is to use a php_fpm. It is a standalone service, where Apache acts some kind of proxy that passes the requests to php files to the server, receives the result and passes it to the client.
The FPM install has a quite high impact of the performance. Some numbers from Bitnami, an “application package provider” comparing the to methods. Apache with php_fpm needs about half of the RAM as the setup with mod_php does. Processed 50% more transactions in the same time transferred about 70% more data.
The numbers are from the 2014, but I would expect that, the modphp installation now does not perform better than the fpm solution, even if its performance issues got some love from the developers. The detailed number and the setup of the study can be found here: https://blog.bitnami.com/2014/06/performance-enhacements-for-apache-and.html
An installation of php as fpm is also necessary, if you want to run a php application wit the nginx web server, an alternative to Apache.
WEBSERVER: APACHE VS. NGINX
The probably most well known and supported web server is the Apache HTTPd. Most of us will use it in every day live. Most web hosters use it as their main web server for different reasons: history, documentation, user space configuration (aka htaccess support) and answered questions on many support platforms. TYPO3 provides (as many other projects) provide an example htaccess file. From TYPO3 9LTS on it is located at /typo3/sysext/install/Resources/Private/FolderStructureTemplateFiles/root-htaccess. That makes it easy quite easy to get kickstarted.
But there is an alternative: Nginx. Nginx was developed with performance in mind. The first version was published in 2004. Most high load web sites use nginx as their web server according to a Netcraft survey. If your hoster supports it, you should really consider using it. Unfortunately TYPO3 does not ship an example configuration AFAIK. But there is a pending ticket on forge.typo3.org, which may help you to get TYPO3 running with Nginx (https://forge.typo3.org/issues/54316).
HTTP VERSION: HTTP 1.1 VS. HTTP 2
Another thing is the HTTP version. The main advantage of HTTP2 over HTTP1.1 is, that it can deliver assets simultaneously to the client. In contrary to my statement in layer 2 “Combine javascript and css in as less as possible files”, it will give some performance improvement splitting them up into several files.
The other question is: “Can I use it?”.
The answer is simply “Yes”, as every major browser supports the HTTP2 protocol. Details about browser support are available here. Also both web servers Apache and nginx are supporting the “new” http protocol. Apache published an official guide, how to use it with version 2.4. If I understood several tutorials correctly, nginx (version 1.9.5 and higher) comes with HTTP/2 support out of the box. You just make sure that every “listen” directive contains the http2 parameter.
MYSQL
MYSQL QUERY CACHE
Also the Mysql server can be tuned. One part is the query cache. It stores the last queries in the hope that it can reuse them in the queries. The goal is to keep it as small as possible, while having many cache hits without quite a low amount of prunes. A good number somewhere in the 10ths of MB together with a cache limit of 256kB. But keep in mind, that the query cache can also lock up your installation, if there are many selects and insert at the same time. The reason is, that each INSERT, UPDATE or DELETE statement invalidates the cache for the table and the SELECT statement is looking for a cached query first before executing on the database. If you encounter issues with mysql performance, check and monitor the behavior of the query cache.
SQL PROXY
If you have performance issues, you can also pass your sql queries through a sql proxy like http://www.profilesql.com/. It helps you to track the sql queries sent to the server, shows the slow log and the explain output. Furthermore it is possible to profile single queries showing the single steps, mysql takes to answer your query. (Thanks to @Ichhabrecht for the tipp).
Also on the services level is some potential for performance improvements, These points are not TYPO3 specific, but can be applied to any web application, that relies on this server stack.
The next and last post in this series will be about the use of hardware and additional services.