-
Notifications
You must be signed in to change notification settings - Fork 1
Algorithm Visualizations

The examples below show the personality of each routing mode. They are not benchmarks; they are a quick way to see whether an algorithm behaves the way you expect.
Each bar represents the number of players on a server. The goal is to see how evenly (or intentionally unevenly) each algorithm spreads the load.
█ = ~5 players
▌ = ~2-3 players
lobby-1: ██ (2)
lobby-2: ██ (2)
lobby-3: █ (1)
lobby-1: ██ (2)
lobby-2: ██ (2)
lobby-3: █ (1)
lobby-1: ██ (2)
lobby-2: ██ (2)
lobby-3: █ (1)
lobby-1: ███ (3)
lobby-2: █ (1)
lobby-3: █ (1)
- Higher variance at low counts — expected behavior.
lobby-1: ███ (3)
lobby-2: █ (1)
lobby-3: █ (1)
lobby-1: ██ (2)
lobby-2: ██ (2)
lobby-3: █ (1)
lobby-1: ██ (2)
lobby-2: ██ (2)
lobby-3: █ (1)
- Depends on UUID hash; shown here as a typical distribution.
lobby-1: ██████ (6)
lobby-2: ██████ (6)
lobby-3: ██████ (6)
lobby-4: ██████ (6)
lobby-5: ██████ (6)
- Near-perfect even distribution.
lobby-1: ██████ (6)
lobby-2: ██████ (6)
lobby-3: ██████ (6)
lobby-4: ██████ (6)
lobby-5: ██████ (6)
- Very close to
least_players— at this scale, practically identical.
lobby-1: ██████ (6)
lobby-2: ██████ (6)
lobby-3: ██████ (6)
lobby-4: ██████ (6)
lobby-5: ██████ (6)
- Strictly even by design.
lobby-1: ████████ (8)
lobby-2: █████▌ (5)
lobby-3: ██████ (6)
lobby-4: ████▌ (4)
lobby-5: █████▌ (7)
- Some variance — evens out further as the player count grows.
lobby-1: ██████████ (10)
lobby-2: ████████ (8)
lobby-3: ██████ (6)
lobby-4: ████ (4)
lobby-5: ██ (2)
- Proportional to weight.
lobby-1: ██████ (6)
lobby-2: ██████ (6)
lobby-3: ██████ (6)
lobby-4: ██████ (6)
lobby-5: ██████ (6)
- EMA smoothing produces an even distribution under steady load.
lobby-1: ██████ (7)
lobby-2: ██████ (6)
lobby-3: █████ (5)
lobby-4: ██████ (6)
lobby-5: ██████ (6)
- Minor variance from hash ring distribution.
srv-01: ██████████ (10)
srv-02: ██████████ (10)
srv-03: ██████████ (10)
srv-04: ██████████ (10)
srv-05: ██████████ (10)
srv-06: ██████████ (10)
srv-07: ██████████ (10)
srv-08: ██████████ (10)
srv-09: ██████████ (10)
srv-10: ██████████ (10)
srv-01: ██████████ (10)
srv-02: ██████████ (10)
srv-03: █████████▌ (11)
srv-04: █████████ (9)
srv-05: ██████████ (10)
srv-06: ██████████ (10)
srv-07: █████████▌ (11)
srv-08: █████████ (9)
srv-09: ██████████ (10)
srv-10: ██████████ (10)
- ±1 deviation — performs well at scale.
srv-01: ██████████ (10)
srv-02: ██████████ (10)
srv-03: ██████████ (10)
srv-04: ██████████ (10)
srv-05: ██████████ (10)
srv-06: ██████████ (10)
srv-07: ██████████ (10)
srv-08: ██████████ (10)
srv-09: ██████████ (10)
srv-10: ██████████ (10)
srv-01: ███████████ (12)
srv-02: █████████▌ (9)
srv-03: ██████████ (10)
srv-04: ████████▌ (8)
srv-05: ███████████ (11)
srv-06: ██████████ (10)
srv-07: █████████▌ (9)
srv-08: ██████████ (10)
srv-09: ███████████ (11)
srv-10: ████████▌ (10)
- Variance shrinks with scale — law of large numbers.
srv-01: ██████████████████ (19)
srv-02: ██████████████████ (19)
srv-03: ███████████ (11)
srv-04: ███████████ (11)
srv-05: ███████████ (11)
srv-06: ████████ (8)
srv-07: ████████ (8)
srv-08: ████████ (8)
srv-09: ████ (4)
srv-10: ████ (4)
srv-01: ██████████ (10)
srv-02: ██████████ (10)
srv-03: ██████████ (10)
srv-04: ██████████ (10)
srv-05: ██████████ (10)
srv-06: ██████████ (10)
srv-07: ██████████ (10)
srv-08: ██████████ (10)
srv-09: ██████████ (10)
srv-10: ██████████ (10)
srv-01: █████████▌ (11)
srv-02: ██████████ (10)
srv-03: █████████ (9)
srv-04: ██████████ (10)
srv-05: █████████▌ (11)
srv-06: █████████ (9)
srv-07: ██████████ (10)
srv-08: ██████████ (10)
srv-09: █████████▌ (10)
srv-10: █████████ (10)
- Hash ring produces ±1 deviation across 10 servers.
latency does not produce an even distribution chart. It ranks the healthy candidates by the ping measured from the Velocity proxy:
lobby-east: 25 ms ← selected
lobby-west: 70 ms
lobby-eu: 110 ms
Every player routed by that proxy sees the same current ranking. This is useful when backend network delay differs, but it is not player-specific geographic routing. If the 25 ms server becomes full, drained, unhealthy, circuit-open, or lifecycle-disallowed, the next eligible candidate can be selected.
| Scenario | Best Algorithm |
|---|---|
| Want perfect balance, don't care about cost | least_players |
| Want near-perfect balance, low cost | power_of_two |
| Servers have different capacities | weighted_round_robin |
| Need sticky sessions | consistent_hash |
| Bursty traffic patterns | least_connections |
| Prefer the lowest proxy-to-backend ping | latency |
| Just testing / strict fairness | round_robin |
| Very large server pool (50+) | random |
See Routing Algorithms for detailed explanations of each mode.
Home · Quick Start · Configuration · Operations · FAQ
GitHub · Support / Discord · Report a Bug
VelocityNavigator v4.3.0 · by DemonZ Development
![]()
Getting Started
Routing
- Routing Algorithms
- Algorithm Visualizations
- Initial Join Balancing
- Contextual Routing Guide
- Player Affinity
- Health & Circuit Breakers
- Retries & Fallbacks
Player Experience
Configuration
Network & Operations
- Advanced Proxy Systems
- Redis & Multi-Proxy
- Storage & Databases
- Server Management
- Backend Lifecycle States
- HTML Dashboard
- Operations Runbook
- Prometheus & Grafana Setup
- Troubleshooting Guide
- FAQ
VelocityNavigator 4.3.0