基准测试

一个你无法信任的基准，比没有基准更糟。本节讲 如何诚实地度量 Aeron、那些会产出 “好看但虚假” 数字的陷阱，以及用于校准的公开结果。

协调遗漏会骗你

最常见的压测错误：只度量系统 允许 你发出的那些请求。负载之下，卡住的系统发得更少， 于是慢请求根本没被计入 —— 你的 p99 看起来很美。请使用 恒定速率 压力生成器， 按 预期 发送时刻（而非实际时刻）记录延迟。

本节内容

• 诚实解读 Aeron® 基准测试 — Aeron cluster/MDC 基准到底测的是什么、burst 旋钮为何能造出漂亮的头条数字、贴近生产的基准长什么样、如何把结果转成 EC2 选型决策，以及如何对产品团队设定诚实的性能预期。
• 微突发基准测试 — 为什么稳态 TPS 基准测试无法反映真实延迟尖峰——以及如何设计以「每毫秒峰值消息数」为核心指标的微突发基准。
• 配置丢包注入 — 通过 JVM 系统属性进行静态丢包配置：四个丢包旋钮、RandomLossGenerator 的 rate 模型、确定性 seed，以及注入的丢包如何影响 p50/p99/吞吐。

一个最小的诚实基准

1. 预热 JVM，让 JIT 稳定。
2. 以远低于饱和的 固定消息速率 施压；逐条记录延迟。
3. 写入 HdrHistogram；报告 p50 / p99 / p99.9 / max —— 绝不只报平均值。
4. 多轮重复；报告方差，而非一次走运的结果。

提示

始终分别对 C Media Driver 与 Java Media Driver 做基准 —— 它们的尾延迟行为差异显著。