预热与冷启动偏差
压测数字受预热影响很大：内存分配器要跑过几轮才进入稳定态，客户端库的即时编译与连接池要完成建连，操作系统的页缓存需要被填充，服务端自身的键空间布局与淘汰逻辑也有初态。这些因素叠加会让首轮结果系统性偏离稳定值。可行做法是固定数据集先跑一轮预热，丢掉预热轮数据，只取稳定阶段的读数并写明丢弃了多少。
基本信息
| 偏差来源 | 分配器初态、客户端编译、页缓存、建连与淘汰逻辑 |
|---|---|
| 推荐流程 | 预热轮 + 测量轮，数据集与并发保持一致 |
| 读数口径 | 只取稳定窗口数据，报告标明丢弃的轮次 |
| 常用工具 | redis-benchmark、memtier_benchmark |
| 针对侧 | 目标实例与压测机两侧都要预热 |
典型使用场景
- 容量评估：先预热再测，避免把冷启动损耗算进容量结论
- 版本对比：升级前后使用同一套预热与测量流程，数字才有可比性
- 参数调优：改完配置重新预热，排除初态差异带来的干扰
- 回归测试：把预热步骤写进压测脚本，避免不同人操作不一致
- 机型选型：对比硬件时统一切分方式与预热过程，压低噪声
两轮压测写法
两轮压测写法
redis-benchmark -t set,get -n 50000 -c 50 -q # 预热轮：结果丢弃，只求进入稳定态
redis-benchmark -t set,get -n 200000 -c 50 -q # 测量轮：只取这一轮数据做结论
redis-benchmark -t get -n 200000 -c 50 -q -r 100000 # 限定键范围，分布可控
redis-benchmark -t get -n 200000 -c 50 -q # 复测一次，确认波动幅度
redis-cli INFO stats | grep total_commands_processed # 核对两轮负载量读数怎么取
| 阶段 | 数据形态 | 处理方式 |
|---|---|---|
| 预热轮 | 首轮延迟与吞吐 | 丢弃，仅用于把系统带进稳定态 |
| 测量轮前段 | 数字仍在爬升 | 继续观察，仍在变化就再等 |
| 稳定窗口 | 波动收窄的一段区间 | 只引用这一段写入报告 |
| 收尾尖峰 | 突然抬高的延迟 | 核对是否有外部干扰，必要时整轮重做 |
压测机自己也会冷启动：工具首次运行、网卡中断分布、CPU 调频策略都会影响首轮。目标实例和压测机两侧都留一段预热时间，数字才稳定。
把预热轮和测量轮混在一起做平均，方差会掩盖趋势，同一配置两次压测可能得出相反结论；两段数据必须分开处理与归档。