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.
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.
Algorithm choice lives on the vService object, not the global ADC config. Different vServices run different algorithms in the same TR7 instance.
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.
Algorithm picks the backend for the first request; session persistence then pins subsequent requests for the same user. Both layers configurable independently per vService.
Change the algorithm on a live vService and traffic shifts to the new logic immediately. No service restart, no connection drain required.
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.
Even distribution across the vService, weighted or unweighted. The standard default for uniform vServices where every backend has identical capacity.
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.
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 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.
Same client IP always routes to the same backend. Useful for stateful flows when the application doesn't manage explicit session persistence.
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.
Hash on a custom HTTP header. Useful for multi-tenant routing (tenant-id header), feature flagging, or A/B testing scenarios.
Read the RDP session cookie for backend selection. Useful for RDP gateways and remote-desktop farms where session affinity is required.
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.
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.
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.
Routes to the backend with the lowest recent response time. A simpler latency-aware option when response time is the only signal that matters.
TR7's proprietary 8-signal adaptive engine. Combines response time, connect time, queue depth, active sessions, error rates and more into a per-request fastness score. See details section below.
Most adaptive algorithms watch one signal — response time or connection count. Fastest+ continuously samples 8 independent performance signals per backend and combines them into a single fastness score, freshly computed for each incoming request.
Mean response latency from the backend, sampled continuously. The headline signal — a backend taking longer to respond drops in the ranking immediately.
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.
Time requests spend queued before reaching the backend. Rising queue time is the earliest warning that a backend can't keep up.
Currently open sessions per backend. Capacity-aware routing without the noise of historical totals.
Requests currently waiting. A backend with 0 in queue is preferred over an equally-fast one with 50 waiting.
Recent failed connections. A backend that refused 3 of the last 10 attempts drops in the ranking before a health check would catch it.
Backend-initiated session aborts in the recent window. Captures the case where a backend is alive but failing partway through.
Connection pool utilization — how close to capacity each backend's keep-alive pool is. Detects pool exhaustion before it becomes user-visible.
Identical backends, identical capacity — round-robin keeps the math simple and the load symmetric. Add random for stateless large vServices.
WebSockets, streaming services, video calls — sessions stay open for minutes or hours. Least-connections or SED tracks active load far better than request count.
Backend churn shouldn't invalidate the whole cache. Consistent hash or Maglev re-shards only a small fraction of keys when backends change.
Mixed hardware, rolling deploys, regional latency variance — Fastest+ scores backends live so the routing picks the actually-fastest, not the theoretically-best.
See how TR7 ADC lets you set the algorithm per vService — and how Fastest+ handles the workloads the others can't.