Round robin or least connections: which algorithm should I pick for my Load Balancer?

Question

I have two Droplets behind a DigitalOcean Load Balancer. It is set to round robin, which I think is the default. Some of my requests are quick and some take a few seconds, and I sometimes see one Droplet at 90% CPU while the other sits idle.

Is round robin the wrong choice for this? How do I know when to switch to least connections, and is there an easy way to see what each algorithm actually does with traffic?

Bobby · Answer

Hi there, Round robin sends requests to each Droplet in turn and ignores how busy they are. If some requests take a few seconds and others take a few milliseconds, one Droplet can end up with a pile of slow requests while the other sits idle. That matches what you are seeing. Least connections is the better fit for uneven request times. The load balancer sends each new request to the Droplet with the fewest open connections. Slow requests keep connections open longer, so the busy Droplet gets fewer new ones. DigitalOcean Load Balancers support both algorithms, and you can switch in the load balancer settings without touching your Droplets. Before you switch, check two things: Sticky sessions. If they are on, users stay pinned to one Droplet no matter which algorithm you pick. A few heavy users on one Droplet looks exactly like your 90% versus idle problem. Health checks. Make sure both Droplets are passing. If one is flapping, the other takes all the traffic. Also keep in mind that least connections counts open connections, not CPU. If your slow requests are CPU heavy but short, it will not help as much. You can confirm what is happening by counting requests per Droplet in the Nginx access logs: wc -l /var/log/nginx/access.log Run that on both Droplets, wait a few minutes, and compare how much each one grew. To see what each algorithm does with mixed fast and slow traffic, try this load balancer simulator . You can turn servers off and watch how traffic moves. It is a safe way to build a feel for it before changing production. My advice: switch to least connections, and turn off sticky sessions unless your app really needs them. Docs for the settings: https://docs.digitalocean.com/products/networking/load-balancers/

alexdo · Answer

Fetch(https://docs.digitalocean.com/products/networking/load-balancers/details/ ures/) Received 56.2KB (200 OK) Allowed by auto mode classifierSignificant finding, but I need to be precise before correcting Bobby. Let me checkwhether the algorithm field still exists in the API/doctl, since UI and API candiverge. Web Search(“DigitalOcean load balancer algorithm field deprecated round_robinleast_connections API doctl regional load balancer”)Did 1 search in 6s Allowed by auto mode classifier This is well-corroborated across sources. Let me confirm the most explicit statement directly from DigitalOcean’s own cloud-controller-manager docs. Ran 1 shell commandHeya, one important update on this, because it changes the answer: you cannot switch algorithm on a DigitalOcean Load Balancer anymore. The algorithm field is deprecated and ignored. DigitalOcean’s own cloud-controller-manager documentation states it plainly for the Kubernetes annotation, “Specifying this annotation does nothing, as the algorithm field on the API is ignored,” and the Terraform and Pulumi provider docs carry the same deprecation note. The field still shows up in the API as optional and deprecated, defaulting to round_robin, which is probably why it still looks like a setting, but setting it has no effect. DigitalOcean’s Load Balancer feature docs describe the current behavior instead: a single algorithm that “assigns new connections and requests to the backends as equally as possible,” which they state outperforms traditional round robin and least connections in nearly all cases.So the practical path is the rest of what Bobby listed, and those checks mattermore now that the algorithmSticky sessions are the firs are on, users stay pinnedregardless of distribution, and a few heavy users on one Droplet looks exactly likeyour 90 percent versus idleHealth checks second. A Dropnd out of the pool sendseverything to the other one. If both are clean and you still see the imbalance, the likely cause is request weight rather than request cU-heavy work per request isDigitalOcean’s Load Balancer feature docs describe the current behavior instead: a single algorithm that “assigns new connections and requests to the backends as equally as possible,” which they state outperforms traditional round robin and least connections in nearly all cases. So the practical path is the rest of what Bobby listed, and those checks matter more now that the algorithm lever is gone: Sticky sessions are the first thing to check. If they are on, users stay pinned regardless of distribution, and a few heavy users on one Droplet looks exactly like your 90 percent versus idle symptom. Health checks second. A Droplet that is flapping in and out of the pool sends everything to the other one. If both are clean and you still see the imbalance, the likely cause is request weight rather than request count. A few seconds of CPU-heavy work per request is not something any connection-distribution scheme evens out, since the balancer is counting connections, not wois on the application side,moving the slow work to a queue, or adding a third Droplet so a single slow request has less impact on the pool. Regards

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

Round robin or least connections: which algorithm should I pick for my Load Balancer?

Related questions

Backend Keepalive enabled automatically (DO Load Balancer)

Report this

Round robin or least connections: which algorithm should I pick for my Load Balancer?

Related questions

Backend Keepalive enabled automatically (DO Load Balancer)