基准测试不是“运行工具并抄下最大值”，而是一项受控实验。它可以服务于采购、概念验证、回归检查、容量规划和故障排查，但首先要回答：测试负载是否像真实业务、结果受谁限制、错误请求是否被计入、测试环境是否可比，以及数字能否重复出现。

本章给出一条实用主线：先定义要比较的用户结果，再设计负载；测试过程中同时观测系统，最后用物理上限和统计分布审查结论。这样才能避免“本来测了 A，实际限制在 B，却宣称证明了 C”。

1. 基准只证明系统运行该基准有多快。 是否能代表生产，需要用工作负载特征来建立映射。
2. 微基准、模拟和回放各有盲区。 微基准便于定位组件；模拟覆盖系统交互；回放接近历史行为，却可能丢失缓存、反馈和时序变化。
3. 主动基准测试优于只看最终得分。 运行时用 USE、剖析和跟踪确认真正的限制因素，才知道测到了谁。
4. 吞吐量必须和延时、错误率一起报告。 把系统强推到更高请求率而让队列和延时失控，不是有效容量。
5. 结果必须可复现且能通过合理性检查。 多次运行、报告分布，并用带宽、IOPS、CPU 数量等已知极限反算。

三类负载

• 微基准测试：固定一种操作，改变 I/O 大小、顺序/随机、读/写、线程数或工作集。优点是简单、可重复，缺点是与业务距离较远。
• 工作负载模拟：按生产中的操作比例、状态转换和突发模式生成请求。它能覆盖组件交互，但模型会随业务变化而过期。
• 跟踪回放：重放曾经捕获的事件。它保留了历史序列，却不一定保留新系统的反馈；例如在设备层回放会绕过新系统更大的文件缓存。

一条有效的容量曲线

逐步增加并发或请求率，记录“输入负载 → 已完成吞吐量 → 延时分布 → 错误率 → 资源利用率”。正常情况下吞吐先近似线性增长，接近瓶颈后增幅变小；队列开始累积，P95/P99 延时上升。可接受容量应落在延时目标和错误预算之内，而不是只取最高吞吐点。

关键维度包括操作组合、数据大小、工作集、缓存热度、并发、突发性、测试时长和成功率。关键输出包括完成吞吐、延时分布、错误/超时、CPU/磁盘/网络使用率、队列深度，以及多次运行的离散程度。

1. 写清问题和判定标准。 例如“在 P99 小于 20 ms、错误率低于 0.1% 时，哪种实例每元成本完成的请求更多”。
2. 刻画目标工作负载。 从生产统计中取得操作比例、大小分布、工作集、并发与峰谷，不要用一个平均数代替变化。
3. 固定并披露环境。 记录硬件/实例类型、内核、软件版本、文件系统、缓存状态、调优参数、网络拓扑和后台任务。
4. 预热并分阶段加压。 让运行时、缓存和连接进入稳定状态，再以小步长增加负载；每个阶段保持足够时间。
5. 边跑边观测。 先用 USE 检查 CPU、内存、设备和网络，再对热点做 CPU 剖析或事件跟踪。
6. 检查成功与限制。 核实请求确实到达目标、响应内容正确、错误没有被当作成功；指出瓶颈是目标、客户端、网络还是测试工具。
7. 重复和反算。 在不同时间或实例上重复，报告分布；用“次数 × 每次字节数”与链路带宽等上限互相验证。

以下命令用于观测正在运行的基准，默认只读系统状态；请先在测试环境确认权限与版本。perf 会生成本地 perf.data，bpftrace 需要相应特权。

~~~bash

# CPU、运行队列、内存与块设备的短周期观测

vmstat 1

iostat -xz 1

pidstat -dur 1

# 低开销统计硬件/软件事件，持续 10 秒

perf stat -a -- sleep 10

# 以 99 Hz 采样全系统 CPU 栈，持续 30 秒

perf record -F 99 -a -g -- sleep 30

perf report --stdio -n

# 只统计块请求由哪些进程发起；Ctrl+C 结束

bpftrace -e 'tracepoint:block:block_rq_issue { @[comm] = count(); }'

~~~

事件名称和字段会随内核改变，先用 <code>perf list block</code> 或 bpftrace 的列表功能确认。任何会写磁盘的负载生成器都应指向隔离的测试数据，切勿在生产卷上照抄参数。

先看结果是否“真的发生”：目标端是否有对应请求和资源活动，成功数是否与客户端一致。再问“为什么不是两倍”：哪个资源、锁、线程模型或客户端先到顶。若吞吐停止增长而延时快速上升，通常是饱和和排队；若资源未忙却吞吐到顶，要检查限流、单线程客户端、连接池或软件配置。

合理性检查尤其有效。若报告 50 000 次/s、每次 8 KiB，则仅有效载荷已约 400 000 KiB/s；若单向链路明显承受不了，结果可能来自客户端缓存、统计口径错误或压根没有到达目标。不要只报平均值：分位数和时间序列能暴露突发干扰，重复试验的分布则说明结论是否稳定。

• 把文件系统缓存命中称为“磁盘性能”，或把客户端超时当成服务器延时。
• 相信流行工具的标签，却没有验证它实际发出的系统调用和 I/O。
• 一次改变硬件、内核、配置和网络，再把差异全部归因于其中一个因素。
• 只跑几秒、只跑一次，忽略预热、定时任务、云端邻居和频率变化。
• 为追求峰值继续加压，虽然错误和延时已不可接受。
• 只提供一个数字，不记录版本、命令、环境、限制因素和原始分布。

1. 微基准为何容易定位问题，却不一定能代表生产？
2. 工作集远小于内存时，文件读基准主要可能测到哪一层？
3. 吞吐还在小幅增长、P99 却急剧上升时，容量点应取哪里？
4. 为什么回放设备层 I/O 可能低估拥有大缓存的新系统？
5. “请求数 × 单次字节数”这一反算主要检查什么？

检查要点：分别对应“简单但相关性有限”“文件系统/页缓存”“满足延时目标的饱和前区间”“回放绕过缓存反馈”“是否突破带宽或设备上限”。

可信基准的交付物不是一个冠军数字，而是一套可重现证据：明确目标、贴近业务的负载、完整环境、运行时观测、吞吐/延时/错误的联合曲线、限制因素和适用边界。先证明测量对象，再讨论输赢；先满足服务质量，再谈最大吞吐。