Cache hit vs forward_fast
How much does a warm lookup cache change throughput versus forward_fast under
sync?
Numbers are same-host comparisons on a single reference host and are not service-level objectives. See the performance hub disclaimer.
When this matters
Cache-hit traffic is a different performance regime
than forwarding. Use this pair to bound expectations when the
lookup cache is effective, not
as a claim that production traffic is mostly hits. Configure instances under
caches: and wire them through
lookup profiles.
What we varied
- Varied: load shape
(
forward_fastvs warmedcache_hit) - Held constant:
syncruntime, ingress workers, observability off
Evidence
Achieved QPS — sync cache_hit vs forward_fast
| Load shape | Runtime | Achieved QPS | Avg latency (ms) | Sent | Completed | Lost | Workers |
|---|---|---|---|---|---|---|---|
| forward_fast | sync | 76269.9 | 26.1 | 765379 | 765379 | 0 | ingress=2 |
| cache_hit | sync | 329202.8 | 6.1 | 3294253 | 3294253 | 0 | ingress=2 |
At a glance
- sync cache_hit vs forward_fast:
cache_hitis about 4.3×forward_fast(~329k vs ~76k).
Takeaway
A warm cache is much faster than forwarding on this lab. Under
cache_hit, sync reaches about
4.3× the QPS of forward_fast
(~329k vs ~76k) with lower latency.
Treat that multiplier as an upper bound for “almost everything hits,” not as a capacity target or a claim about your hit rate.