压测模式
场景列表确定压测的对象，本页确定压测的强度、时长与判定标准， 这一整套配置称为一种压测模式。术语定义见基本概念。
同一组业务链路施加不同强度，回答的是不同问题。共七种模式，按客户诉求选取。
工具的配置目录为 profiles/，单个文件即一种压测模式。
本章正文统一用「压测模式」，涉及文件路径时保留原名。
一、七种模式速查
| 模式 | 回答的问题 | 默认强度 | 用于验收 |
|---|---|---|---|
smoke | 脚本、认证与测试数据是否正确 | 1 VU 执行 5 次 | 否，前置检查 |
baseline | 低竞争条件下的固有性能 | 5 VU 持续 5 分钟 | 否，作为对比基准 |
load | 预期业务量下的响应能力 | 递增至 50 VU，稳态 15 分钟 | 是，验收主场景 |
throughput | 能否支撑目标吞吐量 | 按固定到达率加压 | 是，吞吐口径验收 |
stress | 容量拐点位置与降载后的恢复能力 | 50 → 100 → 150 阶梯递增 | 否，容量规划 |
spike | 突发流量下的抗冲击与自愈能力 | 20 VU 瞬时增至 300 后撤回 | 否，风险评估 |
soak | 长时间运行是否持续劣化 | 20 VU 持续 2 小时 | 否，上线前验证 |
推荐执行顺序：smoke → baseline → load（验收），
按需补充 soak / stress / spike。
多数交付场景只需前三种。后四种针对特定风险，客户未提出对应诉求时不必执行—— 每一轮均占用时间与环境资源。
二、逐个说明
smoke — 验证脚本可用性
不测性能。每次修改配置、更换环境或账号后的第一步。
- 验证内容：认证是否通过、请求路径是否正确、测试数据是否存在。
- 使用方式：通过后方可继续加压；失败应先修正脚本配置。
1 个 VU 执行 5 次迭代的耗时不足以支撑分位数统计，用于判定 SLA 会产生误报。 因此 smoke 模式下产品红线自动降级为「仅观察」。
baseline — 测定性能基线
5 个 VU 恒定运行 5 分钟，几乎无并发竞争，测得的是接口本身 的处理能力。
- 执行时机：smoke 通过后、正式加压前；版本升级后的回归对比。
- 使用方式：归档为性能基线。后续
load出现慢请求时回溯比对—— 基线即慢说明接口自身效率低；基线正常而加压后劣化则为并发问题 （排队、锁竞争或资源不足）。
该步骤常被省略，导致 load 出现问题时无法判断成因。建议不要省略。
load — 验证预期业务量下的响应能力
验收主场景。 分五段：2 分钟递增至 10 VU → 3 分钟至 30 → 5 分钟至 50 → 稳态 15 分钟 → 3 分钟降至 0。
- 判定：这是预期应通过的测试。未通过即表示无法支撑预期业务量，需优化或扩容。
- 必须调整：将目标并发替换为客户实际的峰值在线用户数，默认值 50 仅为模板值。
读取报告时以稳态 15 分钟的分阶段数据为准，不要只看整轮聚合值。
throughput — 验证目标吞吐量
客户验收指标为吞吐量（如「支撑 200 TPS」）而非在线人数时使用本模型。
与 load 的区别：
| 模型 | 控制量 | 系统响应变慢时 |
|---|---|---|
load | 并发用户数 | 发起速率随之下降，压力自动回落，测不出真实上限 |
throughput | 每秒发起次数 | 速率保持不变，处理不及时则累计 dropped_iterations |
因此本模型增加一条硬判据：dropped_iterations == 0。
出现迭代丢弃即表示无法支撑目标吞吐量。
到达率模型下需要足够的 VU 才能按时发出请求。VU 不足时工具会丢弃迭代，
而 dropped_iterations == 0 正是核心判据——配置过低即判失败，
表面看是系统无法支撑目标吞吐量，实际是压测端资源不足。
标定方法见并发公式。
stress — 测定容量拐点与恢复能力
非验收测试。 阶梯加压 50 → 100 → 150 → …，每级稳压 5 分钟， 最后降回起始强度，观察能否自行恢复。
- 测定内容：① 拐点所在的并发数（响应时间陡增、错误率上升的位置）； ② 降载后能否自行恢复，还是需要重启。
- 判定方式：本模型预期会压垮系统，因此阈值放宽、产品红线降级为仅观察。 关注点不是是否通过，而是在第几级出现拐点以及拐点后能否恢复。
各阶梯被平均后拐点被抹平，须查看分阶段统计中每一级的独立数据。
spike — 测定抗冲击与自愈能力
常态 20 并发运行 5 分钟 → 10 秒内递增至 300（15 倍） → 维持 2 分钟 → 10 秒撤回至 20 → 恢复观察 6 分钟。
- 执行时机：存在明确的突发场景时，如早高峰集中登录、批量导入、 活动推送、定时任务 集中触发。
- 测定内容：
- 冲击期间系统的表现：拒绝服务、超时雪崩，还是正常承载；
- 更为关键：流量回落后系统能否自行恢复到冲击前水平。 若必须重启才能恢复，则属严重问题——每次突发都需人工介入。
冲击期出现错误与超时属预期内，因此阈值放宽、产品红线降级为仅观察。判读要点：
- 冲击期：错误类型为何。限流拒绝可接受，超时或 5xx 则需关注。
- 恢复期：分阶段对比中，恢复窗口的 p95 是否回到冲击前水平。
同时检查服务端是否残留副作用：连接未释放、队列未消化、线程池未回落。
soak — 检测随时间累积的劣化
20 VU 中等负载持续 2 小时，用于暴露只有长时间运行才会显现的问题： 内存泄漏、连接池或文件句柄耗尽、缓存无限增长、临时表或日志占满磁盘、 会话堆积、GC 频率上升。
这类问题在 10 分钟的 load 中不会显现任何征兆，通常在上线数日后暴露。
- 并发标定：按该客户
load场景的持续业务量标定，使单位时间的业务活动量 接近真实生产，不应直接沿用默认值 20。 - 时长标定：按预期的泄漏速度与资源耗尽时间标定。 正式验收建议 4~8 小时或整夜运行。
不应只看聚合的 p95 / p99——缓慢劣化会被平均掉。应查看自动生成的首尾窗口对比：
| 现象 | 常见成因 |
|---|---|
| 响应时间逐步抬升 | 内存、缓存或连接泄漏 |
| 错误率随时间上升 | 资源耗尽 |
| 吞吐量逐渐下降 | 系统持续退化 |
首尾窗口持平方可判定通过。同时需观察服务端：内存曲线是否只增不减、 连接数是否持续增长——这些压测端无法采集，须配合服务端监控。
三、模式的选取优先级
同名 模式存在多份时，实际生效的只有一份：
customers/<客户>/profiles/<模式>.yaml—— 存在时优先使用profiles/<模式>.yaml—— 客户目录中不存在时回退至此
由工具创建的客户目录自带全部七种模式，因此对该客户而言全局模板不会被使用。
在全局模板中修改并发数后重跑无变化——实际生效的是客户目录下的同名文件。 修改前须先确认目标文件。
确认方式：执行时终端会输出 负载模型：<完整路径>；
报告目录的 environment.txt 记录同一路径；
报告目录中的 profile.yaml 即本轮实际使用配置的副本。
四、单客户的多套流量画像
同一客户常需多套压测对象配置：既执行混合流量（load），
也执行单接口吞吐验收（如「某接口 TPS 大于 500」）。
画像定义 在客户配置中，压测模式仅引用其名称：
# 客户 config.yaml —— 定义画像
workflowSets:
tps-list:
only: [project-onesql-plain-1000] # 只启用这些，其余全关
tps-create:
only: [project-issue-create-and-query]
overrides:
project-issue-create-and-query: { weight: 100 }
# 客户 profiles/throughput-tps-list.yaml —— 只是引用
workflowSet: tps-list
如此拆分的原因：config 描述压测对象（流量画像、环境地址、采集清单），
profile 描述压测强度与判定标准。「启用哪些链路」属于前者。
定义集中在一处后，查阅单个文件即可获知该客户的全部画像，无需逐个翻阅压测模式文件。
省略 workflowSet 即使用默认画像。