两种口径别混用
redis-benchmark 的 -P N 会把 N 条命令打包成一批发送，用减少往返的方式放大吞吐。它衡量的是服务端在理想批量提交下的处理上限，而不是业务的真实 QPS。做容量评估要用贴近真实调用模式的压测：单条往返、真实命令集、真实读写比例与值大小。
基本信息
| 工具 | redis-benchmark，随 Redis 一起安装 |
|---|---|
| 核心参数 | -n 请求数 / -c 并发 / -P 管道深度 / -d 值大小 |
| 输出关注 | 吞吐 QPS 与延迟百分位 |
| 口径区分 | 找上限与估容量是两件事 |
典型使用场景
- 先 -P 1 拿单条往返基线，再开 -P 32 观察批量提交的上限
- 版本升级或配置变更后做回归对比
- 验证连接数、内核参数、管道深度对吞吐的影响
- 容量评估：用真实命令集与读写比例跑，而不是模板 SET/GET
- 压测期间从服务端侧交叉验证 instantaneous_ops_per_sec
基准与上限对比
基准与上限对比
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -P 1 -q # 单条往返基线
redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 50 -P 32 -q # 批量提交，看吞吐上限
redis-benchmark -t set,get -n 100000 -c 50 -r 100000 -q # 指定命令集与随机键空间
redis-benchmark -t set -n 100000 -c 50 -d 1024 -q # 指定值大小，贴近真实负载
redis-benchmark -t get -n 100000 -c 50 --latency -q # 看延迟分布而非均值
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec' # 服务端侧交叉验证参数含义与注意点
| 参数 | 含义 | 注意点 |
|---|---|---|
| -n | 总请求数 | 太少会被启动抖动带偏，结论不稳 |
| -c | 并发连接数 | 要与业务连接模型对齐 |
| -P | 管道深度 | 只影响上限测量，不代表业务容量 |
| -d | 值大小 | 小值压不出真实带宽与内存压力 |
| -r | 随机键空间 | 键空间太小会全部命中同一批数据 |
| --latency | 报告延迟分布 | 比只看均值更能暴露尾延迟 |
压测机本身会先成为瓶颈：单机跑到十几万 QPS 时，先看压测端的 CPU、网卡与连接数是否已经饱和，必要时用多台客户端分布式施压。
redis-benchmark 用的是内置命令模板，不等价于业务命令。涉及多键、事务、Lua、大值的场景要自己写脚本，否则测的是另一个系统。
压测结论必须写清环境与发压模型。脱离了规格、网络和命令集的数字，搬到生产就是误导。