Comparisons and selection
A Reproducible Traffic Routing Performance Benchmark
This guide provides a method rather than invented results, so teams can measure their own deployment and publish defensible conclusions.
Define what the benchmark must answer
Choose whether the concern is decision latency, full response time, throughput, correctness under load, or recovery after a dependency problem. Mixing these into one score conceals the system component responsible for a change.
Declare the test environment
Record router build, configuration shape, delivery mode, regions, network path, hardware or container limits, data stores, and target response behavior. Fix the request corpus and note whether caches and connections are cold or warm.
Use a repeatable measurement procedure
Warm the system separately, increase concurrency in stated steps, and run enough timed requests for stable percentiles. Include requests that exercise different routing outcomes; a benchmark of one cached redirect does not represent a mixed flow.
Protect correctness while measuring speed
For every load stage, compare observed decisions with the expected fixture labels and count errors, timeouts, and missing events. Discard a run only under a rule written before execution, then preserve the failed run for diagnosis.
Report evidence without overclaiming
Publish sample counts, percentile latency, throughput, error classes, correctness, run order, and raw command or dataset references. Conclusions apply to the declared environment; comparisons require identical conditions and should not imply unmeasured production outcomes.