I tried Matomo 4 RC2 and 3 with RC3 of PHP8.
While pages like settings are ok, the dashboard was very slow and stopped loading. I saw the menubar of Matomo, but nothing more loaded. After I switched back to PHP 7.4 everything worked as expected.
Key facts: nginx, MariaDB 10.5, PHP running as FPM with it's own pool.
Please let me know which logs do you need and I am happy to deliver them to you.
Can you make sure that the PHP 8 php.ini is the same (or similar) as the ones for PHP 7.4?
In my tests (to be fair not in production), loading pages with PHP 8 was as instant as before.
Yes. It's the same. One thing I had to change was the value of the max_execution_time. 30 seconds were to short as I got fatal erros in the nginx log. But the rest is almost identical, no other messages shown.
Hi @timscha Is JIT active maybe? Would try disabling it maybe (I think that's the ini setting
opcache.jit_buffer_size=0). Maybe it's not optimising the right things or not correctly configured or so.
@tsteur: I disabled it without any success (restarted fpm of course) and confirmed that JIT under Zend OPcache is disabled.
There are more options regarding JIT, like "auto_globals_jit" and "PCRE JIT Support" booth are still enabled. I am not sure if these can affected Matomo also (I'm not a PHP developer).
I just installed php8.0-fpm (from https://deb.sury.org/) on my server and did nothing apart from changing the nginx config to point at php8.0-fpm.sock. And indeed I can reproduce exaclty this:
Everything loads really slow (logging in took about a minute) and I only see the navbar as the JS and CSS requests run into a timeout after 30s.
I'll look into this further.
Update: System Check only shows green ticks (once it finally loads)
@Findus23: Exact the same setup and behavior on my server. Also using the php binaries from sury.
And yes, the System check is green (after hours of loading :) )
Hm, the tests I did before (where everything worked fine) I did with a self-compiled PHP-fpm binary. So I wouldn't be surprised if the very extensive php.ini that ships with all debian packages is at fault here.
I'm not too much into that, but 7.4 are shipped with a also extensive ini. Maybe it's one of the new options introduced with 8.0?
Okay, it seems like only the JS/CSS requests are slow, if you disable merging of the assets (https://matomo.org/faq/troubleshooting/faq_135/) Matomo is usable.
The main part might be JShrink running for a very long time.
That was the reason why I had to extend the max execution time, as I found this in my logs:
2020/11/12 15:33:42 [error] 2524384<a href='/2524384'>#2524384</a>: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/vhosts/matomo/public/vendor/tedivm/jshrink/src/JShrink/Minifier.php on line 182" while reading response header from upstream, client: 90.187.x.x, server: matomo.yoursecure.space, request: "GET /index.php?module=Proxy&action=getCoreJs&cb=7dc565129a4c06c23e746d200d6dec16 HTTP/2.0", upstream: "fastcgi://unix:/var/run/php8.0-fpm-matomo.sock:", host: "matomo.myhost", referrer: "https://matomo.myhost/"
It seems like this is indeed a bug in JShrink as it even takes ages when using the most simple PHP script.
I reported it in https://github.com/tedious/JShrink/issues/96
It also turns out that this also doesn't work with my self-compiled PHP, but I never noticed it as I had
disable_merged_assets = 1 enabled for testing which circumvents JShrink.
btw in worst case we could ship Matomo 4 and disable merged assets automatically until we have a workaround.