I’m back again with some small issue, at least I hope it is.
The thing is, we’re trying to evaluate data of the last year.
To do that, we set the period in the matomo backend to “date range”
and set the range to the day one year ago, so we get 365 days.
Like, from 2020-11-09 to 2021-11-09, in todays case.
Now when I do that, I often get one or more widgets showing the following error:
“Oops… there was a problem during the request. Maybe the server had a temporary issue, or maybe you requested a report with too much data. Please try again. If this error occurs repeatedly please contact your Matomo administrator for assistance.”
I get the same error when I try to open the visitors overview.
Our server should be more than capable of handling this, so I guess this should
be some setting in the config so matomo can use more resources?
Does anyone know what settings this would be? Or where I can look into to get
the exact problem?
Here are some specs, if needed:
Visitors ~600K-700K a year ~50-70K a month
Archivation runs every 15min ( …/console console core:archive )
Old “raw” data is kept for 2 years
PHP Settings for Backend:
Memory-Limit 512M
Execution Time 240s ( but aborts way sooner )
PHP 7.4
I appreciate every helpful advice.
Also I’m sorry if this was asked before, but searching for “performance” gives way too many (mostly unrelated or outdated ) results
Custom Date ranges mean that Matomo needs to add up all data on the fly instead of just showing the reports that the Cronjob has created in the background. And with a large amount of data, this needs a large amount of time. So you could try to extend the maximum execution time before a PHP script is killed to avoid this error.
The thing with the execution time is, it’s already at 240 but the errors come up, seconds after the page / widget start loading. So I had my hopes up there would a separate setting in the matomo-config.
The thing with the yearly report is ( correct me if I’m wrong ), it’s only the current year ( like from beginning of 2021 ), not the last year in a 365-days sense, which is what we needed.
Yeah, as mentioned, this was not caused by the execution time. In fact I found the error in the logs ( why didn’t I think of this in the first place? ). Apparently the 512M where not enough memory to evaluate a complete year, so I set this first to 1024M and ended up with 2048M.
Since I can’t set this with htaccess or php.ini I set this via
ini_set('memory_limit','2048M');
in the index.php, which also means the setting does not affect the tracker-script ( which is good, imo ).
For everyone adapting to this: This also means you have to re-set this after a update, so beware.
In any case, thank you for helping me get on the right tracks.