Matomo extremely slow / unusable

escalated

(Léon Melis) #1

Hi,

I have been experiencing Matomo being extremely slow, making it completely unusable.

  • Dashboard login screen takes ~30 seconds just to render
  • Dashboard login usually times out
  • Tracking requests takes ~8 seconds

Environment:

  • Matomo 3.9.1
  • OpenBSD 6.5
  • PHP 7.2.17 (tested both through mod_php and FPM)
  • Apache 2.4.39
  • MariaDB 10.0.38

This server has barely any load, others sites on this server run just fine.

What I have tried so far:

  • Ran core:archive from console
  • Ran diagnostics:run, it warned about some folder permissions, I fixed that
  • Clean reinstall of Matomo
  • Reload of webserver

There is nothing in the Apache logs except the occasional timeout (php runtime exceeds my limit of 30 seconds).

I expect this to be some restriction caused by OpenBSD (by default php config is very restricted on OpenBSD). But I have no idea how to debug Matomo and find out what is causing the slow response.

Can anyone help me with some tips on how to debug this?

BTW: I have found a similar problem here: All Pages Very Slow - New Install but there seems to be no solution either.


(Lukas Winkler) #2

Hi,

Matomo should never be that slow unless you track a huge website on a Raspberry Pi, so there seems to be something going wrong.

I’d recommend you to set up a php profiler like blackfire or xdebug and take a look what exactly is taking this long in every request.

Do you by chance block outgoing requests from the server that wait until they time out? In that case you can configure Matomo to never make requests to the internet: How do I configure Matomo on a server without Internet? FAQ - Analytics Platform - Matomo


(Léon Melis) #3

When looking through the logs, I found this:

 Fatal error:  Maximum execution time of 30 seconds exceeded in /var/mysite/stats/matomo/vendor/matomo-org/jshrink/src/JShrink/Minifier.php on line 244, referer: https://stats.mysite.com/
 Stack trace:, referer: https://stats.mysite.com/
   1. {main}() /var/mysite/stats/matomo/index.php:0, referer: https://stats.mysite.com/
   2. require_once() /var/mysite/stats/matomo/index.php:27, referer: https://stats.mysite.com/
   3. Piwik\\FrontController->dispatch() /var/mysite/stats/matomo/core/dispatch.php:34, referer: https://stats.mysite.com/
   4. Piwik\\FrontController->doDispatch() /var/mysite/stats/matomo/core/FrontController.php:165, referer: https://stats.mysite.com/
   5. call_user_func_array:{/var/mysite/stats/matomo/core/FrontController.php:589}() /var/mysite/stats/matomo/core/FrontController.php:589, referer: https://stats.mysite.com/
   6. Piwik\\Plugins\\Proxy\\Controller->getCoreJs() /var/mysite/stats/matomo/core/FrontController.php:589, referer: https://stats.mysite.com/
   7. Piwik\\AssetManager->getMergedCoreJavaScript() /var/mysite/stats/matomo/plugins/Proxy/Controller.php:48, referer: https://stats.mysite.com/
   8. Piwik\\AssetManager->getMergedJavascript() /var/mysite/stats/matomo/core/AssetManager.php:179, referer: https://stats.mysite.com/
   9. Piwik\\AssetManager\\UIAssetMerger\\JScriptUIAssetMerger->generateFile() /var/mysite/stats/matomo/core/AssetManager.php:284, referer: https://stats.mysite.com/
  10. Piwik\\AssetManager\\UIAssetMerger\\JScriptUIAssetMerger->getMergedAssets() /var/mysite/stats/matomo/core/AssetManager/UIAssetMerger.php:52, referer: https://stats.mysite.com/
  11. Piwik\\AssetManager\\UIAssetMerger\\JScriptUIAssetMerger->getConcatenatedAssets() /var/mysite/stats/matomo/core/AssetManager/UIAssetMerger/JScriptUIAssetMerger.php:40, referer: https://stats.mysite.com/
  12. Piwik\\AssetManager\\UIAssetMerger\\JScriptUIAssetMerger->concatenateAssets() /var/mysite/stats/matomo/core/AssetManager/UIAssetMerger.php:97, referer: https://stats.mysite.com/
  13. Piwik\\AssetManager\\UIAssetMerger\\JScriptUIAssetMerger->processFileContent() /var/mysite/stats/matomo/core/AssetManager/UIAssetMerger.php:109, referer: https://stats.mysite.com/
  14. Piwik\\AssetManager\\UIAssetMinifier->minifyJs() /var/mysite/stats/matomo/core/AssetManager/UIAssetMerger/JScriptUIAssetMerger.php:83, referer: https://stats.mysite.com/
  15. JShrink\\Minifier::minify() /var/mysite/stats/matomo/core/AssetManager/UIAssetMinifier.php:57, referer: https://stats.mysite.com/
  16. JShrink\\Minifier->minifyDirectToOutput() /var/mysite/stats/matomo/vendor/matomo-org/jshrink/src/JShrink/Minifier.php:115, referer: https://stats.mysite.com/
  17. JShrink\\Minifier->loop() /var/mysite/stats/matomo/vendor/matomo-org/jshrink/src/JShrink/Minifier.php:147, referer: https://stats.mysite.com/

Then I found this post: JShrink has broken things · Issue #4970 · matomo-org/matomo · GitHub

I (temporarily) raised the timeout to 120 seconds, which allowed the script to finish. This sped up Matomo a bit, but it’s still not really usable. The widgets in the dashboard take about 10 seconds each to load.

I disabled the internet features like you suggested, but that doesn’t make a difference

I’d prefer not having to install and run xdebug on a production server, so is there anything else I can check before having to resort to a debugger?


(Léon Melis) #4

Found another suspicious issue:

When running diagnostics:run from the console, I noticed this:

Unable to test if mod_pagespeed is enabled: the request to http://unknown/var/mysite/stats/matomo/console?module=Installation&action=getEmptyPageForSystemCheck failed

Notice that Matomo it is trying to fetch http://unknown.

I didn’t notice this before, because it is displayed as a green INFO line so I skipped over it while checking the output of the diagnostics.


(Lukas Winkler) #5

I suspected that maybe there was some issue with Matomo in OpenBSD as I think noone in the team has tested it yet.
As I have never used any BSD os before, I just installed it in a vm and tried to set up Matomo (everything should be the same version as for you, but I used the default httpd)

While some features aren’t working as I haven’t installed the needed PHP modules (curl and gd), Matomo works fine and loads really quickly.

So I can’t think of any reason at the moment


(Matthieu Aubry) #6

Tracking requests taking 8-10s is very unusual. The only thing i can think of is, are you using some sort of slow NFS disks or other network mounted disks? just make sure all Matomo files are not on NFS ever.


(Léon Melis) #7

We have Matomo installed on a modern Xeon machine with SSD storage, the machine is virtual but we haven’t had any performance issues with storage. The machine runs other services (with the same php/apache/mysql setup) and they all perform like expected. So I have no indication the performance issues are due to hardware or storage.

I’m experimenting with various PHP and Apache settings to see if that makes any difference. If I find something I’ll make sure to share that here.