Benchmarks

Real, sustained, concurrent load through a real wardline serve process – not synthetic numbers. The suite lives at bench/ and reproduces with:

go install github.com/tsenart/vegeta@latest   # HTTP load generator
./bench/run.sh

It drives vegeta and a handful of purpose-built load clients (bench/grpcload, bench/anomalyattack, bench/sessionload, bench/scimload, bench/federationwait, …) against every feature this proxy ships, plus three cross-cutting runs: 3-5 risk-based feature-flag combinations, an HA run (2 replicas sharing one Postgres pool), and a 30-60 minute soak.

Machine and method

Numbers below are from one run on a 10-core Apple M4 laptop, not a production cluster – read them as relative (what costs what, whether a limiter actually holds) and as proof the methodology is real, not as an SLA promise for your hardware. Run ./bench/run.sh on your own target machine for numbers that mean something for your deployment.

Two mock upstreams stand in for a real MCP server so the numbers measure Wardline’s own overhead, not a stand-in’s: bench/httpupstream for HTTP (a concurrent Go server – alone it sustains ~89,000 req/s at ~1.4ms p50, confirmed by benchmarking it directly with nothing in front of it) and bench/grpcload upstream for gRPC.

Finding this machine’s real ceiling: sweeping sustained rate (not raw connection count) against the baseline allow path with a fixed, keep-alive-reusing worker pool, throughput peaks around ~37,000- 38,800 req/s (p50 2-4ms, p99 9-12ms, 100% success, 0 errors) at 100-150 concurrent connections, then degrades past ~300-500 as the load generator and Wardline compete for the same 10 CPU cores on one machine – a same-host testing artifact (both processes fighting for cores), not a Wardline-side defect: success stays 100% the whole way, it’s purely a latency/throughput curve, never an error rate. Past ~500-800 concurrent new connections specifically (not the sustained- rate sweep above), the load generator itself hits macOS’s default listen backlog (kern.ipc.somaxconn=128) and ephemeral port range before Wardline’s own capacity does – a genuine ceiling for same-host loopback testing, not for Wardline running on a real host under real distributed client load with persistent connections.

Results

Two things worth calling out on their own:

• The full feature stack (budget, anomaly detection, credential issuance, audit, all on at once) costs single-digit milliseconds of p99 over the v0.1 baseline — the whole point of the layered architecture (identity → auto-block → policy → budget → audit) is that each stage is a cheap in-memory check, and the numbers bear that out.
• Budget enforcement holds its line exactly, not approximately: a 100-req/second-window limit under 5x sustained overload for 15 seconds admitted precisely 1,500 requests and rejected the other 6,000 with 429, not a fail-open gap under load — see Budget Enforcement.

Reproducing

./bench/run.sh
# or tune the load:
BENCH_RATE=2000 BENCH_DURATION=30s BENCH_MAX_WORKERS=500 ./bench/run.sh

Raw vegeta reports (.bin/.txt) and per-scenario server/audit/anomaly logs land under bench/.out/.

The soak test (30-60 real minutes, watching for memory/goroutine growth) is a separate script, deliberately not part of run.sh’s own fast (~5 minute) suite:

./bench/soak.sh
# or run the full hour:
SOAK_DURATION_SECONDS=3600 ./bench/soak.sh