压测延迟分布怎么看
redis-benchmark 的输出包含百分比分布与累计分布两张表：前者适合快速定位某一档位的延迟，后者说明有多大比例的请求落在某段耗时内。判断是否达标要重点看 99% 与 99.9% 档位并对照业务 SLA，只看平均或峰值 QPS 会把尾部风险藏起来。不同并发下的分布表也不能混在一起比较。
基本信息
| 输出内容 | percentile distribution 与 cumulative distribution 两张表 |
|---|---|
| 重点关注 | 99% 与 99.9% 档位 |
| 判断依据 | 与业务 SLA 对照，而不是与别家数字对照 |
| 对比前提 | 并发数、数据集、命令类型与轮次保持一致 |
| 留档要求 | 分布表随压测报告一并归档 |
典型使用场景
- 上线前验收：确认尾部延迟在 SLA 之内，而不只是吞吐达标
- 变更前后对比：同一档位对比，判断改动是否真的有效
- 容量摸底：逐级提高并发，找到尾部开始劣化的拐点
- 硬件选型：不同机型的分布差异比均值差异更有说服力
- 问题定位：尾部分布异常时结合慢日志看具体命令
压测与对照
压测与对照
redis-benchmark -t get -n 200000 -c 50 -q # 快速模式，先看单命令概览
redis-benchmark -t get -n 200000 -c 50 # 完整输出，含两张分布表
redis-benchmark -t get -n 200000 -c 200 # 提高并发，观察尾部是否劣化
redis-cli INFO latencystats # 服务端侧的分位对照
redis-cli SLOWLOG GET 10 # 尾部异常时取命令样本两表怎么读
| 表 | 回答了什么问题 | 用法 |
|---|---|---|
| 百分比分布 | 某一档位请求的延迟是多少 | 定位 99%、99.9% 档是否达标 |
| 累计分布 | 多少比例的请求快于某耗时 | 判断整体是否稳定 |
| 平均值行 | 所有请求的平均耗时 | 仅作参考，不能作为唯一结论 |
| 吞吐数字 | 每秒处理的请求数 | 与延迟一起看，单独看会误判 |
并发数是分布表的隐藏变量：同一实例在 50 并发下可能很漂亮，到 200 并发尾部就塌了，报告必须写明并发与线程配置。
不同并发或不同数据集下的分布表混着对比，结论可能完全反向；对比时固定所有变量，只改要评估的那一项。