Skip to content
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

Fix double query execution #3836

Merged
merged 1 commit into from Jul 2, 2019
Merged

Fix double query execution #3836

merged 1 commit into from Jul 2, 2019

Conversation

lippserd
Copy link
Member

Our monitoring list views call SimpleQuery::hasResult() first in
order to determine whether there are results to display. This calls
fetchRow() which executes the underlying query the first time. If there
are resulsts, the query is iterated which executes the query again.
With this patch, SimpleQuery::hasResult() makes use of the inner
iterator instead of calling fetchRow(). The query is now executed only
once.

Without patch

DescriptionOff (ms)Dur (ms)Mem (diff)Mem (total)
Bootstrap, autoloader registered0.0030.003682.06 KiB682.06 KiB
Action::postDispatch()260.597260.5947.01 MiB7.68 MiB
Counting all results started263.4382.84151.38 KiB7.73 MiB
Counting all results finished389.013125.575168.01 KiB7.89 MiB
Fetching one row started474.78485.7711535.91 KiB9.39 MiB
Fetching one row finished696.487221.7033.91 KiB9.40 MiB
Query result iteration started882.543186.05663.67 KiB9.46 MiB
Query result iteration finished911.22128.678391.45 KiB9.84 MiB
Fetching one row started912.7541.53334.02 KiB9.87 MiB
Fetching one row finished1003.54790.7932.43 KiB9.88 MiB
Response ready1100.53296.985292.98 KiB10.16 MiB

With patch

DescriptionOff (ms)Dur (ms)Mem (diff)Mem (total)
Bootstrap, autoloader registered0.0040.004682.06 KiB682.06 KiB
Action::postDispatch()321.780321.7767.01 MiB7.68 MiB
Counting all results started325.4373.65751.38 KiB7.73 MiB
Counting all results finished471.803146.366168.01 KiB7.89 MiB
Query result iteration started789.899318.0961602.69 KiB9.46 MiB
Query result iteration started790.2950.396-8.55 KiB9.45 MiB
Query result iteration finished818.66628.371400.41 KiB9.84 MiB
Fetching one row started819.8421.17634.02 KiB9.87 MiB
Fetching one row finished916.38096.5382.12 KiB9.88 MiB
Response ready985.69869.318293.29 KiB10.16 MiB

@lippserd lippserd requested a review from nilmerg June 26, 2019 09:20
@lippserd lippserd added this to the 2.7.0 milestone Jun 26, 2019
@lippserd lippserd added area/framework Affects third party integration/development bug Something isn't working labels Jun 26, 2019
Our monitoring list views call SimpleQuery::hasResult() first in
order to determine whether there are results to display. This calls
fetchRow() which executes the underlying query the first time. If there
are resulsts, the query is iterated which executes the query again.
With this patch, SimpleQuery::hasResult() makes use of the inner
iterator instead of calling fetchRow(). The query is now executed only
once.
@nilmerg nilmerg merged commit 6ea012a into master Jul 2, 2019
@nilmerg nilmerg deleted the fix/query-double-execution branch July 2, 2019 11:56
nilmerg added a commit that referenced this pull request Sep 26, 2019
Does not affect views which do not run a count query. (e.g. dashlets)
Though, this is a quick win for all other views with which the user
interacts directly and gets the desired result quicker than before.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Sep 26, 2019
…sults

28ec1e2 has no result on history views as they never count their results.
So restructuring this particular view script I deemed reasonable since the
history queries tend to show very poor performance.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Sep 26, 2019
Does not affect views which do not run a count query. (e.g. dashlets)
Though, this is a quick win for all other views with which the user
interacts directly and gets the desired result quicker than before.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Sep 26, 2019
…sults

28ec1e2 has no result on history views as they never count their results.
So restructuring this particular view script I deemed reasonable since the
history queries tend to show very poor performance.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Oct 8, 2019
Does not affect views which do not run a count query. (e.g. dashlets)
Though, this is a quick win for all other views with which the user
interacts directly and gets the desired result quicker than before.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Oct 8, 2019
…sults

28ec1e2 has no result on history views as they never count their results.
So restructuring this particular view script I deemed reasonable since the
history queries tend to show very poor performance.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Oct 11, 2019
Does not affect views which do not run a count query. (e.g. dashlets)
Though, this is a quick win for all other views with which the user
interacts directly and gets the desired result quicker than before.

refs #3905
refs #3836
nilmerg added a commit that referenced this pull request Oct 11, 2019
…sults

28ec1e2 has no result on history views as they never count their results.
So restructuring this particular view script I deemed reasonable since the
history queries tend to show very poor performance.

refs #3905
refs #3836
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/framework Affects third party integration/development bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants