Benchmarks
Benchmark Concepts
The shortest path to reading Trypema throughput, latency, and decision counts correctly.
Use this page as the legend for the benchmark tables.
What one operation means
An operation is one limiter call, usually inc(...). It is not the cost of your full request lifecycle.
The three numbers to care about first
ops/s
How many limiter operations completed per second.
Tail latency
Look at p99 and p99.9 to understand the slow end of the distribution, not just the median.
Decision counts
These tell you what path you actually measured:
allowedrejectedsuppressed_allowedsuppressed_deniederrors
For suppressed mode, denials show up in suppressed_denied, not rejected.
The workload knobs that change results the most
| Knob | Why it matters |
|---|---|
provider | changes the storage and I/O model |
strategy | changes decision behavior |
key_dist and key_space | decide whether traffic is hot-key heavy or spread out |
rate_limit_per_s | changes how often the limiter is under pressure |
threads | changes concurrency and contention |
mode | max finds peak throughput, target-qps is better for tail-latency reading |
How to compare rows safely
Only compare rows directly when the workload knobs match. A fast result under uniform keys does not tell you what happens under hot-key contention.
The most important caveat
Benchmark results are directional. They are useful for understanding relative behavior, not for making universal promises across every machine and topology.