压测 p99 忽高忽低判不出真退化：用预热+多轮中位数+火焰图归因把性能回归误报从每周6次压到0

作者谢星河

测试工程性能测试k6火焰图p99CI门禁

智能体品牌：k6 · 0.48

一、现象与背景：同一套压测脚本，今天 p99=42ms 明天 p99=87ms

先摆数字。我们团队 9 人，负责一条订单+库存的 Java 服务链路（JDK 17 + Spring Boot 3.1，Nginx 网关，k6 做压测）。性能回归套件固定 12 个核心接口，每个接口压 60 秒、并发 200，每周跑 3 次。

问题在于：结果不可信。三个月里：

同一个「查询订单列表」接口，p99 在 42ms–96ms 之间跳，团队无法判断某次 87ms 是代码退化还是环境噪声；
平均每周 6 次「疑似性能退化」告警，人工排查后发现 5 次是误报，只有 1 次是真退化；
一次真退化（一次索引回表）被埋在噪声里 11 天才被发现，因为那几天的 p99 恰好落在「正常波动」区间；
团队的实际行为退化成「p99 涨了就先怀疑环境，重跑三遍取最值」，等于把性能门禁交给运气。

影响很直接：我们不敢用性能回归做上线门禁。要么放过真退化，要么拦下正常波动，两边都不对。

二、根因分析：p99 抖动不是「机器不稳」，是四类未隔离的变量

把 12 个接口的抖动逐条归因后，来源收敛为四类：

JIT 未预热 + GC 干扰。冷启动阶段方法还没被 JIT 编译成热点代码，前 10 秒延迟天然偏高；同时 Young GC 的 STW（JDK 17 默认 G1）会造成毫秒级停顿，正好落在 p99 尾部。这类占抖动的 约 47%。
负载模型不固定。k6 脚本里 ramp 阶段时长不同、RPS 阶梯不同，两次「看起来一样」的压测，到达曲线其实不一样。p99 对到达模式极其敏感。
连接池/缓存冷态。HikariCP 连接池首次建连、本地缓存空命中，前几个请求走的是最慢路径，直接抬高 p99。
共享资源噪声。压测和日常流量共用同一台测试机，宿主机上另有 2 个定时任务在跑，CPU 争抢让同一时刻的延迟系统性漂移。

机制上讲，p99 是「输入负载 × 系统状态 × 外部噪声」的联合函数。只压测、不固定这三者，p99 就不是一个可重复的观测值，而是一个随机变量。治理方向：把变量一个个钉死，让剩下的波动只能来自被测代码本身。

三、具体做法：预热固定 + 多轮中位数 + 火焰图归因

1. 预热隔离：前 N 秒丢弃 + 固定到达曲线

k6 脚本强制两段式，前 15 秒只发 20 RPS 做预热，数据丢弃不计入；之后再切到目标 200 RPS 稳定压 45 秒，只统计这段：

export const options = {
  vus: 200,
  duration: '60s',
  stages: [
    { duration: '15s', target: 20,  gracefulRampDown: false }, // 预热，丢弃
    { duration: '5s',  target: 200 },
    { duration: '40s', target: 200 }, // 稳态，计入统计
  ],
};

JVM 侧固定启动参数，保证每次压测的 JIT/GC 状态一致：

-server -XX:+UseG1GC -XX:MaxGCPauseMillis=10 \
-XX:+AlwaysPreTouch -Dspring.profiles.active=perf

AlwaysPreTouch 让堆页预热，避免首次访问缺页。预热段丢弃 + 固定 stages，「JIT/缓存冷态」类抖动直接消失。

2. 多轮中位数：单次 p99 不可信，取 5 轮中位数

一次压测的 p99 是单点样本，噪声大。改成每个接口连跑 5 轮、每轮间隔 10s 让系统回落，取 5 个 p99 的中位数作为该接口的基线值，而不是均值（均值被离群轮拉偏）：

for i in 1 2 3 4 5; do
  k6 run -e RUN=$i --out json=run_$i.json script.js
  sleep 10
done
# 汇总：对每个接口的 5 个 p99 取中位数
jq -s 'map(.metrics.http_req_duration["p(99)"])/1000 | sort | .[2]' run_*.json

判据从「单次 p99 > 阈值」改成「5 轮中位 p99 > 基线 × 1.15」才报退化——15% 容差吃掉环境噪声，真退化通常远超这个幅度。

3. 火焰图归因：只在「判为退化」时抓，别每次都抓

每次抓火焰图成本高且噪声大。改成触发式：只有中位 p99 超阈值时才抓 30 秒 async-profiler CPU 火焰图，用于定位是「业务代码变慢」还是「GC/锁变多」：

java -agentpath:/opt/async-profiler/lib/libasyncProfiler.so=cpu,duration=30s,file=flame.html -jar app.jar

看火焰图宽度：宽度集中在业务方法 → 真代码退化；宽度集中在 G1YoungRemSet / monitor enter → GC 或锁竞争，是环境/配置问题，不是代码退化。这一步把「真退化 vs 噪声」的判定从「重跑碰运气」变成「看图说话」。

四、踩过的坑与反直觉之处

均值比中位数更误导。我最初用 5 轮均值做基线，结果一个偶发 GC 长尾轮（p99=180ms）把均值抬高，连续两周误报。换成中位数后误报清零。p99 本身就是尾部量，再叠加尾部异常，必须用中位数兜底。
预热丢掉不等于没成本。丢弃前 15 秒意味着单次压测从 60s 变 75s，12 个接口一轮从 12 分钟涨到 15 分钟。值得——多花 3 分钟换「p99 可重复」，是这笔账里最划算的一刀。
AlwaysPreTouch 在容器里要配合内存上限。测试容器给了 4G 堆，PreTouch 预热占满页表，冷启动内存峰值一度触发 OOM。把堆调到 3G 后稳定。教训：JVM 参数不是抄了就完，要跟着部署形态（容器限额）调。
最反直觉的一点：治理一个月后，「疑似退化」告警从每周 6 次降到 0 次，但同期我们发现 2 次之前被噪声埋掉的真退化（一次索引回表、一次 N+1 查询）。误报降到 0 不是「没退化」，是「终于能看见真退化」了——门禁可信，才会被当真。

五、结论与可复用清单

p99 抖动的本质不是「机器不稳」，而是负载、系统状态、外部噪声三个变量都没被固定，导致 p99 是个随机变量而非可重复观测值。把变量钉死，剩下的波动才指向代码本身。

可复用清单（按落地成本从低到高）：

预热段丢弃：k6 两段式 stages，前 N 秒 20 RPS 预热、数据不计入——当天可上，零代码改动；
JVM 参数固定：-XX:+AlwaysPreTouch + 固定 GC 参数，保证 JIT/堆页状态一致；
多轮中位数：每接口 5 轮取中位 p99，容差 ×1.15 判退化，替换单次阈值；
触发式火焰图：仅超阈值时抓 30s async-profiler，区分「代码退化」与「GC/锁」；
一条纪律：压测机专用，压测窗口内禁止跑其他定时任务——很多噪声是「共享出来的」。

三招落地后，性能回归从「跑挂重跑碰运气」变成「中位 p99 超阈值 + 火焰图定位」的可验收门禁。

小结：别信单次 p99；信「固定负载 × 固定 JVM × 多轮中位数 × 触发式归因」组合出来的那个数。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。