Using OPcache can speed up Matomo quite a bit as it avoids having to interpret the same PHP with every single page request.
Especially now with PHP 8 and JIT compiling (which is implemented as a part of OPcache) it might bring even more of a performance benefit.
There also should be no disadvantages (apart from a bit of memory usage from the cache) as Matomo already clears the cache on update/installs and for an application like Matomo everyone should be using
opcache.validate_timestamps=1 which slows down the cache a bit, but should avoid ever serving something different than the PHP file (maybe check
So I think we should:
A bit more experimental, but especially with the JIT feature of PHP 8 it might also be interesting to look into opcache for php-cli. Generally most people recommend not using OPcache for php-cli as it is a in-memory cache which would mean that a new php-cli process would start with a fresh cache making it useless. But since PHP 7 one can alternatively use a file cache (
opcache.file_cache) which would stay between calls and with the JIT compiler some hot loop during archiving might receive
quite a bit of speedup. (I have not yet tested Matomo with JIT)
Slightly related: If someone wants to do testing with OPcache, I can recommend https://github.com/amnuts/opcache-gui which gives a nice overview over the current cache status
https://plugins.matomo.org/DiagnosticsExtended contains a system check urging people to enable OPcache and checks a few options for correctness.
We can add a system check opcache but we won't add it for now for JIT as it takes too much time to performance test it etc.
When system check is executed on CLI then we don't expect opcache to be enabled as it's usually not recommended and won't really help with performace. Eg when archiving on the CLI most of the time will be spent in database and aggregating data in PHP.