Benchmarking

A benchmark you can’t trust is worse than no benchmark. This section covers how to measure Aeron honestly, the traps that produce flattering-but-fake numbers, and the published results to calibrate against.

Coordinated omission will lie to you

The single most common benchmarking mistake: measuring only the requests that the system let you send. Under load, a stalled system sends fewer requests, so the slow ones never get counted — and your p99 looks great. Use a constant-rate load generator and record latency against the intended send time, not the actual one.

In this section

• Reading the Aeron® Benchmark Honestly — What the Aeron cluster/MDC benchmark actually measures, why the burst knob makes the headline numbers, what a production-representative benchmark looks like, how to turn results into an EC2 sizing decision, and how to set honest expectations with your product team.
• Benchmarking Micro-Bursts — Why steady-state TPS benchmarks miss real-world latency spikes — and how to design a micro-burst benchmark where the key metric is peak messages per millisecond.
• Configuring Loss Injection — Static loss configuration via JVM system properties: the four loss knobs, the RandomLossGenerator rate model, deterministic seeds, and how injected loss moves p50/p99/throughput.

A minimal honest benchmark

1. Warm up the JVM and let the JIT settle.
2. Drive a fixed message rate well below saturation; record latency per message.
3. Capture into HdrHistogram; report p50 / p99 / p99.9 / max — never the mean alone.
4. Repeat across runs; report variance, not a single lucky run.

Tip

Always benchmark the C media driver and Java media driver separately — their tail behavior differs significantly.