feat: allow list items to be processed in parallel #738
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 PR introduces a new setting which allows items returned by
ListPager
to be processed in parallel.Currently, items are processed sequentially per resource. This is a problem if
populateResourceInfoHandler
is expensive. We internally have a custom resource which takes 1.5 milliseconds in thepopulateResourceInfoHandler
function due to a custom lua healthcheck script and a few ignored labels which are removed during diff normalisation. With over 50,000 of these custom resources, that's a 75 second overhead.With a parallelism of 8, we've seen a page of 500 items go from ~750ms to ~100ms. We've also seen the processing of a full list complete at roughly the same time as
ListPager
completes. Previously, processing of pages constantly lagged behind the retrieval.gobench
results:Before and after: