JMeter 在 Linux 环境下进行生产级性能压测的完整实战指南

一、为什么要做性能压测
- [1.1 一次"有价值"的压测，至少要回答哪些问题？](#1.1 一次“有价值”的压测，至少要回答哪些问题？)
- [1.2 核心性能指标](#1.2 核心性能指标)
二、压测方案设计
- [2.1 逐轮压测参数说明](#2.1 逐轮压测参数说明)
- [2.2 为什么参数要这样设计？](#2.2 为什么参数要这样设计？)
- - [✔ 线程数：逐步逼近瓶颈](#✔ 线程数：逐步逼近瓶颈)
  - [✔ Ramp-Up：刻意偏短](#✔ Ramp-Up：刻意偏短)
  - [✔ 持续时间 + 循环次数](#✔ 持续时间 + 循环次数)
  - [✔ 启动延迟](#✔ 启动延迟)
[三、6 轮压测真实结果汇总](#三、6 轮压测真实结果汇总)
四、性能数据逐项拆解
- [4.1 Avg 响应时间：为什么会这样涨？](#4.1 Avg 响应时间：为什么会这样涨？)
- [4.2 P95 / P99：为什么这是最重要的指标？](#4.2 P95 / P99：为什么这是最重要的指标？)
- [4.3 QPS：吞吐为什么不涨反降？](#4.3 QPS：吞吐为什么不涨反降？)
- [4.4 错误率 0%，系统为什么依然"不可用"？](#4.4 错误率 0%，系统为什么依然“不可用”？)
五、最终结论
[六、性能指标的"计算方式 + 解读方式"](#六、性能指标的“计算方式 + 解读方式”)
- [6.1 吞吐量（QPS / TPS）------系统"能吃多少"的能力](#6.1 吞吐量（QPS / TPS）——系统“能吃多少”的能力)
- - [✔ 计算方式](#✔ 计算方式)
  - [✔ 怎么用 QPS 判断瓶颈？](#✔ 怎么用 QPS 判断瓶颈？)
- [6.2 平均响应时间（Avg）------"整体感觉"，但不能单看](#6.2 平均响应时间（Avg）——“整体感觉”，但不能单看)
- - [✔ 计算方式](#✔ 计算方式)
  - [✔ 为什么 Avg 经常"骗人"？](#✔ 为什么 Avg 经常“骗人”？)
- [6.3 P95 / P99 ------真正的"用户体验指标"](#6.3 P95 / P99 ——真正的“用户体验指标”)
- - [✔ 计算逻辑](#✔ 计算逻辑)
  - [✔ 如何用 P95 / P99 判断是否"可用"？](#✔ 如何用 P95 / P99 判断是否“可用”？)
- [6.4 错误率（Error Rate）------最容易被误解的指标](#6.4 错误率（Error Rate）——最容易被误解的指标)
- - [✔ 计算方式](#✔ 计算方式)
  - [✔ 为什么"错误率 = 0%"也可能是灾难？](#✔ 为什么“错误率 = 0%”也可能是灾难？)
- [6.5 并发数 ≠ 系统能力（90% 的人会踩的坑）](#6.5 并发数 ≠ 系统能力（90% 的人会踩的坑）)
- - [✔ 并发到底是什么？](#✔ 并发到底是什么？)
  - [✔ 为什么并发越高，系统越慢？](#✔ 为什么并发越高，系统越慢？)
七、如何一步步判断"系统瓶颈在哪里"？
- [Step 1：先看吞吐（QPS）是否到顶](#Step 1：先看吞吐（QPS）是否到顶)
- [Step 2：再看延迟是否开始失控](#Step 2：再看延迟是否开始失控)
- [Step 3：结合资源指标"对号入座"](#Step 3：结合资源指标“对号入座”)
八、并发压测"终极回答模板"
九、记忆版总结

一、为什么要做性能压测

很多人一提压测，第一反应就是：

"我要起多少线程？"

这是一个典型的新手误区。

真正专业的性能压测，第一步一定是先想清楚一句话：

这次压测，我到底想验证什么？

否则你只会得到一堆"看起来很厉害、但没法用来决策"的数字。

1.1 一次"有价值"的压测，至少要回答哪些问题？

站在系统负责人 / 架构设计 / 面试官的视角，一次合格的压测，需要能回答以下问题：

系统在 高并发场景下的最大处理能力（吞吐上限）是多少？
在接近或超过峰值时，响应时间还能不能接受？
高负载下是否会出现 错误、超时、雪崩或请求堆积？
CPU / 内存 / 线程池 / 数据库连接池 是否出现明显瓶颈？
系统在 长时间运行 情况下，是否存在性能衰退或资源泄漏？

💡 一句话总结 ：

压测不是为了"跑个数据好看"，而是为了给上线、扩容和架构调整提供依据。

1.2 核心性能指标

在团队和面试中，最怕的就是：

你说的 QPS，和我理解的 QPS 不是一回事。

所以，先把口径说清楚。

指标	含义	你该怎么用
Avg Response Time	平均响应时间	看整体性能趋势
Min / Max	最快 / 最慢请求	捕捉极端慢请求
P95 / P99	95% / 99% 请求完成时间	最接近真实用户体验
QPS / TPS	每秒处理请求/事务数	衡量系统吞吐能力
Error Rate	请求失败比例	判断稳定性
系统资源	CPU / 内存 / 线程池 / DB	定位瓶颈来源

⚠️ 核心原则：

任何单一指标都是不可靠的，必须结合：

👉 响应时间 + 吞吐量 + 错误率 + 系统资源一起分析

二、压测方案设计

本次压测对象：

业务类型：快速查询接口
执行环境：Linux
工具：JMeter（非 GUI 模式）
压测策略：逐轮递增并发 + 短时间高强度冲击

核心目的只有一个：

找出系统的性能拐点和吞吐上限

2.1 逐轮压测参数说明

轮次	线程数	Ramp-Up(s)	循环次数	持续时间(s)	启动延迟(s)	压测目标	设计意图
1	200	5	10	10	1	初步试探	校验接口、脚本、监控
2	500	5	20	15	1	小幅压力	观察 Avg / P95 / QPS
3	1000	10	30	20	2	中等压力	开始观察排队现象
4	3000	15	50	30	2	高负载	接近系统拐点
5	5000	20	80	40	3	极限压力	明确系统上限
6	10000	30	100	60	5	超负荷	验证饱和与退化特征

2.2 为什么参数要这样设计？

✔ 线程数：逐步逼近瓶颈

一上来 10000 并发，只能得到一个结论：系统很慢
逐级递增，才能找到：
- 吞吐上限
- 延迟拐点

✔ Ramp-Up：刻意偏短

短 Ramp-Up = 快速形成并发洪峰
更容易暴露：
- 线程池不足
- DB 连接池耗尽
- 锁竞争问题

✔ 持续时间 + 循环次数

防止出现：
- 刚起压测就结束
- 部分线程没真正发起请求

✔ 启动延迟

给监控系统（CPU / JVM / DB）留准备时间
避免压测一开始就"盲跑"

三、6 轮压测真实结果汇总

吞吐量单位：samples/sec（≈ QPS）

轮次	线程数	样本数	Avg(ms)	P95(ms)	Max(ms)	错误率	QPS
1	200	2000	125	291	607	0%	353
2	500	6028	1101	2780	4216	0%	367
3	1000	8683	1957	5359	6759	0%	372
4	3000	13643	5969	12712	16085	0%	337
5	5000	19345	9159	27113	34982	0%	349
6	10000	27131	20047	67370	85321	0%	316

四、性能数据逐项拆解

4.1 Avg 响应时间：为什么会这样涨？

趋势非常清晰：

200 线程（125ms）：
- 资源充足，请求几乎无等待
500~1000 线程（1~2s）：
- 开始出现线程 / 连接排队
3000 线程（≈ 6s）：
- 用户已经明显感知卡顿
5000 线程（≈ 9s）：
- 系统接近极限
10000 线程（≈ 20s）：
- 请求大量堆积，严重过载

✅ 结论：

3000 并发是性能拐点，5000 已接近系统极限

4.2 P95 / P99：为什么这是最重要的指标？

并发	P95(ms)	P99(ms)
200	291	368
500	2780	3235
1000	5359	5818
3000	12712	16085
5000	27113	34982
10000	67370	75746

核心现象：

并发越高，尾延迟放大越明显
P95 / P99 远高于 Avg

➡️ 典型原因：

线程池耗尽
DB 连接池饱和
CPU 上下文切换频繁
请求排队时间急剧增加

系统慢不是慢在"执行"，而是慢在"等资源"

4.3 QPS：吞吐为什么不涨反降？

并发	QPS
200	353
500	367
1000	372
3000	337
5000	349
10000	316

关键结论：

峰值 QPS ≈ 370（500~1000 并发）
并发继续增加：
- QPS 不再增长
- 延迟持续恶化

⚠️ 这正是经典的性能拐点特征：

吞吐达到上限，但延迟开始指数级上升

4.4 错误率 0%，系统为什么依然"不可用"？

所有请求最终都返回 200
但：
- Avg = 20s
- P99 = 75s

➡️ 真实用户视角：

页面转 30 秒，你会等吗？

✅ 结论：

错误率 ≠ 可用性，高延迟本身就是性能失败

五、最终结论

维度	结论
稳定并发	1000 ~ 3000
性能拐点	≈ 3000 并发
极限并发	≈ 5000
最大吞吐	≈ 370 QPS
超负荷	≥ 10000 并发

性能压测不是一次行为，而是一个闭环

复制代码

压测 → 分析 → 定位 → 优化 → 再压测

总结

不看单一指标
关注趋势和拐点
用数据指导架构和容量决策

六、性能指标的"计算方式 + 解读方式"

这一节的目标只有一个：

让你在压测中，不靠背结论，而是靠"算得出来、推得下去"。

6.1 吞吐量（QPS / TPS）------系统"能吃多少"的能力

✔ 计算方式

复制代码

QPS = 成功请求总数 ÷ 压测总时长（秒）

📌 记忆口诀：

QPS 只和"完成了多少事"有关，和并发本身无关

✔ 怎么用 QPS 判断瓶颈？

看三个阶段：

并发 ↑，QPS ↑ → 系统仍有余力
并发 ↑，QPS 持平 → 接近吞吐上限
并发 ↑，QPS ↓ → 系统已过载

👉 一旦 QPS 不再增长，继续加并发只会制造排队

6.2 平均响应时间（Avg）------"整体感觉"，但不能单看

✔ 计算方式

复制代码

Avg = 所有请求耗时总和 ÷ 请求总数

✔ 为什么 Avg 经常"骗人"？

举个极端例子：

99 个请求：100ms
1 个请求：30s

Avg ≈ 398ms

👉 但 那 1 个用户已经崩溃了。

📌 总结：

Avg 只能看趋势，不能判断体验

6.3 P95 / P99 ------真正的"用户体验指标"

✔ 计算逻辑

把所有请求按耗时排序，

第 95% / 99% 位置的那个时间，就是 P95 / P99

✔ 如何用 P95 / P99 判断是否"可用"？

经验判断（非常实用）：

场景	P95	用户感受
< 500ms	几乎无感	非常流畅
1~2s	可接受	稍慢
3~5s	明显卡顿	已不友好
> 10s	不可接受	性能失败

📌 总结：

系统慢，不是慢在平均值，而是慢在那 5% / 1% 的请求

6.4 错误率（Error Rate）------最容易被误解的指标

✔ 计算方式

复制代码

错误率 = 失败请求数 ÷ 请求总数 × 100%

✔ 为什么"错误率 = 0%"也可能是灾难？

因为：

HTTP 没报错
但用户等了 30 秒

📌 结论一定要记住：

高延迟，本身就是一种失败

6.5 并发数 ≠ 系统能力（90% 的人会踩的坑）

✔ 并发到底是什么？

同一时刻，系统里"正在处理或等待处理"的请求数量

✔ 为什么并发越高，系统越慢？

核心只有一句话：

资源是有限的，并发只是让更多请求来"抢资源"

当出现以下现象：

线程池满
DB 连接池满
CPU 上下文切换频繁

➡️ 请求只能排队等待

七、如何一步步判断"系统瓶颈在哪里"？

这是压测能直接套用的标准流程。

Step 1：先看吞吐（QPS）是否到顶

并发 ↑
QPS 不再 ↑

➡️ 说明系统已经"吃不下更多请求"

Step 2：再看延迟是否开始失控

Avg 是否陡增
P95 / P99 是否指数级上升

➡️ 说明请求开始大量排队

Step 3：结合资源指标"对号入座"

现象	最可能瓶颈
CPU 接近 100%	计算 / 线程切换
Load 很高，CPU 不满	线程阻塞 / IO
DB 连接池满	SQL 慢 / 连接数不足
内存持续上涨	缓存或泄漏

📌 口诀：

QPS 定上限，延迟判体验，资源定瓶颈

八、并发压测"终极回答模板"

"你是怎么判断系统扛不住的？"

你可以这样回答：

1️⃣ 我先逐步提高并发，观察 QPS 的增长情况

2️⃣ 当 QPS 不再增长时，说明系统吞吐达到上限

3️⃣ 同时 Avg、P95、P99 开始明显上升，说明请求在排队

4️⃣ 再结合 CPU、线程池、DB 连接池定位具体瓶颈

5️⃣ 最终得到稳定并发、性能拐点和极限并发三个结论

👉 这就是"有方法论的压测"，而不是跑脚本。

九、记忆版总结

复制代码

并发不是能力，吞吐才是能力

Avg 看趋势，P95 看体验

QPS 到顶 + 延迟暴涨 = 性能拐点

错误率为 0，也可能是系统失败