matomo-org/matomo

Document using Matomo with OPcache and JIT compilation

Open

#17,390 opened on Mar 24, 2021

View on GitHub
 (4 comments) (0 reactions) (0 assignees)PHP (2,847 forks)batch import
Help wantedc: Documentationc: Performance

Repository metrics

Stars
 (21,513 stars)
PR merge metrics
 (Avg merge 8d 11h) (106 merged PRs in 30d)

Description

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

Contributor guide