Perform SQL matching of Build&Runner tags to greatly speed-up job picking
What does this MR do?
This makes jobs/request to be effectively O(1) request instead of O(n) where n is a number of non-matching jobs due to tags.
This puts tags matching work on the database, and given that all tags are loaded in the database anyway it makes it very cheap and only adds a very small overhead to the SQL query that chooses next job to pick. Looking at current gitlab.com queues it seems to make it unnoticeably slower.
This adds two additional checks to SQL. They were executed previously in Application, each of them generating around 3 SQL requests if we had 500 non-matching jobs we were generating around 1k SQL queries as it can be seen on https://performance.gitlab.net/dashboard/db/grape-endpoints?orgId=1&var-action=Grape%23POST%2Fapi%2Fjobs%2Frequest&var-database=Production.
Since this makes all matching to be done via SQL we effectively execute:
- Get Runner,
- Get Runner Tags,
- Get Next job to be queued,
- Get Runner Projects and Job Tags to perform consistency validation,
This is more like a band-aid solution, but it seems like a very low-cost band-aid that makes general CPU/SQL/API processing time way-way-way-way faster.
@yorickpeterse Let me know what you think about this.
This has a feature flag which is off by default. Our test suite actually tests with the feature flag on.
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessar -
Tests added for this feature/bug - Review
-
Has been reviewed by Backend -
Has been reviewed by Database
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Squashed related commits together