Skip to content
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

Round robin load balancing #96

Merged
merged 2 commits into from
Apr 30, 2020
Merged

Round robin load balancing #96

merged 2 commits into from
Apr 30, 2020

Conversation

Tratcher
Copy link
Member

#72 While we debated more complex backend data storage mechanisms, I wanted to try something simple first. Built in algorithms can avail themselves of built in structures so I added the round robin state tracker to the existing BackendLoadBalancingOptions structure.

@Tratcher Tratcher added this to the 1.0.0-preview1 milestone Apr 24, 2020
@Tratcher Tratcher self-assigned this Apr 24, 2020
@@ -79,9 +80,13 @@ public BackendHealthCheckOptions(bool enabled, TimeSpan interval, TimeSpan timeo
public BackendLoadBalancingOptions(LoadBalancingMode mode)
{
Mode = mode;
// Increment returns the new value and we want the first return value to be 0.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd make the first value random - that way all requests don't all start out hitting the same server.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

? Every request increments the counter for an even distribution. It shouldn't matter where it starts, I only wanted 0 because it conceptually meets expectations (start the the top of the list and cycle through all entries).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a distributed deployment of YARP, all YARP instances would start out choosing the same target server if initial choice is const. There is some merit to making it random, but i reckon the benefit is minimal to negligible. In a practical deployment, it is unlikely that many instances of YARP would be (re-)started at precisely the same time, and even if they were, there is a lot of entropy that would help minimize hotspots to some extent. Further, anyone doing round-robin probably doesn't care about hotspots anyway.

@@ -41,7 +41,8 @@ public Task Invoke(HttpContext context)
var endpoints = endpointsFeature?.Endpoints
?? throw new InvalidOperationException("The AvailableBackendEndpoints collection was not set.");

var loadBalancingOptions = backend.Config.Value?.LoadBalancingOptions ?? default;
var loadBalancingOptions = backend.Config.Value?.LoadBalancingOptions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this being read per request?

Copy link
Member Author

@Tratcher Tratcher Apr 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it can be configured per route/backend, and can be changed if they are reloaded.

Copy link
Member

@halter73 halter73 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we create an issue to move RoundRobinState out of BackendConfig?

@Tratcher Tratcher merged commit 0c6751d into master Apr 30, 2020
@Tratcher Tratcher deleted the tratcher/roundrobin branch April 30, 2020 20:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants