Load Balancing Algorithms
Available algorithms and when to use each
Load Balancing Algorithms
The load balancing algorithm determines how Tula distributes incoming traffic across the backend servers in a pool. Selecting the right algorithm depends on the characteristics of your application, the uniformity of your backend servers, and whether clients need to be consistently directed to the same server.
Available Algorithms
Round Robin
Round Robin is the default algorithm. It distributes requests sequentially and evenly across all healthy backend servers, cycling through the pool in order. Each backend receives an equal share of traffic regardless of current load or response time.
Round Robin works best when backend servers are identically configured and requests impose a roughly uniform workload.
Weighted Round Robin
Weighted Round Robin extends Round Robin by assigning a numeric weight to each backend server. Servers with higher weights receive a proportionally larger share of traffic. For example, a server with weight 3 receives three times the traffic of a server with weight 1.
This algorithm is useful when backend servers have different capacities, ensuring that more powerful servers absorb a greater share of the workload.
Least Connections
Least Connections routes each new request to the backend server with the fewest active connections. This approach naturally adapts to varying request processing times, directing traffic away from busy servers and toward those with capacity.
Least Connections is well suited for workloads where request duration varies significantly, such as APIs with a mix of lightweight reads and heavy computation.
Weighted Least Connections
Weighted Least Connections combines connection awareness with capacity weighting. The algorithm selects the backend with the lowest ratio of active connections to assigned weight. This accounts for both current load and server capacity, making it the most adaptive general-purpose algorithm.
Source IP Hash
Source IP Hash computes a hash of the client's source IP address to consistently assign that client to the same backend server. As long as the set of healthy backends remains stable, a given client IP will always reach the same server.
This provides session persistence at the network layer without requiring cookies. It is commonly used for L4 VIPs or protocols that require client affinity such as FTP. Note that Source IP Hash may produce uneven distribution when clients connect through shared NAT gateways.
URI Hash
URI Hash computes a hash of the request URI and assigns the request to a backend based on that hash. Requests for the same URI are always directed to the same backend, which maximizes cache hit rates when backends maintain local caches.
This algorithm is only available for Layer 7 (HTTP/HTTPS) VIPs and is particularly effective for content delivery workloads and caching proxies.
Algorithm Comparison
| Algorithm | Distribution | Server Affinity | Best For |
|---|---|---|---|
| Round Robin | Equal | None | Uniform workloads, identical servers |
| Weighted Round Robin | Proportional to weight | None | Mixed-capacity servers, uniform requests |
| Least Connections | Adaptive | None | Variable request duration |
| Weighted Least Connections | Adaptive + weighted | None | Mixed capacity + variable duration |
| Source IP Hash | Hash-based | By client IP | L4 persistence, NAT-friendly environments |
| URI Hash | Hash-based | By request URI | Caching proxies, static content servers |
Choosing an Algorithm
For most deployments, Round Robin is a safe starting point. If your backends have different hardware specifications, switch to Weighted Round Robin or Weighted Least Connections. If your application requires client affinity at Layer 4, use Source IP Hash. For cache-heavy workloads behind an L7 VIP, URI Hash can meaningfully improve hit rates.
The algorithm is configured per VIP and can be changed at any time. After changing the algorithm, apply the configuration to activate it.