feat(cluster): ShardStatus V2 endpoint - optimizing response size for clusteringV2 ShardAssignmentStrategy #1926
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.
Pull Request checklist
Current behavior : The response size of
cluster/api/v1/{dataset}/status
is greater than ~37KB for a 256 shards cluster. This could utilize a lot of network bandwidth, especially if the status calls is used frequently across nodes of cluster.New behavior : Adding another endpoint
statusV2
, which compresses the shard status information in a bit map representation to reduce the response size from 37KB to 172 Bytes ( for a 256 shards cluster ). This doesn't makes any changes in the way we track the shard status and it's interaction with the actors. It is merely a wrapper on top of ShardMapper on the response time.NOTE: No breaking changes as we are not changing the way ShardMapper tracks the shard status. There is also no change to the existing Ask/HTTP/CLI calls.