You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue #5211 was looking into the issue of op catch up performance.
It has a lot of data, but as result of it, I've started implemented concurrent op retrieval
#5393 issue was tracking first part of it - implementation of capability, but also a policy of 4 concurrent requests in fetch-tool, with no change in DeltaManager.
This issue tracks future impartments in this space, including
moving code into driver-utils for drivers to be able to leverage it
changing driver interface to be streaming interface and not using batches at that API boundary
coming up with actual policy for DeltaManager / OPSP driver.
The text was updated successfully, but these errors were encountered:
Implements and closes#5393
Implement ability to to do multiple parallel requests to storage to speed up retrieval of ops.
This change implements ability to do concurrent fetches. It does not change behaviour of DeltaManager for now, and only enables this new capability in fetch-tool with 4 parallel requests by 20K ops.
Future work in this area is tracked by issue #5523.
This new capability will help in following scenarios:
- Boot from cached (stale) snapshot (in future)
- Being offline for a day - week (in future)
- fetching a lot of ops using fetch-tool (in this PR)
IN future, I'll refactor this approach into an adapter layer that drivers could use to implement parallel requests (or not), as well as their batching strategy.
An API that will be exposed from driver will be an IReadPipe API and full (including infinite) request, where DeltaManager no longer would control batching or parallelism.
It's easy to start with no parallelism and add concurrency (workers) later. We need to explore that such that we start with one request and add more parallel requests only when we know we are far behind. That will reduce pressure on storage (extra empty requests for nothing).
Issue #5211 was looking into the issue of op catch up performance.
It has a lot of data, but as result of it, I've started implemented concurrent op retrieval
#5393 issue was tracking first part of it - implementation of capability, but also a policy of 4 concurrent requests in fetch-tool, with no change in DeltaManager.
This issue tracks future impartments in this space, including
The text was updated successfully, but these errors were encountered: