-
Notifications
You must be signed in to change notification settings - Fork 863
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix an issue where destinations are compared against themselves #2065
Conversation
@microsoft-github-policy-service agree |
Pull request was converted to draft
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a reasonable change to make, thanks!
Can you please also add a test that checks this specific concern?
E.g.:
- you have 2 destinations, one with 1000 requests and the other with 0
- if you do 100 calls to PickDestination, they should all give you the destination with less load
The failing test is
reverse-proxy/test/ReverseProxy.Tests/LoadBalancing/LoadBalancingPoliciesTests.cs
Line 75 in 4700674
public void PickDestination_PowerOfTwoChoices_Works() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
do | ||
{ | ||
secondIndex = random.Next(destinationCount); | ||
} while (firstIndex == secondIndex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fix suffers from the same issue as the original, a high collision rate in small sets. I think it'd be better to do a deterministic shift in those cases.
int secondIndex = random.Next(destinationCount);
if (secondIndex == firstIndex)
{
secondIndex = (irstIndex + 1) % destinationCount;
}
I'll send a PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MihaZupan convinced me that the +1 approach leads to non-trivial imbalance.
Even in the smallest case of two destinations where collisions will be common, the loop will only need to run a few times on average to break the tie. That's probably adequate.
The two calls to
Random.Next
may return the same index, so the comparison happens against the same destination. This behavior compromises the worst case protection this algorithm has because it might only use the worst destination, not offering opportunity of a better one. The fewer destinations we have, the more prominent this issue becomes.