endpointsharding: shuffle endpoint order before updating children #8438
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.
See b/412468630, and esp. comment 46. Essentially, if the connection order is not randomized then the first address gets hammered with all the client's initial requests when traffic is bursty. If multiple clients are all using the same order and many start up around the same time, then the first address can see that problem magnified even further. Randomizing at least spreads the load between the clients, even if it still results in one address getting hammered at startup.
The diffs are much smaller than it shows. Basically, the existing
e.s._test.go
was moved to..._ext_test.go
and the only new code is in..._test.go
._ext_test.go
is completely unchanged from the old_test.go
. Weightedtarget's tests needed changes because they assumed the order in which subchannels were created matched the order in which endpoints were provided.RELEASE NOTES: