延迟为什么被低估
固定间隔发压的工具在系统变慢时会自动减少实际发出的请求数，测出的延迟低于真实用户感受，这就是协调遗漏。它让压测结果在饱和区系统性偏乐观。对策是改用闭环速率控制，或让工具按目标速率施压并在延迟超标时记录纠偏量。
基本信息
| 现象 | 饱和时延迟被低估 |
|---|---|
| 成因 | 固定间隔发压，慢时自动少发 |
| 对策 | 闭环速率控制或延迟纠偏 |
| 影响范围 | 压测方法论与容量结论 |
典型使用场景
- 压测报告给出的延迟远好于生产实际
- 不同工具给出的压测结论互相矛盾
- 验证工具在饱和区的测量是否可信
- 容量评估：确定系统真实的性能拐点
- 压测方法论评审：报告要写明发压模型
交叉验证做法
交叉验证做法
# 选支持目标速率与延迟纠偏的压测工具，例如 memtier_benchmark
memtier_benchmark --help # 查看速率与延迟相关选项，参数以实际版本为准
memtier_benchmark -s 127.0.0.1 -p 6379 --ratio=1:9 --clients=40 -n 100000
redis-benchmark -n 100000 -c 50 -q # 固定并发模型，吞吐随延迟变化，注意口径
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec' # 服务端侧实际处理速率
redis-cli INFO latencystats | head -20 # 服务端观测到的延迟分布，用于交叉验证发压模型对照
| 发压模型 | 饱和区表现 | 结论可靠性 |
|---|---|---|
| 固定并发数 | 实际发送速率随延迟下降 | 延迟数字偏乐观 |
| 固定间隔发压 | 系统慢时自动少发请求 | 低估延迟，最典型的协调遗漏 |
| 闭环速率控制 | 按目标速率施压并记录纠偏 | 更贴近真实用户感受 |
| 固定总请求数 | 压测时长随延迟被拉长 | 必须报告实际耗时 |
redis-benchmark 以固定并发数施压，属于闭环模型，在饱和区同样会低估延迟。用它估容量时要意识到这一点，并与服务端 latencystats 交叉验证。
拿压测延迟直接对业务 SLA 做承诺风险很高，偏差在饱和区尤为明显。压测报告必须写明工具、发压模型与目标速率。
更稳的做法是同时记录客户端测得的延迟与服务端观测到的延迟，两者差距明显时，先怀疑测量方法而不是服务端。