JMeter压测4000并发实战：从线程配置到瓶颈定位全解析-港品优选

很多团队做性能压测时，第一步就错了：不管三七二十一，先在 JMeter 里把线程数调到 4000，然后点击启动，结果 JMeter 自己先卡死了，或者压测机 CPU 跑满，服务端还没到瓶颈。

这不是 JMeter 没用对，而是对“4000 并发”的理解出了问题。并发数不等于线程数，更不等于在线用户数。真正有效的并发，是同时打到服务器上的活跃请求数量。

本文将以 JMeter 压测 4000 并发为目标，完整拆解一条实战路线：从概念辨析、脚本设计、阶梯加压、分布式压测、监控排查到瓶颈定位。读完你不仅能跑出 4000 并发的压力测试，还能回答老板最关心的问题：服务器到底还能扛多少。

做性能压测，尤其是高并发压测，最大的难点不是把并发数“拉上去”，而是准确判断哪些请求在什么条件下达到多少 TPS、平均响应时间多少、资源消耗多少、系统的拐点在哪里。这也是本文要解决的核心问题。

1. 压测 4000 并发前，必须先想清楚的三个问题

只看“4000 并发”这几个字，很容易让人陷入数字崇拜。比如：别人能做到 4000 并发，我是不是也要做到？如果做不到 4000，是不是系统性能不行？

这里首先要澄清一个概念误区。

第一个问题：4000 并发到底指什么？

并发数在不同语境下，含义差别很大。

在线用户数：登录系统但未必有操作的连接，比如在线玩游戏、挂着页面。
并发会话数：服务器当前保持的会话连接数量。
并发请求数：同时发起的 HTTP 请求或业务请求数量。

JMeter 中设置的线程数，对应的是“虚拟用户数”。每个虚拟用户会持续循环执行脚本。如果每个用户每次循环只发一个请求，那么理论并发请求数约等于线程数。但如果脚本中一个循环发 3 个请求，那么同时打到服务器的请求数会接近线程数的 3 倍。

所以，配置 4000 线程，不代表系统就是 4000 并发。它只是虚拟用户数，真正的并发量取决于单位时间内实际发出的请求数。

第二个问题：4000 并发的压测结果，是否真实反映了系统能力？

JMeter 运行 4000 线程时，每台压测机本省就在消耗 CPU 和内存。如果压测机资源不足，请求本身会产生排队，导致响应时间虚高。这测出来的不是服务器性能，而是压测机瓶颈。

另外，JMeter 默认的 HTTP 客户端在 4000 线程下会创建大量连接，如果没开启连接复用，会带来严重的 TIME_WAIT 问题，压测结果同样失真。

第三个问题：压测的目标是什么？是找到瓶颈，还是跑一个数字？

性能压测的核心目标是找到系统的承受边界和瓶颈点。4000 并发只是一个目标值或压力水平，更重要的是观察：

系统吞吐量（Throughput，即 TPS）是否还能增长；
平均响应时间（Avg RT）是否出现断崖式升高；
错误率（Error%）是否超过阈值；
CPU、内存、磁盘、网络是否达到瓶颈。

在实际项目中，更推荐的做法是先小并发摸底，再阶梯加压，观察系统的“拐点”出现在哪里。如果系统在 1500 并发时 TPS 就开始下降，那 4000 并发压测的意义就在于论证：当前系统不支持 4000 并发，需要优化或扩容。这个结论本身，就是性能压测最重要的产出。

1.1 这些核心术语必须先对齐

术语	含义	在 JMeter 中对应的概念
线程数	虚拟用户数	Thread Group 中的 Number of Threads
Ramp-Up 时间	达到最大线程数所需时间	Thread Group 中的 Ramp-Up Period
循环次数	每个虚拟用户执行的循环次数	Loop Count
TPS	每秒事务数，系统吞吐量核心指标	通过聚合报告或后端监听器统计
RT	响应时间，单个请求的耗时	聚合报告中的 Average / Percentile
错误率	失败请求占总请求的比例	聚合报告中的 Error %
拐点	吞吐量开始下降或响应时间急剧升高的点	通过阶梯加压观察

2. JMeter 核心机制与 4000 并发的技术挑战

JMeter 是 Apache 旗下基于 Java 的性能测试工具。它的核心机制是：通过线程组模拟虚拟用户，每个线程独立运行测试计划中的 Sampler，采集并汇总结果。

