Various performance improvements, especially for Range period and installations with many sites #7119
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…d the metadata for each site and if one has 20k sites would request it 20k times!
…gers an event for each label in a datatable which can be many!
…ting the footerIcons. Instead cache the result to save many postEvents etc
This is a bit experimental and I need to see whether any test will fail. It takes a long time to generate subperiods for period=range. Eg requesting date=2015-01-04,2015-02-02&module=Referrers&action=getSearchEngines&period=range took about 700ms for each request of 1500ms in total. It now takes only 40ms which means it is 30-40% faster. With the other optimizations the request in total does now only take 700-800ms instead of 1500ms.
tsteur
added
c: Platform
mattab
added
the
Pull Request WIP
mattab
pushed a commit
that referenced
this pull request
Feb 9, 2015
Various performance improvements, especially for Range period and installations with many sites
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
allwebsites. If an installation has many websites we ended up building the report metadata for all sites. This takes a long time, especially since some reports get site information eggetFor('sitesearch'). If an installation has 100 Piwik websites it resulted in 100 queries topiwik_sitewhich resulted in 100 posted events inPiwik::setSiteetc.Referrers.getSearchEnginerequest if not more.date=last30&period=rangeabout 40% of the request time was spent in generating the sub periods. In one simple request we did this eg. 20 times for the same date range which took about 700ms on my server. As we cache it now it will take only about 35ms making all calls to range dates faster. I just this is more or less "only" a performance boost forflat=1as it looks like it generates the subperiods for each subtable. Note: If there was any long/endless running job this cache could result in a memory issue.On our demo test server this call does now take only about 0.75s instead of 1.7s:
index.php?date=2015-01-04,2015-02-02&module=Referrers&action=getSearchEngines&widget=1&isFooterExpandedInDashboard=true&flat=1&idSite=1&period=range