-
-
Notifications
You must be signed in to change notification settings - Fork 339
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
Improve performance by splitting query details off into seperate table #481
base: master
Are you sure you want to change the base?
Conversation
@auvipy could you hit the button to approve the workflow run? |
@@ -0,0 +1,38 @@ | |||
# Generated by Django 2.2.24 on 2021-06-24 09:54 | |||
|
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.
is this migration handwritten? or auto generated
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.
The code inside the migration was handwritten, the file was autogenerated using ./manage.py makemigrations silk --empty --name fill_query_details
Codecov Report
@@ Coverage Diff @@
## master #481 +/- ##
==========================================
+ Coverage 82.83% 84.32% +1.48%
==========================================
Files 50 53 +3
Lines 2051 2086 +35
==========================================
+ Hits 1699 1759 +60
+ Misses 352 327 -25
Continue to review full report at Codecov.
|
@ErwinJunge This is a candidate for merge if tox tests can be passed. |
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.
could you please rebase?
This PR aims to improve the performance of silk by splitting the query details off into a seperate database table.
Some background information: The current system stores the details of the queries directly inside the query table itself. This leads to a very wide table and consequently few tuples per page, which makes doing aggregates over large tables very expensive in IO since the database has to load all the pages into memory.
What this PR does to fix that is pull the details that aren't used in the overview pages out of the main table and into a seperate table. This decreases the width of the main table, leading to more tuples per page and therefore less IO when generating overviews.
Specifically, in our production environment the sqlquery table has >3M rows. This lead to the overview page taking more than a minute to load and therefore timeout. With these changes, the overview page takes ~9s. Still long, but at least it doesn't timeout anymore.