2.1 4000 并发压测，难点在哪里

如果只是做一个 50 并发的接口冒烟测试，JMeter 默认配置足够。但在 4000 并发场景下，会遇到几个非常现实的问题：

问题一：本地压测机成为瓶颈。

4000 个线程同时运行，每个线程都要维护自己的上下文、请求数据、响应数据。JMeter 默认的 JVM 参数通常不足以支撑这么大的并发量，会出现 GC（垃圾回收）频繁、内存溢出、线程阻塞等问题。

问题二：连接数耗尽。

如果被测服务部署在 Tomcat 上，默认最大线程数通常是 200。当并发量超过 200 时，多余的请求会进入 Tomcat 的连接队列等待。如果 JMeter 并发到 4000，Tomcat 日志中会大量出现连接超时，甚至拒绝连接的错误。

问题三：网络带宽与端口资源限制。

一台压测机发出 4000 并发请求时，会消耗大量的客户端端口。Linux 系统默认临时端口范围有限（通常是 32768-60999），如果连接没有及时复用和回收，端口耗尽后新请求将无法发出。

问题四：资源监控缺失。

压测过程中，如果只盯着聚合报告，不关注服务器 CPU、内存、磁盘 I/O、网络等指标，即使发现问题也无法定位是 GC 耗时长、数据库连接池不够，还是磁盘写入太慢。

理解了这四个挑战，后面的操作步骤就有了针对性。

3. 环境准备：从 JDK 到 JMeter 插件

在开始 4000 并发压测之前，先准备好环境。本文章节的版本信息以实际操作环境为准，重点是演示过程和方法。

3.1 JDK 安装

JMeter 是 Java 应用，需要 JDK 1.8+。建议使用 JDK 8 或 JDK 11，这两个版本在兼容性和稳定性上表现较好。安装完成后，验证版本：

java -version

如果输出中包含类似java version "1.8.0_xxx"或openjdk version "11.0.xx"的信息，说明 JDK 安装成功。

3.2 JMeter 下载与安装

从 Apache JMeter 官网下载二进制包，解压到任意目录即可。需要注意：

Windows 下解压后，运行bin/jmeter.bat启动界面；
Linux/macOS 下运行bin/jmeter.sh启动。

启动成功后，会看到 JMeter 图形界面，初始配置即可满足普通压测需求。

3.3 必要插件安装

对于 4000 并发场景，推荐安装以下插件：

阶梯线程组（Ultimate Thread Group）该插件允许设置多个阶段的线程数、启动时间、持续时间和停止时间。比 JMeter 自带的线程组更适合观察系统在不同并发水平下的表现。

服务器性能监控插件（PerfMon）用于实时监控被测服务器的 CPU、内存、磁盘和网络指标。

安装插件的方式通常有两种：一种是下载 JMeter Plugins Manager，在插件管理器中勾选安装；一种是手动下载 JAR 包放入lib/ext目录并重启 JMeter。

注意：插件版本必须与 JMeter 主版本兼容，安装失败时优先检查 JMeter 主版本与插件版本是否匹配。

3.4 JVM 参数调优

4000 线程运行时，JMeter 默认的 JVM 堆内存很可能不够。建议修改bin/jmeter或bin/jmeter.bat中的 JVM 参数。

# Linux/macOS 下修改 bin/jmeter 文件，找到 HEAP 参数 HEAP="-Xms2g -Xmx4g -XX:MaxMetaspaceSize=512m"

修改完成后重启 JMeter。这里要特别注意：堆内存并不是越大越好，如果压测机本身只有 4G 内存，强行分配 6G 堆，会直接导致压测机频繁 GC，进而影响压测结果。

3.5 压测机系统参数调整

对于 Linux 压测机，需要调整系统文件句柄数和临时端口范围。临时端口范围控制在 4000 并发请求时，这些参数非常重要。

# 查看当前临时端口范围 cat /proc/sys/net/ipv4/ip_local_port_range # 临时修改临时端口范围（重启后失效，如需永久生效，可写入 sysctl 配置） echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range # 查看文件句柄限制 ulimit -n # 临时修改（以 root 身份执行） ulimit -n 65535

这些系统参数如果不变，压测过程中很可能出现 “Cannot assign requested address” 的错误。

4. 设计 4000 并发的压测场景

