Traffic
Load balancing methods
How requests are shared out across the servers in a pool. There are four ways to do it and one of them is right for almost everybody.
The four methods
| Method | What it does | When to use it |
|---|---|---|
| Round robin | One after another, in turn. | Almost always. It is the default and it is right. |
| Least connections | Whichever server has the fewest open connections right now. | When some requests take much longer than others, such as a mix of quick API calls and file uploads. |
| By address | The same visitor always reaches the same server. | Only when the application keeps things in memory per visitor and cannot be changed. |
| By a value you choose | The same value always reaches the same server, using a variable you name. | Caches and shards, where you want a given key to land on a given box. |
Consistent hashing
Offered with both hashing methods, and worth turning on whenever you hash at all.
Without it, taking one server out of a pool of four reshuffles roughly everybody. Every cache is suddenly cold and every pinned visitor moves. With it, only the share belonging to the changed server moves. Everybody else stays exactly where they were and never notices.
Weights
Weight is how much traffic one server takes compared to the others. Leave it at 1 unless one machine is genuinely bigger, then give it 2 to send it twice as much. Weights are a blunt tool and they are also the mechanism behind slow start and adaptive weighting, both of which move the weight for you.
What about least time?
The paid nginx has least_time, which sends each request to whichever backend is
answering fastest at that moment. Free nginx does not have it. Least connections tracks speed
reasonably well on its own, because a slow server piles up open connections.
Where you want something closer, adaptive weighting uses the response times the health checker is already measuring and nudges the weights. It reacts on a cycle rather than per request, so it is minutes and not milliseconds. For a pool of mixed hardware that works well. For traffic that spikes in seconds, least connections on its own reacts faster and you should just use that.
The honest advice
If you are choosing between these because your application keeps session state in local memory, the real fix is to move sessions into redis or your database. Then any backend can serve any visitor, you can use round robin, and you can take servers out whenever you like. Everything else on this page is a workaround for not having done that.
Common questions
Which method is fastest?
They all cost about the same to compute. The difference is which one matches how your application behaves, not raw speed.
Can I set the method per path?
The method belongs to the pool. If one path needs different behavior, give it its own pool, even if the servers in it are the same machines.
Does the weight affect health checks?
No. Every backend is checked at the same interval regardless of its weight.
Step by step instructions
The how to section has searchable, task shaped answers. Search it for balancing.
Related features
Backend pools
The list of servers behind a site, and how traffic is shared.
Read moreSticky sessions
Send the same visitor back to the same backend.
Read moreAdaptive weighting
Give the faster backends more of the work.
Read moreActive health checks
Probe every backend on a schedule and pull the dead ones out.
Read more