An opcode cache is a system to cache the result of the PHP code compilation to bytecode. This allows to use the bytecode instead of compiling on every request. Different opcode cache systems are available, mostly depending on used PHP version. Currently usually OPcache is used.
Every opcode cache system has its own pitfalls, which we want to show here, so you can configure your system as good as possible and to get the message “This opcode cache should work correctly and has good performance.” in your TYPO3 installer. Opcode caching systems which aren’t listed here are not supported by TYPO3 CMS.
In general, PHP opcode caches can lead to a massive performance improvement of bigger PHP frameworks like TYPO3 CMS and can be seen as a must-have in professional production environments. All existing opcode cache solutions give a similar performance gain, the differences are insignificant. But the performance gain between using one and not using a opcode cache can be a factor of 3 in typical TYPO3 CMS installations. A well configured PHP environment on decent hardware usually delivers a full cached TYPO3 CMS frontend page in around 50 milliseconds or less. Enabling an opcode cache reduces this to 18ms or less! This gain is not so big for pages that are not delivered from cache, since the actual calculation time and database stuff has a bigger share than the compile time of PHP scripts. Still, opcode caches can lead to a massive performance gain and can make the website and the TYPO3 CMS backend more snappy.
General opcode cache considerations¶
Using opcode cache in CLI¶
The implementation of opcode cache system is done by using Shared Memory. This means only the same user from same process have access to it. The options apc.enable_cli or opcache.enable_cli do not give the ability to change/reset the opcode cache of the webserver. So for example package installation via CLI can lead to problems on the website as the opcode cache does not correlate to the new settings. This issue isn’t easy fixable and an outstanding issue.
(!) This issue applies to CLI scheduler tasks.
(!) Using ApcBackend, WincacheBackend, XcacheBackend as caching backend in your TYPO3 CMS installation will lead to the same problem. You can’t change the data from the website.
Opcode caches and PHP file changes¶
In a perfect world, opcode caches are fully transparent. That means, if PHP code is changed that is covered by an opcode cache, the opcode cache detects this change and invalidates its cache entry of the file. This works pretty well but it comes with overhead, since the opcode cache needs to check change times on files on every request. If you need maximum performance in production, disk load can be reduced by turning those checks off. If PHP files are changed then, the opcode cache must be explicitly hinted to invalidate its entries. Most opcode cache systems default to stat file changes everytime, OPcache defaults to only every 5 seconds, but this default behavior depends on your distribution.
This opcode caching system comes mostly with your PHP 5.5 (or newer) installation. It is derived from Zend Optimizer+ and maintained by the PHP developers.
Do not set opcache.save_comments and opcache.load_comments to false. Some internet pages mention this speeds up the website, but the code information which will be removed with this options is needed by Extbase and Fluid and therefore for TYPO3 CMS.
On live systems you can set the option opcache.validate_timestamps to false to gain a speedup. This prevents the cache from looking up every opcache.revalidate_freq seconds if there is a changed PHP file. If you update your system or an extension you should use the “clear opcode cache” button in the install tool to clear the complete opcode cache so the new files will be used.
Please open an issue report if you experience issues with the PhpCacheBackend and option opcache.validate_timestamps set to false.