压测场景设计是整个流程中最核心、也最容易被忽视的环节。很多团队直接加线程数，完全不考虑业务模型，导致压测结果无法指导生产容量规划。

4.1 明确业务场景

在设置 4000 并发之前，先回答这些问题：

被测系统面向的用户量级是多少？
峰值时用户行为是什么？是登录、浏览、下单、搜索还是上传文件？
这些操作的调用比例是多少？

如果是一次登录接口压测，4000 并发意味着短时间内有 4000 个用户同时登录，这通常对应大促秒杀或抢购场景。如果是混合场景（30% 登录、40% 查询、30% 下单），那么需要按比例合理分配线程数。

4.2 选择线程组类型

JMeter 自带的线程组适合固定并发数的压测，比如直接设置 4000 线程。但更推荐使用阶梯线程组，原因有两个：

4000 个线程同时启动，会给服务器造成瞬间冲击，这种冲击既不符合真实场景，也不利于观察系统的平滑性能变化；
阶梯加压可以帮助定位系统拐点。

4.3 设计测试脚本

以登录接口为例，一个典型的 HTTP 请求脚本需要包含以下组件：

线程组或阶梯线程组
HTTP 请求默认值（配置协议、域名、端口）
HTTP Cookie 管理器（处理登录后的 Session）
HTTP 请求 Sampler（登录接口）
响应断言（校验返回结果）
聚合报告（结果汇总）
查看结果树（调试用）

这里给出一个 JMeter 脚本片段示例，以 XML 格式展示关键部分，便于读者理解脚本结构（实际操作可直接在 JMeter 界面中配置，无需手写 XML）：

<!-- 文件路径：login_script.jmx 中的线程组部分 --> <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="登录接口 4000 并发"> <intProp name="ThreadGroup.num_threads">4000</intProp> <intProp name="ThreadGroup.ramp_time">60</intProp> <boolProp name="ThreadGroup.same_user_on_next_iteration">true</boolProp> <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testname="循环控制器"> <boolProp name="LoopController.continue_forever">false</boolProp> <intProp name="LoopController.loops">100</intProp> </elementProp> </ThreadGroup>

对应到图形界面的含义是：

线程数：4000
Ramp-Up 时间：60 秒（60 秒内启动 4000 个线程，相当于每秒新增约 67 个用户）
循环次数：100 次

4.4 参数化：让 4000 个用户身份不重复

压测登录接口时，如果所有线程都使用同一个测试账号，会面临两个问题：一是测试数据耦合，无法反映真实场景；二是服务器可能因会话冲突产生误判。

推荐使用 JMeter 的 CSV 数据文件配置实现参数化。准备测试账号文件users.csv：

username,password user001,123456 user002,123456 user003,123456

在 JMeter 中添加 CSV 数据文件配置：

文件名：users.csv
变量名称：username,password
分隔符：,
共享模式：所有线程

然后在 HTTP 请求的参数中引用变量：

{ "username": "${username}", "password": "${password}" }

这样 4000 个线程会循环读取 CSV 文件中的不同账号。

5. 完整压力测试执行步骤

上面完成了环境准备和脚本设计，下面走一遍完整的压测执行流。假设目标系统是一个部署在http://192.168.100.10:8080的后端服务，测试登录接口。

5.1 在 JMeter 中创建完整测试计划

步骤如下：

打开 JMeter，右键 Test Plan，选择 Add > Threads > Thread Group。
在线程组中设置线程数为 4000，Ramp-Up 为 60 秒，循环次数为 100。
添加 HTTP Cookie 管理器：右键 Thread Group，选择 Add > Config Element > HTTP Cookie Manager。
添加 HTTP 请求默认值：右键 Thread Group，选择 Add > Config Element > HTTP Request Defaults，填写协议为 http，服务器名称为192.168.100.10，端口为8080。
添加 HTTP 请求 Sampler：右键 Thread Group，选择 Add > Sampler > HTTP Request，填写请求路径/api/login，请求方法为 POST，并按之前的设计参数化用户名和密码。
添加响应断言：右键 HTTP Request Sampler，选择 Add > Assertion > Response Assertion，验证响应结果是否包含"code":200或"success":true。
添加聚合报告：右键 Test Plan，选择 Add > Listener > Aggregate Report。

关键逻辑解释：HTTP Cookie 管理器负责维持会话，HTTP 请求默认值避免重复配置，响应断言判断请求是否真正成功（只看 HTTP 200 不代表业务成功）。

