Tula Networks
Documentation
Toggle sidebar

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.