Why traffic patterns demand different algorithms
Each classical algorithm rests on an assumption about the vService it serves. Round-robin assumes backends are interchangeable. Least-connections assumes session count correlates with backend load. Source-IP assumes user-to-backend stickiness without explicit persistence. Cache-affinity hashes assume the request key — URL, header, or session — is stable. When the assumption holds, the algorithm is the right answer.
The harder cases are when those assumptions stop holding: backends drift in performance during the workday, hardware generations mix during a rolling upgrade, regional latency varies request-to-request, or the workload itself has bursty heavy queries that don't match raw request count. In those scenarios, picking the actually-fastest backend per request — or using a hash algorithm built to absorb backend changes without re-sharding everything — is what preserves user-visible latency.
The right answer is to match algorithm to workload — per vService, not globally.
Algorithm choice, per vService
A vService in TR7 wraps the frontend listener, traffic rules, health checks, and backend group into a single configuration object — broader than the classical pool that splits these across separate places. Each vService picks its own algorithm from a dropdown — no rebuild, no restart. Mix and match across one TR7 instance: round-robin on the static-asset vService, Fastest+ on the API vService, Maglev hash on the cache-tier vService. Service-type filtering happens automatically; the UI only shows algorithms valid for the vService's protocol.
Per-vService algorithm
Algorithm choice lives on the vService object, not the global ADC config. Different vServices run different algorithms in the same TR7 instance.
Protocol-aware filtering
The UI surfaces only algorithms that make sense for the vService protocol — HTTP, TCP, or network-layer vServices each get the relevant subset, no operator guesswork.
Composable with session persistence
Algorithm picks the backend for the first request; session persistence then pins subsequent requests for the same user. Both layers configurable independently per vService.
Hot-swap (no restart)
Change the algorithm on a live vService and traffic shifts to the new logic immediately. No service restart, no connection drain required.
14 algorithms shipped with TR7 ADC
Every classical algorithm, two modern consistent-hash variants, one shortest-delay algorithm, plus TR7's proprietary Fastest+ engine. All available per vService — pick from a dropdown, no configuration code required.
Round-robin (weighted + static)
Even distribution across the vService, weighted or unweighted. The standard default for uniform vServices where every backend has identical capacity.
Least-connections (weighted)
Routes to the backend with the fewest currently-open connections. Highly effective for long-lived sessions where session count correlates with backend load. Weighted variant accounts for capacity differences.
Least response time
Routes to the backend answering fastest right now, measured continuously rather than sampled. Suited to pools where capacity is equal but per-node latency drifts — a warming cache, a node under GC pressure, a noisy neighbour.
Least bandwidth
Routes to the backend currently moving the least traffic. The right criterion when responses differ in size rather than in count — media, file downloads, report exports — where connection count says nothing about real load.
First-available
Always routes to the first listed backend with capacity; falls through to the next only when overloaded. Useful for warm-then-cold backend ordering or staged deployments.
Random
Random selection from healthy backends. Stateless, statistically even — useful when the vService is large and uniform. Supports power-of-two random for low-overhead least-loaded selection.
Source-IP hash
Same client IP always routes to the same backend. Useful for stateful flows when the application doesn't manage explicit session persistence.
URL hash (URI / URL-parameter)
Hash on a URL component — the URL length, the URI path, or a specific query parameter (e.g. ?user_id). Routes the same URL or user to the same backend for cache affinity.
Header hash
Hash on a custom HTTP header. Useful for multi-tenant routing (tenant-id header), feature flagging, or A/B testing scenarios.
RDP cookie hash
Read the RDP session cookie for backend selection. Useful for RDP gateways and remote-desktop farms where session affinity is required.
Consistent hash
Modern hash mode that minimises disruption when backends join or leave the vService — only a small fraction of keys re-shard, not the whole vService. Right for cache tiers where backend churn shouldn't invalidate the whole cache.
Maglev hash
Google's consistent-hashing algorithm built for software load balancers at scale. Lower variance than classic consistent hash, deterministic across replicas. Excellent for stateless services that need predictable backend assignment.
SED — Shortest Expected Delay
Routes to the backend with the lowest expected wait time, factoring in active connections and per-backend weight. A latency-aware alternative to least-connections when backend capacities differ significantly.
Fastest
Routes to the backend with the lowest recent response time. A simpler latency-aware option when response time is the only signal that matters.
Fastest+
TR7's proprietary two-stage engine. The operator picks two of eight live service signals — response time, connect time, queue depth, error rates and more; Fastest+ narrows candidates by the primary signal, then breaks the tie by the secondary. See details section below.
Fastest+ — TR7's two-stage, operator-tuned engine
Most adaptive algorithms watch one signal — response time or connection count. Fastest+ lets the operator pick two of eight live service signals: the primary signal narrows the candidates to the best-scoring backends, and the secondary signal breaks the tie among them. In-maintenance and unhealthy backends are filtered out automatically, and a single-signal mode is available when one criterion is enough. These are the eight signals you can choose from:
Response time
Mean response latency from the backend, sampled continuously. The headline signal — a backend taking longer to respond drops in the ranking immediately.
Connect time
How long it takes to establish a TCP/TLS connection. A backend whose connect time grows is approaching saturation, even if its response time still looks fine.
Queue time
Time requests spend queued before reaching the backend. Rising queue time is the earliest warning that a backend can't keep up.
Active sessions
Currently open sessions per backend. Capacity-aware routing without the noise of historical totals.
Active queue depth
Requests currently waiting. A backend with 0 in queue is preferred over an equally-fast one with 50 waiting.
Connection errors
Recent failed connections. A backend that refused 3 of the last 10 attempts drops in the ranking before a health check would catch it.
Server-side aborts
Backend-initiated session aborts in the recent window. Captures the case where a backend is alive but failing partway through.
Used connections
Connection pool utilization — how close to capacity each backend's keep-alive pool is. Detects pool exhaustion before it becomes user-visible.
Fourteen at Layer 7, eleven at packet level
At Layer 7 the decision is made by reading the request — header, path, cookie, live response time. At Layer 4 it is made on the packet, before the traffic ever reaches the application layer, which is where the highest throughput lives. Either way the algorithm is chosen per service and changes while the appliance is running.
Layer 7 — 14 selection criteria
Layer 4 — 11 packet-level schedulers
When each algorithm shines
Uniform vServices
Identical backends, identical capacity — round-robin keeps the math simple and the load symmetric. Add random for stateless large vServices.
Long-lived sessions
WebSockets, streaming services, video calls — sessions stay open for minutes or hours. Least-connections or SED tracks active load far better than request count.
Cache-tier vServices
Backend churn shouldn't invalidate the whole cache. Consistent hash or Maglev re-shards only a small fraction of keys when backends change.
Heterogeneous or shifting load
Mixed hardware, rolling deploys, regional latency variance — Fastest+ scores backends live so the routing picks the actually-fastest, not the theoretically-best.
Common questions
Can I change the algorithm without restarting the service?
How does Fastest+ relate to least-connections?
When should I pick Consistent hash vs Maglev hash?
What does SED do that least-connections doesn't?
Does algorithm choice require external monitoring or APM integration?
What's the default algorithm?
Match algorithm to workload
See how TR7 ADC lets you set the algorithm per vService — and how Fastest+ handles the workloads the others can't.