Fetch service plan visibilities with eager loading #3507
Merged
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.
Previously the visibility was fetched per service plan. This could cause a high number of db queries when e.g. calling GET /v3/service_plans with a large page size.
This can be improved by:
service_plan_id
on postgres to reduce the query time. Mysql automatically creates this index due to the foreign key relationship.Both changes significantly increases the performance for
v3/service_plans
when the number of service plans with visibility type organization is high.Performance measurements - WITHOUT index
100_000 service_plans & 1_000_000 service_plan_visibilities
Parameters
Results for
GET v3/service_plans?page_size=5000
10 service_plans & 1_000_000 service_plan_visibilities
Parameters
Results for
GET v3/service_plans?page_size=5000
100_000 service_plans & 0 service_plan_visibilities
Results for
GET v3/service_plans?page_size=5000
Performance measurements - WITH
service_plan_id
indexDepending on the table size and possible values of entities in service_plans and service_plan_visibilities eager loading is actually slower than the current implementation.
This is caused by a large sequential scan in the database. To overcome this we introduced a index on column
service_plan_id
in table service_plan_visibilities30_000 service_plans & 6_000_000 service_plan_visibilities
Parameters
Results for
GET v3/service_plans?page_size=5000
I have reviewed the contributing guide
I have viewed, signed, and submitted the Contributor License Agreement
I have made this pull request to the
main
branchI have run all the unit tests using
bundle exec rake
I have run CF Acceptance Tests