第 22 章 —— 从微基准到生产容量证据

本章目标： 本章完成后，开发者能够选择一个具体 DSM 热路径，固定 JMH 环境和参数，保存原始 JSON，并只在可比条件下形成容量判断。

学习目标

1. 区分 benchmark harness smoke、微基准结果和生产容量。
2. 为 Register、Lease、CRDT、ChangeStream 与 security 选择对应 fixture。
3. 记录 JDK、CPU、参数、单位和原始结果。
4. 识别吞吐、延迟分布和分布式端到端性能的不同问题。

前置条件

• 已完成第 13 章背压和第 19 章 metrics。
• 能运行 Maven/JMH。
• 接受微基准不包含生产网络、GC 配置、业务载荷和依赖系统。

案例进度

履约团队想知道「DSM 能不能扛住流量」。这个问题太大，无法直接测。团队把它拆成：RecordCodec 编解码延迟、Register get、Lease renew、CRDT apply/merge、ChangeStream overflow、加密 envelope 开销等独立热路径。

容量结论的证据链

仓库中的 benchmark module 包含：

• RecordCodecLatency、ProtobufSerializationLatency
• RegisterGetLatency
• LeaseRenewThroughput
• CrdtApplyThroughput、CrdtMergeThroughput
• ChangeStreamOverflowPolicyThroughput
• SecureEnvelopeEncryptionOverhead
• HLC、striped lock、QoS scheduler 等组件热路径

每个 fixture 只回答它命名的局部问题。

Smoke run 与测量 run

BenchmarkHarnessTest 只验证 request 默认值、参数校验和 JSON 输出结构。一个很短的 JMH run 可以证明 harness 可执行，但 warmup、fork、测量时间不足时，结果波动不能用于容量承诺。

可复制的 smoke 命令：

cd submodule/dsm
mvn -q -pl dsm-benchmark -am test
mvn -q -pl dsm-benchmark -DskipTests exec:exec \
  -Dbenchmark.include=RegisterGetLatency \
  -Dbenchmark.warmupIterations=0 \
  -Dbenchmark.measurementIterations=1 \
  -Dbenchmark.measurementTimeMs=100 \
  -Dbenchmark.forks=0

这条命令是 CI/教学 smoke，不是报告数字的推荐测量配置。

结果卡的必要字段

只抄平均值会丢失单位、误差、分位数和运行条件。

从微基准到容量计划

微基准帮助发现热路径回归。生产容量还要叠加：实体大小与 key 分布、节点数、网络延迟/丢包、repair 流量、GC、线程竞争、安全开销、观察后端以及业务峰谷。最终压力测试需要在接近生产的独立进程环境中运行。

反例与故障注入

• 把 forks=0、100 ms 的 smoke 数字写成 SLA，指出缺失条件。
• 比较不同 JDK/CPU 的两个结果但不记录环境，观察结论不可复核。
• 用 RegisterGetLatency 推断跨节点 repair 吞吐，指出执行面不匹配。
• 只保留 Markdown 数字、删除 JMH JSON，观察原始证据丢失。

实验

运行 harness test 和一个短 smoke；将环境与参数写入 benchmark-run-card.json。书稿不固化短测分数，只校验结果卡字段完整。

实验验收卡

回顾

• 先问具体热路径，再选择 fixture。
• smoke 证明可执行，不证明容量。
• 结果需要绑定环境、参数、单位、原始 JSON 和 revision。
• 生产容量需要独立的端到端负载与故障测试。

下一步

第 23 章进入第六篇：用真实 TCP 端口和 Redis 客户端观察 DSM 的复制、repair 与协议边界，补上 E4 证据。

证据链接

• BenchmarkMain
• BenchmarkHarnessTest
• RegisterGetLatency
• SecureEnvelopeEncryptionOverhead