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

Optimize summary queries #1479

Merged
merged 2 commits into from Apr 14, 2019
Merged

Conversation

cproensa
Copy link
Contributor

@cproensa cproensa commented Mar 11, 2019

Further improvements for summary page performance, targeting queries that use bug history table.

To put the recent changes of summary page in perspective:
my locally measured times, in a summary page for 50k issues.
MariaDB 10.3

  Total DB time Total page time
Release-2,19,0 13,1623 14,4944
  12,4130 13,5943
  12,3068 13,4926
     
master 4,4554 5,8133
  4,3266 5,5710
  4,2514 5,4992
     
This PR 1,5704 1,8281
  1,4995 1,7396
  1,4600 1,7086

Fixes #25693

@cproensa
Copy link
Contributor Author

cproensa commented Mar 11, 2019

I have tested mariadb, mysql, pgsql and oracle
Can't test mssql at the moment, as adodb+sqlsrv5.6+php7.3 is broken

Copy link
Member

@dregad dregad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @cproensa nice work !
Just a quick code review for now, will test later on.

core/database_api.php Show resolved Hide resolved
core/database_api.php Outdated Show resolved Hide resolved
core/database_api.php Outdated Show resolved Hide resolved
core/summary_api.php Outdated Show resolved Hide resolved
core/summary_api.php Outdated Show resolved Hide resolved
The query for issues time stats is based on bug history, and history
queries are expensive when scanning a lot of issues.
The previous query retrieves all individual times for each issue, and
then processes all the rows to find the maximum, average, etc. This
processing, for a big number of issues, adds a considerable time to the
function execution.

With this change:
- Introduce a database api check to know if window functions (analytic)
  are supported by current database.
- When window functions are availabe, perform a query that computes the
  aggregated values by itself. The result is now only one row.
- When window functions are not available, perform the simple, non
  aggregated query as before.

The time cost for the windowed query is very similar to the previous
version, but it improves:
- No postprocessing time.
- By returning one row, it can be effectively cached by the database,
  and further reduce times in succesive page loads.
Summary queries for bug history are the most expensive queries.
Rewrite the queries for open/resolve count to be performed in a single
query.
@dregad
Copy link
Member

dregad commented Apr 13, 2019

@cproensa Do you have an issue in the bugtracker for this ?

@dregad
Copy link
Member

dregad commented Apr 14, 2019

Opened #25693 to track this.

@dregad dregad merged commit 0abb605 into mantisbt:master Apr 14, 2019
dregad added a commit that referenced this pull request Apr 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants