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
Live.getCounters times out on very large instance #7399
Conversation
$idSite, | ||
$lastMinutes, | ||
$segment, | ||
'COUNT(log_visit.visit_last_action_time)', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When using count(*)
and passing a segment eg pageUrl
this method fails. It took me a long time to figure out what is going on. Anyway, we do not get an error when passing a log_visit
field here and I made sure count(log_visit.visit_last_action_time)
is as fast as count(*)
as it still can do everything on the index and doesn't have to query the table.
* If we know there are 0 visits, do not execute any further query. * Added showColumns as it is more appropriate
Looks good to me! 👍 |
Live.getCounters times out on very large instance
fixes #6758
We do only display the number of visits and actions in the Real time widget so let's only request those. This should make it very fast as we can avoid the
visitors
counter which is slow. Eg the visitors counter takes a few seconds on many million rows whereas thevisits
counter standalone takes maybe0.05
seconds if at all. If someone uses the API it will be still "slow" on a very large instance.Adding a separate query for
visits
andvisitors
shouldn't make a huge difference as thevisitors
one is so slow compared to thevisits
one.In the actual "Live counter" widget we do only request the last 3 minutes were we shouldn't have any problem with the unique visitors counter as MYSQL will choose a different index automatically.
I added another tweak: If
visits
is0
we can assume that all other counters are0
as well so we do not execute any further query at all. We can assume this as we request thelast_action_time
so we should be sure there was no further action etc.