5.2 命令行模式与非 GUI 模式

4000 并发在 GUI 模式下执行会有两个明显问题：一是 GUI 本身会消耗大量内存，影响压测结果；二是执行过程中点击界面可能导致线程阻塞。

因此，高并发压测必须在命令行模式执行：

# 进入 JMeter bin 目录 cd /opt/jmeter/bin # 执行压测脚本，结果输出到 result.jtl，并生成 HTML 报告 ./jmeter -n -t /opt/test_plan/login_4000.jmx -l /opt/test_plan/result.jtl -e -o /opt/test_plan/html_report

参数说明：

-n：非 GUI 模式
-t：指定测试计划文件路径
-l：指定结果日志文件路径
-e：测试结束后生成 HTML 报告
-o：HTML 报告输出目录

执行过程中，终端会输出实时进度，包括线程启动数量、已完成的请求数、错误数量等。

5.3 使用阶梯线程组观察拐点

如果安装了 Ultimate Thread Group，可以配置多个阶段。比如：

阶段 1：500 线程，启动 30 秒，持续 60 秒
阶段 2：1000 线程，启动 30 秒，持续 60 秒
阶段 3：2000 线程，启动 30 秒，持续 60 秒
阶段 4：4000 线程，启动 60 秒，持续 120 秒

这种设计能有效观察系统在 500、1000、2000、4000 并发下的表现变化。

6. 压测过程中的监控方法

压测中最重要的环节就是同时监控“两端”：JMeter 端的请求情况和服务器端的资源消耗。

6.1 JMeter 端实时查看

命令行压测时可以配合聚合报告监听器，但 GUI 模式只建议在调试阶段使用。更好的方式是使用后端监听器将结果发送到 InfluxDB + Grafana，实现实时监控。如果不具备这套监控环境，可以直接观察命令行输出中的实时摘要。

6.2 服务器端资源监控

推荐使用 nmon、top、free、dstat 等命令实时监控服务器资源。比如持续观察 CPU 和内存：

# 每 2 秒刷新一次，按 CPU 使用率排序 top -d 2 # 查看内存使用情况 free -h # 查看磁盘 I/O iostat -x 2

同时注意观察以下指标：

指标	健康参考值	出现问题的征兆
CPU 使用率	整体 ≤ 70%	持续 100%，说明计算资源饱和
内存使用率	整体 ≤ 80%	频繁 swap，内存溢出
磁盘 I/O	util ≤ 70%	磁盘 %util 持续接近 100%
网络带宽	不丢包不重传	网络重传率高，带宽打满
应用线程数	低于容器最大线程数	线程池满，大量请求排队

6.3 应用日志与中间件监控

如果系统采用 Tomcat，需要查看 Tomcat 的可执行线程数是否打满。进入 Tomcat 目录查看日志：

tail -f /opt/tomcat/logs/localhost.log tail -f /opt/tomcat/logs/catalina.out

当出现以下日志时，说明服务端线程池已经达到上限：

SEVERE: All threads (200) are currently busy, waiting. Increase maxThreads or check the servlet

当出现大量connect timed out错误时，说明连接队列已满，服务器拒绝新请求。

MySQL 数据库连接池可以查看连接数是否达到上限，一般通过show processlist查看当前活跃连接数。如果连接数长期接近 max_connections，数据库连接池就会成为瓶颈。

7. 如何分析压测结果

压测完成后，最关心的是三个指标：TPS、响应时间、错误率。下面以聚合报告和 HTML 报告为工具，分析 4000 并发下的性能体检报告。

7.1 聚合报告关键指标解读

聚合报告中的每行数据对应一个取样器。主要看以下几列：

字段	含义	优秀标准（经验值）
Samples	总请求数	请求越多，统计越可靠
Average	平均响应时间	接口逻辑不同标准不同，一般 < 500ms
Median	中位数响应时间	比平均值更能反映大多数用户体验
90% Line	90% 的请求在此时间内完成	一般 < 1000ms
Min / Max	最小 / 最大响应时间	最大值反映极端峰值情况
Error %	错误率	一般 < 0.1%
Throughput	吞吐量，即 TPS	越高越好

小结论：如果 4000 并发下，TPS 持续稳定且错误率接近 0，说明系统具备承受 4000 并发的能力。如果 TPS 在某一并发量出现明显下降，说明系统已过饱和，后续压测只会增加排队时间，不会带来更多吞吐量。

