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
Made reports faster when flat=1 is used. #7409
Conversation
Also replaceColumnNames is now queued again which should bring a performance boost in general.
@@ -337,6 +323,36 @@ public function getSocials($idSite, $period, $date, $segment = false, $expanded | |||
$this->setSocialIdSubtables($dataTable); | |||
$this->removeSubtableMetadata($dataTable); | |||
|
|||
if ($flat) { | |||
$urlsTable = Archive::createDataTableFromArchive(Archiver::WEBSITES_RECORD_NAME, $idSite, $period, $date, $segment, $expanded, $flat); |
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.
Here we need a special handling to make it fast as getSocials
does not really have a subtable...
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.
can you refactor this special handling in own method?
(or maybe even own filter if it makes sense)
if (Common::getRequestVar('flat', 0, 'int') === 1) { | ||
$view->requestConfig->filter_excludelowpop = 'nb_hits'; | ||
} else { | ||
$view->requestConfig->filter_excludelowpop = Metrics::INDEX_PAGE_NB_HITS; |
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.
un-related to this PR, but +1 toconsider removing this mix of Metrics ID and Named metrics... could you create an issue for this? (to store named metrics in archives rather than stored metrics ID)
Feedback
|
Made for reports faster when flat=1 is used.
Also
replaceColumnNames
is now queued again which should bring a performance boost in general for not flattened and not expanded reports.Eg in my dev vm A huge first level
getPageUrls
report loads in < 300ms. Half of that time is spent in Twig, about 1/4 in bootstrapping etc. We do now spend more time in JS (300-400ms on a fast computer with a fast browser) after the report is fetched than it takes to fetch it.