What this tool does
Round robin, weighted round robin, least connections, IP hash, and power of two choices all answer the same question — which backend gets the next request — but they produce genuinely different distributions once request cost varies or backends differ in capacity. This tool runs the same simulated sequence of requests (each with a simulated duration and client IP) through all five algorithms side by side, so the difference is a chart instead of a claim.
Why the distributions diverge
Round robin and weighted round robin decide purely from the request's position in the sequence — they never look at how busy a backend currently is. Least connections and power of two choices do look at current load, which is why they stay even even when some requests take far longer than others — a backend stuck on a slow request stops getting new ones until it frees up. IP hash optimizes for something else entirely — not evenness, but stickiness: the same client always lands on the same backend, which is what session affinity depends on.
Reading the results
Each card's bar shows the share of requests each backend received, and the spread figure is the gap between the busiest and quietest backend — 0% means perfectly even. The request-by-request trace underneath shows exactly which backend a given algorithm picked for each simulated request, including its client IP and duration.
FAQ
Why does IP hash have a higher spread than the others?
It's not trying to minimize spread — it's trading evenness for stickiness. With a small client pool, some IPs will hash to the same backend purely by chance, the same way any hash function distributes a small input set unevenly. A larger client pool averages that out.
Why does weighted round robin sometimes look uneven in the trace but even in the chart?
The trace is a sequence of individual decisions; the chart is the aggregate over all of them. Weighted round robin uses a smooth scheduling algorithm (the same one nginx uses) specifically so a weight-2 backend's extra turns are spread throughout the sequence instead of bunched at the start — but the aggregate share still converges exactly to each backend's weight proportion.
Is this simulating real network behavior?
No — it's a simplified, deterministic-per-run model for comparing the algorithms' routing logic, not a network or queueing simulator. Request "duration" is an abstract number of ticks used only to determine which requests overlap, not a real latency measurement.
Is my data uploaded anywhere?
No — everything happens entirely in your browser. Nothing is sent to a server.
Try it yourself
For the full mechanics behind each algorithm — plus Layer 4 vs Layer 7, health checks, and sticky sessions — see Load Balancers Explained. Once requests are spread across backends, Throughput Calculator models how much capacity that pool actually provides.