@Findus23
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 opcache.revalidate_freq).
So I think we should:
- encourage more Matomo users to enable OPcache
- document recommended settings
- add a system check to warn against bad settings and generally recommend setting it up
(for reference: Nextcloud shows a system check warning if it isn't set up)
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.