7.2 常见结果误区

很多测试人员看到平均响应时间 300ms，就觉得系统性能很好。但这是错误的。

假设有 100 个请求，99 个耗时 100ms，1 个耗时 20 秒，平均响应时间是约 300ms。但真实用户体验是 99% 的用户很快，1% 的用户卡了 20 秒。因此，平均响应时间往往掩盖长尾问题。在 4000 并发压测中，更应关注 90%、95%、99% 分位值，以及最大值。如果 99% Line 是 800ms，而 Max 是 15 秒，说明系统存在明显的长尾延迟。

7.3 判断系统瓶颈所在

当 4000 并发压测结果不理想时，按以下顺序排查：

应用层：Tomcat 线程数是否打满、连接队列是否堆积？
中间件层：Nginx 的 worker_connections 是否够用？网关路由是否超时？
数据库层：慢查询数量是否大幅增加？连接池是否耗尽？锁等待是否严重？
资源层：CPU 是否打满？磁盘 I/O 是否成为瓶颈？内存是否频繁交换？

举个例子：如果压测过程中服务端 CPU 只有 30%，但 TPS 很低，那么重点排查锁、慢 SQL、远程调用、序列化等，它们可能才是真正的瓶颈。如果说 CPU 已经 95% 以上，那说明计算资源耗尽，扩展方向应该是加机器或优化代码。

8. 4000 并发压测分布式方案

当单台压测机资源不够支撑 4000 并发时，可以采用 JMeter 分布式压测。这在高并发场景下几乎是必然选择。

8.1 分布式架构

JMeter 分布式结构包含两部分：

Master：控制机，负责分发脚本、汇总结果，不直接产生压力。
Agent（Slave）：执行机，负责实际运行线程组，向被测系统发起请求。

比如使用 4 台 4 核 8G 的 Agent，每台分配 1000 个线程，就能支撑 4000 并发。

8.2 配置步骤

假设 Master 和 Agent 机都安装了 JMeter：

首先配置 Agent 机，进入bin/jmeter-server（Windows 是jmeter-server.bat）：

# Agent 机启动远程服务（默认端口 1099） ./jmeter-server -Djava.rmi.server.hostname=192.168.100.20

再配置 Master 机，进入bin/jmeter.properties，找到remote_hosts配置，修改为：

remote_hosts=192.168.100.20:1099,192.168.100.21:1099,192.168.100.22:1099

在 Master 机器上使用命令行执行分布式压测：

./jmeter -n -t /opt/test_plan/login_4000.jmx -l /opt/test_plan/result.jtl -e -o /opt/test_plan/html_report -R 192.168.100.20:1099,192.168.100.21:1099,192.168.100.22:1099

8.3 分布式压测注意事项

分布式压测有三个坑需要特别强调：

脚本中的数据文件：CSV 文件必须同步分发到所有 Agent 机的对应路径，且路径一致，否则执行时读取不到文件。
结果汇总的网络开销：所有 Agent 的测试结果都要回传到 Master，4000 并发下这个网络流量不小。如果 Master 带宽不足，会造成结果丢失，建议脚本中不要开启过多 Debug 监听器，只保留聚合报告。
时钟同步：虽然 JMeter 是最终结果以各 Agent 上报时间为准，但跨机器后，服务器监控和 JMeter 结果的时间对应关系容易不准确，建议部署 NTP 时间同步。

9. 常见压测失败问题与排查方法

4000 并发压测过程中，最常见的错误和排查方法如下表所示：

