New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Much faster Reports archiving when Action segment is used, on large Piwik analytics servers #9522
Comments
This requires further investigation as without the transition keys it still may be slow. Before implementing, we have to test many cases and most likely not only with this single query. |
we may have to postpone to 2.16.1 but let's see! |
Any news on this? |
@gebi can you post here, or in a separate issue, the slow queries from your mysql slow query log? |
Hi, @mattab. Did you manage to solve this issue? I have a Matomo installation running a few sites with a LOT of traffic. When I create segments, it takes forever to complete the archiving process. The query we detected as the problem was exactly the one you exposed in the first comment of this post. Original query (32.26 sec):
New query (0.01 sec [it seems it could solve the problem, but we have not implemented it on our Matomo]):
|
FYI: I don't think that query would be faster for most installations as this query can select heaps of rows (in worst case basically selects like all rows when no other sites are used on the same DB):
It is missing something like |
One thing that you could try is to enable the subquery segment cache which we may enable in the future see #8867 in your config/config.ini.php:
|
see #8867 |
The problem
It can take more than 1000s to execute a single query with action segment:
Explain extended with a standard DB (vanilla Piwik):
We can see that it's starting from log_visit and
index_idsite_datetime
is being used. So in such case, this query will be quite fast as it's limiting the data set using date range.Then this query for a big server with added additional indexes to speed up transitions report. Here's the result:
In this case MariaDB is trying to use
transitions_url
index however it's not being used at all.A faster query
Our SQL query above says:
If we replaced the WHERE statements with following:
Then the query takes 15 seconds to complete.
explain extended says that there are only 2M rows to scan:
Solution
Therefore the solution seems to be that, when
log_link_visit_action
is used in the query (ie. an action segment is used):replace
AND log_visit.idsite IN ('1')
intoAND log_link_visit_action.idsite IN ('1')
replace
AND log_visit.visit_last_action_time
byAND log_link_visit_action.server_time
-> then the
transitions_url
INDEX would be used.This would lead to massive performance improvements, where currently SQL query that often takes 30minutes would be then only 15s or so.
Notes
Thanks @quba for the find & report 👍
The text was updated successfully, but these errors were encountered: