JMeter 压测：线程组、定时器与聚合报告入门
更新时间：2026-09-19。JMeter 适合需要多接口编排、参数化、断言、图形化报表的复杂场景；单接口快速压测用 ab/wrk 更轻，gRPC 用 ghz。
一、核心概念：线程组
bash
Test Plan
└─ Thread Group（线程组）
├─ Number of Threads：并发用户数（每个线程一个虚拟用户）
├─ Ramp-Up Period(秒)：在多少秒内把所有线程启动完
├─ Loop Count：每个线程执行多少次（Forever 配合 Duration）
└─ Scheduler/Duration：持续压测时长Number=200, Ramp-Up=20：20 秒内均匀启动 200 个线程（每秒 +10），避免瞬间冲垮。- JMeter 是线程阻塞模型，高并发时压测机本身吃 CPU/内存，单机几千线程就要考虑分布式压测（Distributed Testing），别把客户端瓶颈当服务端。
二、一个最小压测计划
- 线程组下加 HTTP Request（HTTP Sampler）：填协议、IP、端口、路径、方法。
- 加 HTTP Header Manager：
Content-Type: application/json、鉴权头。 - 加 HTTP Request Defaults：统一设置 host/port，各请求只写路径。
- POST body 直接写在请求 Body Data。
- 加 View Results Tree（调试用，正式压测关掉/只收错误）和 Aggregate Report。
三、定时器：为什么不能无脑狂打
真实用户操作之间有停顿。Constant Timer / Uniform Random Timer 在请求间加等待（思考时间）。不加定时器时每个线程以最大速度狂打，测的是「极限吞吐」而非「真实用户负载」。两种模型要分清：容量测试可以少等待，用户体验模拟必须加思考时间。
bash
Uniform Random Timer：随机延迟 = 固定基准 + 随机量，更接近真实
同步定时器 Synchronizing Blocks：模拟「同时 N 个请求」的并发集合点（抢购场景）四、参数化与断言
- CSV Data Set Config：从 CSV 读用户名/token/商品 ID，避免所有请求打同一条数据（命中缓存导致虚高、或唯一约束报错）。
- Response Assertion / JSON Assertion：校验返回码和关键字段，把「HTTP 200 但 body 是错误页」也算失败。
- 用
${__time()}、${__Random()}、${__counter()}函数生成动态值。
五、聚合报告怎么读
| 列 | 含义 |
|---|---|
| Samples | 总请求数 |
| Average / Median | 平均/中位延迟(ms) |
| 90% / 95% / 99% Line | 分位延迟（尾延迟，见 P99） |
| Throughput | 吞吐（请求/秒，≈QPS） |
| Error % | 错误率，非 0 必须查 |
| Received/Sent KB/sec | 带宽 |
重点看 90/99% Line 和 Error%：平均低但 99% 很高说明长尾严重。逐步提高线程数，找吞吐见顶而 P99 开始陡增的拐点。
六、正式压测用非 GUI
GUI 只用于编排和调试（本身开销大），真正压测用命令行：
bash
jmeter -n -t plan.jmx -l result.jtl -e -o report/
# -n 非GUI -t 测试计划 -l 结果文件 -e 测试结束生成报告 -o 报告目录再结合服务端资源（CPU、Full GC、连接池）一起判断瓶颈。
坑
- GUI 模式跑大并发，压测机卡顿结果失真；正式务必非 GUI。
- 没有断言，把错误响应当成功，吞吐虚高。
- 所有线程打同一个 URL/参数，命中缓存导致结果不可信；用 CSV 参数化。
- 线程数盲目拉满，压测机自身成为瓶颈。
- 忽略 Ramp-Up 瞬间打满，测的是冷启动冲击而非稳态容量。
总结
JMeter 以线程组的线程数、Ramp-Up 启动时间和循环/持续时间定义负载，用 HTTP 取样器加 Header/默认值构造请求、用定时器模拟用户思考时间、用 CSV 做参数化和断言剔除假成功，最终通过聚合报告的吞吐、90/99 分位延迟与错误率找容量拐点；正式压测必须用 -n 非 GUI 模式并结合分布式压测避免客户端成为瓶颈，单接口快速验证则用 ab/wrk 更高效。