Benchmarks¶

Numbers, glorious numbers. This page documents benchmark results for Traffik across a wide range of scenarios — HTTP dependencies, middleware, WebSocket, and the overhead of specific features like response headers and throttle rules.

The headline: Traffik wins on throughput in most scenarios — faster across the majority of backends and integration patterns, with both libraries achieving correct throttling when state is properly managed.

Test Environment¶

Benchmarks were run on:

• Machine: 8-core CPU (WSL2), 16 GB RAM
• Python: 3.9.22
• Backend versions: Redis v6.2, aiomcache v0.8.2
• Comparison: SlowAPI — a popular FastAPI rate limiter
• Test client: httpx.AsyncClient with ASGITransport (in-process, no real network)
• Iterations: 5 per scenario (results averaged)
• Concurrency: batches of 50 concurrent requests unless noted otherwise

HTTP Dependency Mode¶

Throttle applied via Depends(throttle) on individual endpoints — the most common integration pattern.

Throughput (req/s) — Higher is better¶

InMemory Backend¶

Traffik wins decisively on scenarios that involve throttling (high load, burst). The sustained load gap is an artefact of the benchmark, not a real-world concern: all 50 concurrent requests share the same identifier key, so they all queue on the same InMemory shard lock. In production, different users produce different keys that distribute across separate shards with no contention. This effect is specific to the InMemory backend — notice that Redis and Memcached (below) show no such gap under sustained load.

Redis Backend¶

Memcached Backend¶

Traffik and SlowAPI show competitive performance on Memcached, with each winning 2 out of 4 scenarios. Traffik maintains an edge on sustained load and burst scenarios, while SlowAPI performs slightly better on low and high load tests.

Latency Percentiles — Lower is better¶

InMemory — High Load (200 req, 50% throttled)¶

Redis — High Load (200 req, 50% throttled)¶

Memcached — High Load (200 req, 50% throttled)¶

Traffik's tail latency (P95, P99) is mostly lower. Under load, Traffik's operations reduce variance because there's no retry-on-conflict — the lock serialises, computes, and returns.

Middleware Mode¶

Throttle applied via ThrottleMiddleware with MiddlewareThrottle entries — the pattern used when you want to rate-limit without modifying route handlers.

Throughput (req/s)¶

Traffik wins 4 out of 5 middleware scenarios. The sustained load gap follows the same pattern as dependency mode — all benchmark requests share one identifier key, causing single-shard lock contention on the InMemory backend. In production with diverse user keys, this contention does not occur.

Selective throttling¶

One benefit of middleware: you can exempt entire paths from throttle evaluation at zero cost. In the selective throttling benchmark, requests to unthrottled paths (/health) pass through with no throttle overhead, while throttled paths are correctly enforced:

Correctness Under Concurrency¶

A rate limiter that over-throttles or under-throttles isn't doing its job. Both libraries are tested with a clean backend state before each iteration to ensure fair comparison.

Each test sends 150 fully concurrent requests (across 5 iterations = 750 total) against a limit of 100. The expected outcome per iteration: exactly 100 allowed, 50 blocked.

Race condition test (Redis)¶

Both libraries achieve perfect correctness when backend state is flushed between iterations.

Distributed correctness (Redis)¶

10 concurrent clients, each sending 120 requests (limit of 100 per client). Expected: ~5,000 total allowed, ~1,000 throttled.

Success rate across scenarios (Redis)¶

Both libraries achieve correct throttling on Redis when each iteration starts from a clean state. The benchmark suite flushes backend storage between iterations to ensure neither library is penalised by stale counters from previous runs.

WebSocket Benchmarks¶

WebSocket rate limiting has a different performance profile. Connections are long-lived; messages arrive in bursts. Traffik's per-message throttle check is extremely lightweight.

Sustained message throughput¶

WebSocket throttle checks are sub-millisecond at P50 and under 2ms at P99 even with 10 concurrent connections. The default throttled handler (which sends a JSON rate_limit message back to the client and keeps the connection alive) is faster than raising an exception, because exception propagation carries Python interpreter overhead. See Custom Throttled Handlers for the send-message pattern.

Strategy Comparison¶

Different strategies have different CPU and memory profiles. All figures are InMemory backend, FixedWindow strategy baseline, 200 requests (100 allowed, 100 throttled).

%%{init: {"theme": "base", "themeVariables": {"xyChart": {"plotColorPalette": "gray"}}}}%%
xychart-beta
    title "Strategy Throughput (InMemory, High Load, req/s)"
    x-axis ["FixedWindow", "SlidingCounter", "SlidingLog", "TokenBucket", "TokenBucketDebt", "LeakyBucket", "GCRA"]
    y-axis "req/s" 0 --> 2000
    bar [1828, 1834, 1025, 1686, 1718, 1719, 1750]

SlidingWindowLog is the most accurate (100% — it stores every request timestamp), but it's also the most memory-hungry and the slowest due to the log scan. SlidingWindowCounter hits 100% correctness in practice with much lower overhead by using a weighted counter approximation instead of a full log.

Feature Overhead Benchmarks¶

These benchmarks isolate the cost of specific Traffik features on top of a baseline (no-headers, no-rules, InMemory, FixedWindow, 500 requests with 50 concurrent clients).

Response headers overhead¶

Adding response headers has negligible cost. The overhead is within noise margin across all configurations.

Takeaway: Headers add effectively zero overhead — the differences are within measurement noise. Even 8 headers with 4 dynamic resolvers don't produce a measurable performance impact.

Run it yourself:

python benchmarks/headers.py --scenarios no-headers,default-always,many-headers

ThrottleRule registry overhead¶

Registry evaluation runs on every request when rules are configured. The overhead is negligible regardless of rule count or pattern complexity.

Takeaway: Even a registry of 10 mixed rules does not add overhead due to early short-circuiting. Rules are evaluated with short-circuit logic — BypassThrottleRule entries are checked first, so frequently-hit exempted paths (like /health) are fast-pathed out before any ThrottleRule patterns are evaluated.

Run it yourself:

python benchmarks/rules.py --scenarios no-rules,single-rule,many-rules,bypass-rule

Running All Benchmarks¶

Install benchmark dependencies first:

pip install "traffik[dev]"
# or
uv sync

Then run any combination:

# HTTP dependency mode (InMemory backend, no external services needed)
python benchmarks/https.py

# HTTP dependency mode vs SlowAPI with Redis
python benchmarks/https.py \
  --traffik-backend redis --traffik-redis-url redis://localhost:6379/0 \
  --slowapi-backend redis --slowapi-redis-url redis://localhost:6379/0

# Middleware mode
python benchmarks/middleware.py

# WebSocket benchmarks
python benchmarks/websockets.py --scenarios low,high,sustained,burst,concurrent

# Response headers overhead
python benchmarks/headers.py

# ThrottleRule registry overhead
python benchmarks/rules.py

# Strategy comparison (Traffik only, single strategy)
python benchmarks/https.py --libraries traffik --traffik-strategy sliding-window-counter
python benchmarks/https.py --libraries traffik --traffik-strategy token-bucket
python benchmarks/https.py --libraries traffik --traffik-strategy gcra

All scripts accept --help for full option reference.