问题现象	可能原因	排查方式	解决方案
压测机报 Cannot assign requested address	本地临时端口已耗尽，连接未复用	`netstat -antpl`查看端口连接状态，统计 TIME_WAIT 数量	开启 HTTP 连接复用，调大临时端口范围，增加压测机数量
JMeter 内存溢出 OutOfMemoryError	JVM 堆太小，结果数据量过大	查看 jmeter 日志中的 OOM 报错，检查 JVM 参数	增大 HEAP 值，减少不必要监听器，使用命令行模式
压测刚开始错误率飙升	服务端线程池不够，连接队列打满；或压测请求没带正确的 Header/Token	查看服务端日志，查看聚合报告中具体错误内容	增加服务端线程数或优化服务处理能力；检查脚本的鉴权逻辑
TPS 上不去，CPU 和内存都低	应用内部存在锁竞争、慢 SQL、远程调用超时、磁盘 I/O 瓶颈	使用 Arthas 或 JProfiler 进行线程分析，查看 BLOCKED 状态的线程；查看慢查询日志	优化 SQL、减少锁粒度、替换磁盘为 SSD 等
响应时间出现周期性波动	压测机 GC 周期性暂停，或服务端有定时任务	查看压测机 GC 日志，查看服务端定时任务时间点	调优压测机 JVM 参数；调整或限制服务端定时任务期间的请求
4000 线程启动后 JMeter 卡死	本地线程数过多导致线程上下文切换开销过大	查看压测机 CPU 使用率，查看线程 dump	改为分布式压测，降低单机线程数，每台不超过 1000-1500
压测结果中所有请求都是 502/504	网关或负载均衡连接后端超时，后端已挂	查看 Nginx 错误日志、后端应用日志	检查后端服务是否宕机，检查网关超时配置，合理设置队列大小

10. 最佳实践与工程化落地建议

10.1 先做小流量调试，再上 4000 并发

很多团队在调试阶段就使用 4000 线程，这是低效且危险的做法。建议先用少量线程（10-50）执行脚本，用“查看结果树”检查请求参数、响应数据、断言是否正确。调试通过后，再逐步加压到 4000。在压测评审中，这种做法也更容易得到开发团队的信任。

10.2 压测环境必须和生产隔离

压测 4000 并发会对服务器、数据库造成真实冲击。线下压测必须使用独立压测环境，且压测前要和开发、运维确认不影响其他项目。在云环境做压测要注意流量费用和限流策略，推荐先小范围测试，确认不会影响线上业务再执行。

10.3 每个项目总结基线数据

完成一轮压测后，应该沉淀以下基线数据，形成性能测试报告：

系统最大支持并发数
系统最佳并发数（TPS 最高的并发区间）
各接口 90%、99% 分位响应时间
饱和点时的 CPU、内存、磁盘 I/O、网络指标

这些数据沉淀后，后续做容量规划、链路优化、扩容决策时可以直接作为参考。

10.4 关注慢 SQL 与远程调用

高并发场景下，性能瓶颈最常出现在数据库和依赖服务。JMeter 压测发现 TPS 上不去时，不要只看接口逻辑代码，先看慢 SQL、连接池、Redis 缓存命中率、外部 WebService/RPC 调用时间。这些数据比盲目优化代码更有效。

10.5 充分利用后端监听器建立监控体系

团队如果具备 InfluxDB 和 Grafana 环境，建议配置 JMeter 后端监听器（Backend Listener），将实时 TPS、响应时间、线程数指标写入时序数据库。这样在压测过程中，可以像看监控大盘一样观察每一秒的性能变化。该配置的图形操作路径为：右键 Test Plan -> 添加 -> 监听器 -> Backend Listener，选择org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSender，然后填写 InfluxDB 的推送地址即可。

11. 总结与后续学习路线

本文围绕 4000 并发压测展开，完整覆盖了概念澄清、环境准备、脚本设计、执行监控、结果分析、分布式压测与排错方法。核心结论有三点：

第一，4000 并发不是简单设置 4000 个线程，它考验的是测试脚本设计、压测机资源配置、服务器支撑能力和结果分析方法。第二，性能压测的最终产出不是“跑了一个 4000 并发的数字”，而是找出了系统的峰值点、瓶颈点和优化方向。第三，从单机压测到分布式压测，是并发量增长后的必然路径，团队需要提前准备压测机资源池。

如果你刚从功能测试转向性能测试，下一步建议按这样的顺序练习：

用 JMeter 对本地项目做 100 并发的基础压测，掌握脚本设计、断言、聚合报告分析；
对系统做阶梯加压，找到 TPS 拐点，理解资源与吞吐量的关系；
学习 JVM 线程分析、数据库慢查询优化、连接池调优，掌握定位瓶颈的能力；
搭建 JMeter + Grafana 监控体系，并尝试对线上系统做小流量压测，逐步积累容量管理经验。

性能压测不是一次性工作，而是系统上线前的质量门禁，更是发现系统弹性能力的手段。希望这篇文章能帮你在 4000 并发压测这条路上少走弯路。建议收藏备用，实际压测中遇到问题可以直接按文中的排查表对号入座。

企业官网建设流程全解析