Which algorithm should I choose; is there a decision guide?

Short answer

The choice is made based on four questions: which algorithms the vService type offers, whether the servers have equal capacity, whether the connections are short or long, and whether the user needs to stay on the same server. In short: Round Robin is selected for equal servers, Weighted Round Robin for different capacities, Least Connection for long or variable-duration connections, and Least Response Time if response speeds differ; if persistence is required, a self-persistent algorithm or the Persistence setting is used.

Decision Table

Your situation	Recommended algorithm
The servers have the same capacity, the requests are short (typical web)	Round Robin
The capacities of the servers differ	Weighted Round Robin (+ Weight in the Backend Services)
Long-lived connections (LDAP, SQL, WebSocket)	Least Connection
The response speeds of the servers differ or vary	Least Response Time or Fastest
Bandwidth-heavy workload (downloads, media)	Least Bandwidth
Using a small number of servers by filling them up	First (+ Connection Limit in the Backend Services)
The same client IP should go to the same server (HTTP)	Source
The same content should go to the same server (cache servers)	URI
The same user or tenant ID should go to the same server (HTTP)	URL Param or HDR
RDP server farm (L7 TCP)	RDP Cookie
A single Backend Service	It does not matter

Step-by-Step Decision

1. vService type: Source, URI, URL Param and HDR are available only on HTTP; RDP Cookie only on L7 TCP. On the Network vService, if Protocol ANY - L3 is selected or Port Range is on, distribution is done only with Round-Robin or Weighted Round-Robin.
2. Capacity: If the servers are not equal, an algorithm that uses Weight is selected; the default Round Robin ignores Weight.
3. Connection duration: If the connections are long or their durations differ greatly, Least Connection, which looks at the current load instead of distributing in turn, is selected.
4. Persistence: If the user session is kept on the server, either a self-persistent algorithm (Source, URI, URL Param, HDR, RDP Cookie) is used, or Persistence (New cookie, Current cookie, Hash, Session Affinity Manager (SAM) on HTTP; Hash on L7 TCP) is used together with an algorithm that is not self-persistent. While a self-persistent algorithm is selected, the Persistence field is not visible; the two cannot be selected at the same time.

In TR7

• The algorithm is selected in the vService → Details → LB Algorithm box; the info line below it describes the selected algorithm.
• The algorithm tables in docs have a "Recommended Scenario" column for each algorithm (HTTP, L7 TCP, Network).
• The effect of the choice is monitored with the session and request counts of the Backend Services on the Live Stats screen of the vService.

Common Misconceptions

• "There is a single best algorithm." The right choice depends on the type of traffic; for short HTTP requests, Round Robin is sufficient.
• "Entering Weight is enough." The default Round Robin ignores Weight; an algorithm that uses Weight must be selected.
• "A hash-based algorithm distributes evenly." The distribution depends on the variety of the values; users behind NAT or a small number of distinct values can skew the distribution.

How it is done in the documentation

• HTTP (L7) vService · Algorithms
• L7 TCP vService · Algorithms
• Network vService · Algorithms
• HTTP (L7) vService · Session Persistence

Related questions

• Which load balancing algorithms are supported?
• When is Least Connection better than Round Robin?
• How do I know whether my application needs persistence?