How do Least Response Time and Least Bandwidth work; why do they sometimes behave like Least Connection?

Short answer

Least Response Time selects the server with the lowest value of active request count × average response time ÷ Weight; traffic is directed to the servers that respond the fastest. Least Bandwidth selects the server carrying the least bandwidth at that moment (bytes/second, scaled by Weight). They can behave like Least Connection for two reasons: (1) if the Core Engine version of the vService does not support these algorithms, distribution is applied as Least Connection and a message stating this appears in the vService status; (2) if the response times of the servers are close to each other or traffic is low, the calculation is effectively reduced to the number of open requests.

How Does It Work?

	Least Response Time	Least Bandwidth
Criterion	Active requests × average response time ÷ Weight	Bytes/second averaged over the Bandwidth Window, scaled by Weight
Additional field	Time Metric: Total Time (queue + connection + response; default) or Response Time (response time only)	Bandwidth Window: default 10 seconds, range 1 second – 1 hour
Suitable load	Servers with different or variable response times	Bandwidth-heavy loads such as downloads, media and streaming
vService type	HTTP, L7 TCP	HTTP, L7 TCP

On an L7 TCP vService, the measured time is the duration of the connection; a server with long sessions can appear slow. For this reason, Least Response Time gives the most meaningful result on an HTTP vService.

Why Does It Behave Like Least Connection?

1. The core engine does not support it (definite switch). Least Response Time and Least Bandwidth depend on the Core Engine version on which the vService runs. If the selected version does not support these algorithms, distribution is applied as Least Connection and the message "The selected core engine does not support: …" appears in the vService status. The solution is to select a version that supports these algorithms in the Core engine field in the Details → QOS section of the vService. The selected version is seen in the Resources section of the Load Balancer Management screen of the vService.

2. The calculation is reduced to the number of open requests (behavioral similarity).

• If the response times of the servers are close to each other, the criterion of Least Response Time becomes almost only active requests ÷ Weight; this is equivalent to the criterion of Least Connection.
• When traffic is low, the bandwidth of the servers is close to each other and low; no difference remains for Least Bandwidth to distinguish.

In TR7

• Selection: vService → Details → LB Algorithm → Algorithm → Least Response Time or Least Bandwidth; the additional fields open when the algorithm is selected (algorithm-specific additional fields).
• Support note: The docs also state that these algorithms are applied as Least Connection on an unsupported Core engine version (supported features).
• Network vService: These two algorithms do not exist.

Common Misconceptions

• "If the screen says Least Response Time, that is how it works." The algorithm saved in the form is shown; if the Core engine does not support it, distribution is Least Connection. The message in the vService status is checked.
• "Least Response Time ignores Weight." The criterion is divided by Weight.
• "Least Bandwidth balances the number of requests." It balances the amount of bytes carried; a small number of large downloads can make a server appear full.
• "It is the same as Fastest." Fastest selects the best server in the metric selected in the Fastest Opt-1 field and does not use Weight.

How it is done in the documentation

• HTTP (L7) vService · Algorithms
• HTTP (L7) vService · Supported Features
• HTTP (L7) vService · Core Engine
• Load Balancer Management · Resources

Related questions

• When is Least Connection better than Round Robin?
• Why is traffic not distributed evenly across the servers?
• Which algorithm should I choose; is there a decision guide?