Optimise render-time link expansion for GraphQL (all editions, except ministers index page) #3102
+39
−11
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.
This makes two changes to optimise the performance of all edition (except ministers index page) render-time link expansion in GraphQL.
These two changes reduce the total response time for a GraphQL query on the prime minister's page from ~4,500ms (ActiveRecord: ~360ms) to ~3,200ms (ActiveRecord: ~250ms), when run locally in govuk-docker. The total request duration reduces from ~1,000ms to ~800ms, when queries are made against Publishing API in the integration environment.
1. Reduction in number of queries for link expansion
This halves the number of database queries needed to retrieve links when doing render-time link expansion on GraphQL queries, by combining the retrieval of link set and edition links into a single database query.
For example, this reduces the queries for rendering the prime minister page from 162 to 81.
2. Adding an index to optimise edition links
We are currently querying on
edition_id
andlink_type
in GraphQL'sLinkedToEditionSource
dataloader.At the moment, we are only using an index for the
edition_id
part of the query, not thelink_type
part as well.Adding a composite index to allow one index to handle both parts of this query.
Given the query (as generated by ActiveRecord):
Query explanation before new indices:
Query explanation after new index:
Trello card