Safew 性能压测要点是先明确业务场景与SLA，再用分层脚本、参数化与动态关联、数据隔离和逐步并发攀升来模拟真实流量；同步采集时序与资源指标，复现瓶颈并做容量验证与回归。
先弄清楚“我们要测什么”——用费曼法把问题拆开
想把性能问题讲清楚，我会先回答三件事：测哪条业务线、期望什么指标（响应时间、吞吐、错误率、并发量）和用什么定义“通过”。把这三点讲清楚后，剩下的就是把用户行为拆成“可执行的步骤”并用压测脚本把它们重放。
核心概念（用最简单的话解释）
- 事务（Transaction）：一次业务操作，比如“下单”或“搜索”。
- 并发模型：封闭模型（固定并发用户数）和开放模型（到达率/事件速率）两种常见方式，选择取决于系统特性。
- 稳态 vs 爬坡：先慢慢加负载（ramp-up），到达目标后维持（steady），最后降低（ramp-down）。
- 参数化与关联：避免所有虚拟用户使用同一数据/令牌，确保脚本能处理动态返回值（如 session id / csrf token）。
Safew 脚本设计原则（一步一步来）
把脚本当成“人”的简化模型：有登录、等待、操作、登出。让每一步都有输入和输出，并处理动态值。下面是可以直接套用的设计准则。
- 分层脚本结构：公共模块（登录、登出、统一头部）、业务模块（商品浏览、加入购物车、结算）和工具模块（数据读取、结果上报）。
- 参数化数据：用 CSV/DB/内存队列喂入用户数据，数据要做隔离和回滚（测试环境）。
- 动态关联：对所有需关联的字段做正则/JSONPath抓取并替换到后续请求。
- Think Time 与 Pacing 区别：think time 模拟用户思考停顿；pacing 控制每个虚拟用户的事务发起频率，二者配合能控制到达率。
- 错误处理与重试策略：脚本要能捕获 4xx/5xx，记录日志并按策略重试或跳过。
- 环境隔离：测试账号、测试数据与生产隔离，数据库与消息中间件应使用测试实例或沙箱。
并发模拟配置：开放模型 vs 封闭模型如何选
选择方法取决于你关注的指标和系统表现：
- 封闭模型（Concurrent Users）：适用于长连接/会话显著影响资源的场景（Web 会话、Socket 连接）。你控制的是并发用户数，能观察系统在固定并发下的行为。
- 开放模型（Arrival Rate / RPS）：适用于短请求、高到达率的场景，控制的是请求速率，更接近真实互联网流量的到达特性。
一步步实操：从小白到能复现瓶颈
1) 书写最小可运行脚本（smoke test）
先写一个包含登录、一次业务操作、登出的最小脚本并在本地小范围跑通（1-5 并发）。目的是验证流程、关联和参数化是否正确。
2) 数据喂入与隔离
- 用表格或文件列出必要字段（账号、商品ID、地址ID）。
- 准备比并发数量多 2-3 倍的数据量，避免重复冲突。
- 运行前清理或初始化状态（若需要可用初始化脚本）。
3) 设定 ramp 和稳态阶段（示例配置）
| 阶段 | 并发用户 | 目标 RPS（估算） | 持续时间 | 说明 |
| Smoke | 1-5 | 0.5-5 | 5min | 功能校验 |
| Ramp-up | 0 → 500 | 逐步上升 | 10min | 观察响应曲线 |
| Steady | 500 | 目标吞吐 | 30-60min | 采集稳定指标 |
| Ramp-down | 500 → 0 | 下降 | 5-10min | 恢复检查 |
4) 指标采集与监控清单
单靠压测客户端的响应统计是不够的，必须同时采集服务端指标：
- 应用层：P50/P90/P95/P99 响应时间、错误率、吞吐（TPS/RPS）。
- 主机层：CPU、内存、磁盘 IO、网络带宽。
- JVM/语言运行时：GC 时间、线程数、堆使用、连接池使用率。
- 下游依赖：数据库 QPS、慢查询数量、连接池饱和、Redis 命中率、消息积压。
5) 判定“瓶颈”的方法（直观且可复现）
- 如果响应时间随并发线性上升，通常是CPU或同步阻塞问题。
- 若出现高延迟偶发性抖动并伴随 GC 峰值，可能是内存/GC 问题。
- 吞吐率 Plateau（趋近上限）且 CPU 未饱和，检查 DB 连接池或外部接口限流。
- 错误率上升且返回 5xx，首先确认服务端日志和限流/熔断配置。
示例：一个简化的 Safew 场景脚本（伪代码）
下面是伪代码，表达脚本结构与并发策略，供迁移到 Safew 的实际语法时参考：
| 脚本片段 |
|
{ “scenario”:”purchase_flow”, “setup”:[ {“action”:”get”,”url”:”/”}, {“action”:”post”,”url”:”/login”,”body”:”{user,password}”,”save”:”authToken”} ], “steps”:[ {“action”:”get”,”url”:”/catalog”,”think”:2}, {“action”:”get”,”url”:”/item/${itemId}”,”save”:”itemToken”}, {“action”:”post”,”url”:”/cart/add”,”body”:”{itemId,count}”,”think”:1}, {“action”:”post”,”url”:”/checkout”,”body”:”{payment}”,”think”:3} ], “load”:{ “mode”:”ramp”, “startUsers”:0, “targetUsers”:500, “rampMinutes”:10, “steadyMinutes”:30 }, “data”:”csv://users.csv” } |
常见误区（别掉进这些坑）
- 把客户端瓶颈当成系统瓶颈：压测机资源不足会伪造高延迟，务必单独监控压测客户端 CPU/网络。
- 未做缓存预热：缓存命中率在测试中崩盘会导致不真实的错误。
- 重复使用同一测试账号：会引起数据冲突或短时锁。
- 忽略外部依赖：第三方 API 的限流或网络抖动会影响测试结论。
把结果变成可执行的改进计划
压测结束后，按下述步骤整理输出：
- 把所有关键图表（响应分布、吞吐、错误、CPU/GC）放在一页并标注时间轴。
- 标明“通过/未通过”对应 SLA 的具体点（如 p95 < 500ms）。
- 列出复现步骤与可重复的测试脚本、数据集与环境配置。
- 给出逐条优化建议（数据库索引、连接池调优、热点缓存、异步化）。
示例检查清单（提交给开发团队）
| 项 | 是否 | 说明 |
| 脚本可复现 | 是/否 | 脚本路径与参数 |
| 问题时间点 | 时间戳 | 对应监控截图 |
| 初步原因 | 模块 | 例如：DB 连接池耗尽 |
| 建议改进 | 优先级 | 短期/长期方案 |
最后一点——复测与容量验证
改完之后别忘了回归：先做相同负载的回归验证，再做更高一步的容量验证（例如目标并发的 1.5 倍），确认系统有线性增长或可控退化。这样你才真正把“性能问题”从偶发变成可控。
写到这里，我想起有人把压测当成一次性活动，跑完就丢到一边——其实它更像定期体检：场景会变、流量会变，脚本和指标也要跟着演进，带着问题去跑、带着数据去改，最后才能把“稳定”变成日常操作的一部分。