@timscha opened this Issue on November 12th 2020

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.

@Findus23 commented on November 12th 2020 Member


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.

@timscha commented on November 12th 2020

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.

@tsteur commented on November 12th 2020 Member

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.

@timscha commented on November 12th 2020

@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).

@Findus23 commented on November 12th 2020 Member

That's amazing.

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)

@timscha commented on November 12th 2020

@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 :) )

@Findus23 commented on November 13th 2020 Member

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.

@timscha commented on November 13th 2020

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?

@Findus23 commented on November 13th 2020 Member


  • It is unrelated to JIT (it is disabled by default)
  • a diff between the config and my current one doesn't really show anything odd
  • testing nextcloud for comparison doesn't work as they don't support php 8 yet (same with Wordpress)
  • a website I wrote from scratch years ago loads as instantly as before with PHP 8 (but doesn't really use many complex features)
  • I am currently running xdebug profiling to find out more
@Findus23 commented on November 13th 2020 Member

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.

@timscha commented on November 13th 2020

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/"

@Findus23 commented on November 15th 2020 Member

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.

@tsteur commented on November 16th 2020 Member

btw in worst case we could ship Matomo 4 and disable merged assets automatically until we have a workaround.

This Issue was closed on November 16th 2020
Powered by GitHub Issue Mirror