JMeter 4000并发压测实战：从脚本设计到性能瓶颈定位全流程

这次我们直接来看一个非常硬核的话题：用 JMeter 把系统压到4000 并发，看它到底会不会挂。

很多同学做性能压测，都是拿 JMeter 随便加个 100、200 的线程数，跑完看看聚合报告就结束了。但真正的线上场景里，秒杀、抢购、热点活动，瞬时流量轻松突破几千甚至上万 QPS。如果不在上线前用 4000 并发把接口、数据库、中间件、网络链路都压一遍，等线上真的被流量打崩了，再回去看日志，那时候就晚了。

这篇文章不是 JMeter 的菜单讲解，而是一次接近实战的压测全过程拆解。我会从安装部署开始，带你完成测试计划设计、脚本编写、参数化、断言、监听器配置，再到 4000 并发阶梯加压、性能瓶颈定位、系统调优，最后把监控数据转换成可读的测试报告。全程围绕JMeter 性能压测 4000 并发这个核心目标展开，每一步都给出可复制的配置和命令，你可以直接跟着在自己的测试环境里跑一遍。

1. 核心能力速览

先把这次实战涉及到的关键能力整理成一张表，方便你对照自己的环境快速判断能不能跟做。

JMeter 本身不限制线程数上限，4000 并发在脚本层面就是一个线程组里配置 4000 个线程，或者按照阶梯加压的方式逐步加到 4000。真正限制你压测上限的，是压测机自身的 CPU、内存、文件句柄数，以及你用 GUI 模式还是命令行模式去跑。

2. 适用场景与使用边界

在做 4000 并发压测之前，先明确 JMeter 适合解决什么问题，以及哪些场景不能盲目用。

2.1 适合做什么

• 接口容量评估：一个订单接口、登录接口、查询接口，在 4000 并发下 TPS 能到多少，平均响应时间是多少，错误率是否在可接受范围内。
• 瓶颈定位：压测过程中观察 TPS 曲线和响应时间曲线，判断瓶颈在应用层、数据库连接池、Redis、MQ 还是带宽。
• 稳定性验证：4000 并发持续运行 10 到 30 分钟，检查内存泄漏、连接池耗尽、Full GC 频繁等问题。
• 上线前评估：新系统或大版本迭代上线前，用接近峰值的流量做一次摸底，给运维和开发提供容量参考。

2.2 不适合做什么

• JMeter 本身不做业务层面的功能正确性验证，它只负责模拟协议请求并统计响应结果。接口返回 200 不代表业务成功，需要配合断言判断响应内容。
• 4000 并发不等于 4000 个真实用户。真实用户会有思考时间、页面资源加载、网络波动，JMeter 压测通常不模拟真实浏览器行为，更偏向协议层压力。
• 如果目标系统是自己的开发环境或测试环境，压测没问题。但如果是未授权的线上系统、第三方网站、生产环境，压测可能触发限流、封禁，甚至影响真实用户，必须先获得授权。

2.3 合规与安全边界

性能压测本质上是对目标系统发起大量请求。这里必须明确边界：

• 只对你有权测试的系统进行压测，比如公司内部测试环境、预发环境或你自建的服务。
• 不要对未授权的线上地址发起高并发请求，这可能被判定为恶意流量。
• 压测数据要使用测试账号或脱敏数据，不要使用真实用户手机号、身份证号、银行卡信息。
• 压测过程会占用带宽和服务器资源，尽量选择业务低峰期进行，或者使用单独的压测集群。
• 如果系统涉及人脸识别、语音、图像等敏感能力，压测前确认数据合规和用户授权。

3. JMeter 本地部署环境准备

无论你用什么版本，JMeter 的部署都非常简单。它是纯 Java 应用，重点先把 Java 环境搞定。

3.1 环境检查清单

3.2 JDK 安装

Windows 和 Linux 都建议使用 OpenJDK 或 Temurin 发行版。安装完成后验证版本：

java -version javac -version

正常情况下会出现类似输出：

java version "11.0.18" 2023-04-18 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.18+10) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.18+10, mixed mode)

如果提示找不到 java 命令，说明环境变量没配置好。Windows 需要把 JDK 安装目录下的 bin 路径加入Path，Linux 可以使用export PATH=$PATH:/opt/jdk/bin临时生效，或写入/etc/profile。

3.3 JMeter 下载与安装

JMeter 官方不提供一键安装包，直接下载二进制压缩包解压即可使用。

1. 打开 Apache JMeter 官网下载页。
2. 选择apache-jmeter-5.x.zip或.tgz版本。
3. 下载完成后解压到指定目录。

Windows 解压示例：

Expand-Archive -Path .\apache-jmeter-5.6.3.zip -DestinationPath D:\tools\

Linux 解压示例：

tar -zxvf apache-jmeter-5.6.3.tgz -C /opt/

解压后的目录结构：

apache-jmeter-5.6.3/ ├── bin/ │ ├── jmeter.bat │ ├── jmeter.sh │ ├── jmeter.properties │ └── jmeter.log ├── lib/ │ ├── ext/ │ ├── junit/ │ └── ... ├── docs/ ├── printable_docs/ └── LICENSE

3.4 启动 JMeter

Windows 进入 bin 目录，双击jmeter.bat或执行：

cd D:\tools\apache-jmeter-5.6.3\bin jmeter.bat

Linux 执行：

cd /opt/apache-jmeter-5.6.3/bin ./jmeter.sh

启动后会弹出一个 JMeter GUI 窗口。注意，JMeter 官方文档和社区强烈建议：GUI 模式只用于创建测试计划和调试脚本，不要用 GUI 模式进行正式压测。尤其是 4000 并发这种高压力场景，GUI 会消耗大量本地资源，导致本身成为瓶颈。后面我会详细说命令行压测的正确姿势。

4. 构建 4000 并发压测脚本

启动 JMeter 之后，就要开始搭建测试计划了。这里我会带你完成一个标准 HTTP 接口压测脚本的完整构建过程，包括线程组配置、HTTP 请求、CSV 参数化、断言和监听器。

4.1 测试计划结构

在左侧测试计划树上，右键测试计划->添加->Threads (Users)->线程组，创建一个基础线程组。整体结构如下：

Test Plan ├── Thread Group (4000 并发) │ ├── HTTP Request (登录接口) │ │ ├── CSV Data Set Config │ │ └── HTTP Header Manager │ ├── HTTP Request (业务查询接口) │ │ ├── JSON Extractor │ │ └── HTTP Header Manager │ ├── Response Assertion │ └── Constant Throughput Timer ├── Aggregate Report ├── View Results Tree └── Simple Data Writer

4.2 线程组参数配置

线程组是整个压测的核心，直接决定并发模型。

这里要重点说下Ramp-Up Time的意义。直接把 4000 个线程瞬间全部启动，会产生一个非常陡峭的流量尖峰，这对压测机本身也是一次不小的冲击，而且会把目标系统的真实瓶颈掩盖在瞬间连接爆炸中。推荐设置为 60 秒到 120 秒，让并发数平滑上升到 4000，更容易观察系统性能曲线。

如果你希望实现更精细的阶梯加压，可以考虑使用插件jp@gc - Stepping Thread Group，它允许你配置初始线程数、每次增加线程数、每次增加耗时、持续运行时间等参数，适合分阶段摸清系统的性能拐点。不过这里我们先按标准线程组来搭。

4.3 HTTP 请求默认值

如果你要压测的是同一个域名下的多个接口，建议先添加一个HTTP Request Defaults配置元件，把协议、域名、端口统一配置在这里，后续每个 HTTP 取样器只写路径和参数，便于维护。

重点配置：

4.4 HTTP 请求：登录接口

第一个核心取样器是登录接口，这是大多数业务链路的第一步。

参数名称: login_request 请求方式: POST 路径: /api/v1/user/login Content-Type: application/json 请求体: { "username": "${username}", "password": "${password}", "captcha": "${captcha}" }

这里的${username}、${password}、${captcha}都是从外部 CSV 文件读取的变量，具体参数化方式见下一节。

4.5 CSV 参数化

4000 个并发用户不能都使用同一组账号密码。一方面真实场景中每个用户凭据不同，另一方面单账号高并发可能触发服务端防刷限制，导致测试失真。所以必须使用CSV Data Set Config做参数化。

右键线程组 ->添加->配置元件->CSV Data Set Config，配置如下：

CSV 文件内容示例users.csv：

user001,password001,captcha001 user002,password002,captcha002 user003,password003,captcha003 ... user4000,password4000,captcha4000

如果你的账号不足 4000 个，可以重复使用，把Recycle on EOF设置为 True，线程读取完所有行后从头开始继续读取。

这里有一个常见的坑需要注意：CSV 文件路径不能有中文或空格，否则某些版本会读取失败。另外，CSV 文件编码必须与File encoding一致，推荐统一 UTF-8。

4.6 HTTP 信息头管理器

登录接口返回的是 JSON，需要添加请求头，指定Content-Type为application/json。右键 HTTP 请求 ->添加->配置元件->HTTP Header Manager，添加：

如果登录后有 token、cookie 需要传递到后续接口，可以使用HTTP Cookie Manager或JSON Extractor提取 token 并动态传入请求头。后面接业务接口时会专门演示。

4.7 JSON 提取器

登录接口响应体通常是这种格式：

{ "code": 0, "message": "success", "data": { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." } }

后续业务查询接口需要携带这个 token。右键登录 HTTP 请求 ->添加->后置处理器->JSON Extractor，配置：

这样登录成功后，${auth_token}变量就被赋值了，后续接口的 Header 中可以直接引用。

4.8 业务查询接口

第二个核心取样器是业务查询接口，它依赖登录接口返回的 token。由于登录和查询是顺序执行的，需要把两个 HTTP 请求放到同一个线程组下，并保持顺序。

请求方式: GET 路径: /api/v1/user/order/list?page=1&size=${page_size} Header: Authorization: Bearer ${auth_token}

这里的${page_size}也可以通过另一个 CSV 文件做参数化，或者直接在参数中写死。

需要注意的是，JMeter 默认按线程组内取样器的排列顺序执行。如果你希望登录只执行一次、查询循环执行多次，可以使用仅一次控制器（Once Only Controller）把登录请求放进去，查询请求放在控制器外面。这个在长稳压测中很常用，能避免频繁登录对目标系统造成额外压力，同时更接近真实用户行为。

4.9 响应断言

压测过程中，接口可能返回 HTTP 200，但业务状态码是失败。比如响应体是：

{ "code": "50001", "message": "系统繁忙，请稍后重试" }

如果不加断言，JMeter 会把这种业务失败当成成功请求统计，最终报告中的错误率完全失真。所以必须添加响应断言。

右键 HTTP 请求 ->添加->断言->响应断言，配置：

这样只有响应体包含"code":0的请求才会被判定为成功，其他情况都会计入错误率。

4.10 控制压测流量

4000 并发条件下，如果不加控制，JMeter 会以最大速率发送请求，目标服务可能直接被压垮。更合理的做法是使用Constant Throughput Timer控制 TPS，让它只发送你能预期的目标流量。

右键线程组 ->添加->定时器->Constant Throughput Timer，配置：

注意，Target Throughput的单位是每分钟请求数。如果你期望全组 TPS 是 4000，这里要填240000。

这里需要理解一个关键点：线程数是 4000，不等于 TPS 就是 4000。TPS 取决于每个事务的响应时间和定时器控制。如果接口响应时间平均 100ms，4000 个线程理论上每秒最多发 40000 个请求，这个数字远超 4000 TPS。所以"4000 并发"描述的是最大并发线程数，而不是实际吞吐量。真正要控制的是 QPS/TPS，让流量模型符合测试目标。

4.11 监听器配置

调试脚本阶段，添加View Results Tree可以直观查看每个请求的响应体，判断参数提取是否正确。正式压测阶段，不要开这个监听器，它会占大量内存。

推荐添加以下监听器：

• 聚合报告：查看 TPS、平均响应时间、错误率、90% 响应时间等关键指标。
• 汇总报告：类似于聚合报告，数据更简洁。
• Simple Data Writer：把压测结果实时写入 jtl 文件，供后续命令行生成 HTML 报告。

正式压测时，建议只保留Simple Data Writer和后端监听器，其他监听器全部禁用或删除。

5. 命令行模式执行 4000 并发压测

这是整个实战最关键的环节。正式压测必须使用命令行模式。GUI 模式下，JMeter 界面的刷新、图表绘制、监听器数据展示都会消耗大量 CPU 和内存，4000 并发时压测机自己会先崩溃。

5.1 保存测试计划

在 GUI 中完成脚本调试后，点击保存，文件名如stress_test.jmx。确保 jmx 文件中所有 CSV 文件路径都是绝对路径，或者将 jmx 文件和 CSV 放在同一个相对目录下。

推荐目录结构：

jmeter-stress/ ├── test.jmx ├── data/ │ └── users.csv ├── results/ │ ├── result.jtl │ └── html-report/ └── logs/ └── jmeter.log

5.2 命令行压测

打开终端，进入 JMeter 的 bin 目录，执行：

./jmeter.sh -n -t /path/to/test.jmx -l /path/to/result.jtl -j /path/to/jmeter.log -e -o /path/to/html-report

参数说明：

Windows 下执行：

jmeter.bat -n -t D:\jmeter-stress\test.jmx -l D:\jmeter-stress\results\result.jtl -j D:\jmeter-stress\logs\jmeter.log -e -o D:\jmeter-stress\results\html-report

执行后命令行会实时输出每个线程组的运行进度，类似这样：

Creating summariser <summary> Summary + 1234 in 00:00:30 = 41.1/s Avg: 231 Min: 92 Max: 1876 Err: 0 (0.00%) Summary + 2456 in 00:00:30 = 81.9/s Avg: 245 Min: 95 Max: 2345 Err: 0 (0.00%) Summary = 3690 in 00:01:00 = 61.5/s Avg: 238 Min: 92 Max: 2345 Err: 0 (0.00%)

这里能直接看到实时 TPS、平均响应时间、错误数。如果在命令行中看到 Err 比例快速增长，说明系统已经出现压力过大或响应异常，需要结合目标服务器的监控数据判断瓶颈位置。

5.3 注意事项：内存设置

4000 线程的测试计划会占用较多内存。默认 JVM 堆内存可能不够，启动前需要调整 JMeter 的堆内存配置。

编辑bin目录下的jmeter.bat或jmeter.sh，找到类似下面的配置：

set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m

修改为：

set HEAP=-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m

Linux 的jmeter.sh中修改：

HEAP="-Xms4g -Xmx4g -XX:MaxMetaspaceSize=512m"

注意，压测机的内存设置不要超过物理内存的一半，否则操作系统本身的内存压力会影响压测结果。比如压测机是 16G 内存，JVM 堆设置 4G 到 6G 比较合理。

5.4 压测机系统参数调整

4000 并发意味着同时建立数千个 TCP 连接，Linux 系统默认的文件描述符上限可能不够。压测前执行：

ulimit -n 65535

这个命令只在当前会话生效。要永久生效，编辑/etc/security/limits.conf，添加：

* soft nofile 65535 * hard nofile 65535

同时，如果压测的是本地回环地址，短时间大量请求可能耗尽本地端口，可以调整端口范围：

sysctl -w net.ipv4.ip_local_port_range="1024 65535" sysctl -w net.ipv4.tcp_tw_reuse=1

这些参数需要根据你的压测机和目标服务器实际情况调整，不是所有环境都需要动。但先记住这个排查方向，如果压测时遇到Address already in use或者大量连接超时，多半跟这个有关。

6. 功能测试与效果验证

4000 并发压测不是跑完就结束，关键在于事后验证数据是否可信、系统瓶颈定位是否准确。这一节带你构建一套完整的验证流程。

6.1 压测前的基线测试

直接上 4000 并发之前，建议先跑 3 轮基础测试作为基线数据：

基线测试可以用同一份 jmx 文件，通过命令行参数覆盖线程数。JMeter 支持使用属性传递参数：

./jmeter.sh -n -t test.jmx -Jthreads=1000 -Jrampup=30 -Jloops=50 -l result_1000.jtl

在线程组中，把线程数设置为${__P(threads, 4000)}，Ramp-Up 设置为${__P(rampup, 60)}，循环次数设置为${__P(loops, 100)}。这样就能通过-J参数动态控制并发规模，不需要为每轮测试创建单独的 jmx 文件。

6.2 正式执行 4000 并发压测

基线数据采集完成后，使用以下命令执行正式压测：

./jmeter.sh -n -t test.jmx -Jthreads=4000 -Jrampup=120 -Jloops=200 -l results/run_4000.jtl -j logs/run_4000.log -e -o reports/html_4000

这里的-Jloops=200表示每个线程执行 200 次循环，4000 线程乘以 200 次循环，总共会生成 80 万条请求记录。如果目标服务扛不住，错误率会直线上升，你需要立即关注日志输出。

压测过程中，盯住三个核心数据点：

• TPS 是否持续上升：如果 TPS 在某个数值突然停止增长甚至下降，说明系统资源已经耗尽，服务端开始排队。
• 平均响应时间是否线性增长：响应时间随着并发数上涨是正常的，但如果出现陡增，说明出现了排队或线程阻塞。
• 错误率是否超过阈值：一般压测要求错误率低于 0.1%，稳定性测试可以放宽到 1%。如果超过 1%，需要优先排查超时、连接拒绝、5xx 错误。

6.3 判断压测数据是否有效

压测结束后，jtl 文件记录了所有请求的响应码、响应时间、发送字节数等。你需要从以下几个维度判断这次压测是否有效：

6.4 查看聚合报告

压测完成后，如果开启了聚合报告监听器，可以在 GUI 中打开 jtl 文件查看结果。但更推荐的方式是通过命令行直接生成 HTML 报告。

./jmeter.sh -g results/run_4000.jtl -o reports/html_4000_final

HTML 报告里包含以下关键图表：

• APDEX 指数：用户满意度的量化指标，0.9 以上表示体验良好。
• 响应时间百分位图：展示了 50%、90%、95%、99% 响应时间，对应不同分位的用户体感。
• TPS 走势图：判断系统吞吐量是否稳定。
• 错误率趋势图：如果错误率随时间递增，通常说明系统开始出现资源耗尽或连接泄漏。

打开报告后，重点看Statistics表格中的这几列：

Label, #Samples, Average, Min, Max, Std. Dev., Error %, Throughput

Average是平均响应时间，Throughput是每秒事务数，Error %是错误率。4000 并发下，如果 Throughput 远低于预期且 Error % 很高，说明瓶颈特征明显。

6.5 结果数据可信度评估

最后做一次"数据反证"。把 4000 并发压测得到的最大 TPS，乘以平均响应时间，得到的是理论并发数。比如报告显示 TPS 为 8000，平均响应时间 400ms，那么理论并发线程数约为 3200（8000 × 0.4），与配置的 4000 差距较大，说明有 800 个线程处于等待空闲状态，可能需要检查线程池配置、连接池大小或定时器是否过度限制了吞吐。

7. 接口 API 与批量任务扩展

JMeter 除了通过 GUI 和命令行执行压测，还可以作为服务端接口被外部调度，适合持续集成和自动化压测平台集成。

7.1 命令行方式的批量压测脚本

如果你的压测任务需要批量执行，比如不同接口、不同并发梯度各跑多轮，可以写一个 Shell 或 Python 脚本循环调用 JMeter 命令。

下面给出一套通用模板，用 Shell 实现不同并发梯度依次压测：

#!/bin/bash # batch_stress_test.sh # 用法: ./batch_stress_test.sh THREADS=(100 500 1000 2000 4000) TEST_PLAN="test.jmx" OUTPUT_DIR="./results" for THREAD in "${THREADS[@]}" do echo "========== 开始压测，并发数: ${THREAD} ==========" ./jmeter.sh -n -t ${TEST_PLAN} \ -Jthreads=${THREAD} \ -Jrampup=$((THREAD / 20)) \ -Jloops=100 \ -l ${OUTPUT_DIR}/result_${THREAD}.jtl \ -j ${OUTPUT_DIR}/log_${THREAD}.log \ -e -o ${OUTPUT_DIR}/report_${THREAD} echo "========== 并发数 ${THREAD} 压测完成 ==========" done

Python 批量调用示例：

import subprocess import time threads_list = [100, 500, 1000, 2000, 4000] jmeter_path = "/opt/apache-jmeter-5.6.3/bin/jmeter.sh" test_plan = "test.jmx" for threads in threads_list: output_file = f"results/result_{threads}.jtl" report_dir = f"results/report_{threads}" cmd = [ jmeter_path, "-n", "-t", test_plan, "-Jthreads", str(threads), "-Jrampup", str(threads // 20), "-Jloops", "100", "-l", output_file, "-e", "-o", report_dir ] print(f"开始压测: {threads} 并发") result = subprocess.run(cmd, capture_output=True, text=True) if result.returncode != 0: print(f"压测失败: {threads} 并发，错误信息: {result.stderr}") else: print(f"压测完成: {threads} 并发，报告已生成到 {report_dir}") time.sleep(5)

这样你就能一键跑完整个并发梯度，把多轮结果汇总后对比，快速找到系统从"正常"到"劣化"的拐点。

7.2 批量测试数据准备

压测过程中经常需要构造大量测试数据。如果使用 CSV 配置元件，可以用 Python 脚本生成：

import csv with open("users.csv", "w", newline="") as f: writer = csv.writer(f) for i in range(1, 4001): writer.writerow([f"user{i:04d}", f"password{i:04d}", f"captcha{i:04d}"]) print("已生成 4000 条测试数据")

这里要提醒一个点：生成的密码等数据如果是存量的测试账号，需要确认目标系统的测试环境支持这些账号真实登录。如果账号不存在，登录接口返回业务失败，压测结果会全部是错误，也会影响真实性能数据的获取。

7.3 分布式压测扩展

单机跑 4000 并发时，JMeter 进程占用资源会明显上升。如果继续提高到 8000、10000 甚至更高，单机模式很容易遇到文件句柄、内存、CPU 瓶颈。此时可以使用 JMeter 分布式压测：一台 master 调度机 + 多台 slave 执行机。

启动 slave 节点：

./jmeter-server.sh -Dserver.rmi.localport=4000

master 节点执行压测时，通过-R指定远程机：

./jmeter.sh -n -t test.jmx -R 192.168.1.101:4000,192.168.1.102:4000 -l result.jtl

使用分布式压测时要注意：

• 所有 slave 的 jmeter 版本、JDK 版本必须一致。
• 测试计划中的 CSV 数据文件需要在每台 slave 上都存在，且路径一致。
• jtl 结果文件汇总到 master 端，报告由 master 生成。
• 分布式压测的网络开销和数据汇总可能会成为新的瓶颈，建议 master 和 slave 之间使用万兆内网。

7.4 接口监控与自定义脚本

如果你希望 JMeter 压测过程中把性能数据实时推送到 Grafana 或自建监控平台，可以使用后端监听器（Backend Listener），支持 InfluxDB、Graphite 等。

配置方式：右键测试计划 ->添加->监听器->后端监听器，实现类选择org.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClient，填入 InfluxDB 地址、数据库名称、测试名称即可。

这样，JMeter 每 5 秒会把响应时间、TPS、错误率等指标写入时序数据库，再通过 Grafana 配置仪表盘，就能实时观察压测进展，不再依赖命令行窗口的滚动输出。

8. 资源占用与性能观察

JMeter 压测过程中，资源占用是决定结果可信度的关键因素。如果压测机自身 CPU 被打满，TPS 数据就不真实。

8.1 压测机性能观察

压测机执行 4000 并发时，需要观察三类资源：

如果压测机 CPU 过高，优先检查：

• 是否用了 GUI 模式。GUI 模式必须立即停止，改用命令行。
• 是否添加了过多的监听器。聚合报告、View Results Tree 都建议只在调试时使用。
• 是否把jmeter.properties中的mode设置为Standard，而不是Stripped。Stripped 模式会减少采样数据量，降低资源消耗。

在bin/jmeter.properties中修改：

mode=Stripped

8.2 目标服务器性能观察

压测的目的是找出目标服务器的瓶颈。压测开始后，在目标服务器执行：

top vmstat 1 free -m iostat -x 1 sar -n DEV 1

重点看四个维度：

• CPU 使用率：us（用户态）持续超过 80% 说明应用层计算密集；sy（系统态）持续超过 30% 说明上下文切换频繁，线程数可能过大。
• 内存使用率：free 明显下降，swap 开始使用，说明内存不足。
• 磁盘 IO：await 持续超过 100ms 说明磁盘响应缓慢，可能是日志写入、数据库刷盘或慢查询导致。
• 网络带宽：received/sent 是否接近网卡上限，带宽打满也会导致响应时间上升。

如果应用是 Java 技术栈，还可以用jstat观察 GC 情况：

jstat -gcutil <pid> 1000 10

FGC和FGCT如果持续快速上涨，说明 JVM 堆内存压力过大，Full GC 频繁导致应用卡顿，这经常表现为"响应时间周期性尖刺"。

8.3 压测过程中的典型曲线

根据经验，压测过程中大概率会遇到下面几类曲线：

观察到这些特征后，要结合业务代码和中间件配置去定位，而不是只看一个数据。

9. 常见问题与排查方法

把高频问题整理成了一张排查表，下面这些大概率你会遇到。

9.1 证书与 HTTPS 问题

压测 HTTPS 接口时，JMeter 会提示未安装安全证书。JMeter 自带一个 Apache 证书，在 bin 目录下生成：

keytool -genkeypair -alias jmeter -keyalg RSA -validity 365 -keystore jmeter_keystore.jks

如果你压测的目标系统是自签名证书，需要在 JMeter 的 HTTP 请求中忽略证书校验，或者在jmeter.properties中配置：

server.rmi.ssl.disable=true

另一种更稳妥的方式，是把目标系统的 HTTPS 证书导入 JDK 的 cacerts 信任库：

keytool -import -alias example.com -keystore $JAVA_HOME/lib/security/cacerts -file example.crt

这里要注意，去操作生产系统证书前先确认权限，不要为了压测临时关闭证书校验，留下安全隐患。

10. JMeter 性能压测最佳实践

最后把 4000 并发压测过程中总结的经验整理成一套可复用的最佳实践。

10.1 脚本设计要点

• 先小并发调试脚本。100 并发跑通业务流程，确认登录、参数提取、断言都正常，再上 4000 并发。
• 使用属性控制并发参数。线程数、Ramp-Up、循环次数都用${__P()}读取，方便命令行动态传参，减少改 jmx 的次数。
• 分离不同接口的压测场景。登录压测、订单查询压测、全链路压测分别维护独立线程组，不要全堆在一个测试计划里。
• 使用 CSV 参数化真实数据。避免几十个线程用同一账号打到服务端缓存，导致测试结果失真。
• 开启事务控制器。如果压测多接口链路，使用事务控制器把登录 + 查询 + 下单的逻辑包成一个事务，统计用户在完整链路上的总耗时和成功率。

事务控制器配置示例：

Thread Group └── 事务控制器: 下单全链路 ├── HTTP 请求: 登录 ├── HTTP 请求: 创建订单 └── HTTP 请求: 订单支付

右键线程组 ->添加->逻辑控制器->事务控制器，勾选Generate parent sample，这样聚合报告和 HTML 报告都会把整个链路作为一个事务来统计。

10.2 压测过程控制

• 分阶段加压。不要直接用 4000 并发砸上去，而是按 100 -> 500 -> 1000 -> 2000 -> 4000 逐步增加，观察每个阶段的响应时间和错误率变化，找到性能拐点。
• 控制 Ramp-Up 时间。4000 线程建议 Ramp-Up 60 到 120 秒，避免瞬时冲击压垮系统，也避免压测机本身线程创建风暴。
• 设置合理的循环次数或持续时间。接口测试建议循环 100 次，稳定性测试建议按时间持续 30 分钟以上。
• 压测过程中观察实时日志。命令行模式下summary输出每 30 秒滚动一次，重点关注 Err 百分比。

10.3 数据管理

• 结果文件独立归档。每一轮压测的输出放到独立目录，命名带上日期、并发数、接口名，例如order_api_4000_20250601.jtl，方便后续追溯和对比。
• 保留 CSV 测试数据副本。压测结束后，把本轮使用的 users.csv 也备份一份，避免后续排查数据对不上。
• 报告生成后立刻归档。命令行生成的 HTML 报告占用空间不大，但对于多轮压测，建议只保留最终版本和对比报告，减少磁盘占用。

10.4 性能调优思路

4000 并发压测发现瓶颈后，调优顺序建议按照"成本从低到高"来：

1. JVM 参数调优：调整堆大小、GC 回收器、线程栈大小，成本最低。
2. 中间件参数调优：Tomcat 最大线程数、数据库连接池最大连接数、Redis 超时时间、MQ 消费者并发数。
3. 应用层代码优化：慢 SQL、循环调用、同步等待、锁竞争、日志强度。
4. 架构层面优化：加缓存、加异步、加队列、水平扩容、读写分离。

调优之后，用同一份压测脚本再跑一轮 4000 并发，对比调优前后的 TPS、响应时间、错误率，形成可量化的调优结论。

10.5 合规使用提醒

JMeter 本身是开源工具，它的功能边界很清楚：模拟协议请求、采集响应数据、生成统计报告。整个压测过程中，你有义务确保：

• 压测目标是你拥有或获得授权的系统。
• 压测数据不涉及真实用户的敏感信息。
• 压测过程不对外部公网未授权服务发起流量。
• 压测结果不用于恶意攻击或破坏他人系统。

尤其在测试环境复现和排查问题时，如果涉及外部服务，先确认服务提供方的测试条款和 API 调用限制。

11. 总结与下一步

JMeter 跑 4000 并发，核心不是点一下"开始"按钮那么简单。它考验的是测试脚本设计的合理性、压测机资源的管理、目标系统瓶颈的定位方式，以及事后对数据的解读能力。

这篇文章从 JMeter 安装部署、测试计划设计、CSV 参数化、JSON 提取、断言配置、命令行压测、分布式扩展、批量任务调度、资源监控、问题排查到最佳实践，完整覆盖了一次 4000 并发压测的各个阶段。如果你能完整跟做一遍，就会掌握一套通用的性能压测方法论，而不是只会"填线程数、看结果"。

建议收藏备用。下一步可以做三件事：

第一，把线程组参数改成 100 并发，先跑通登录 + 业务查询的完整链路，确保 JSON 提取器和响应断言的数据没问题。

第二，按照 100 -> 500 -> 1000 -> 2000 -> 4000 的梯度做一轮阶梯压测，记录每个并发梯度下的 TPS 和响应时间，画出性能曲线。

第三，用命令行模式生成 HTML 报告，把报告中的 APDEX、百分位响应时间、TPS 走势图和错误率趋势截图归档，作为这一轮压测的结论。

如果 4000 并发压测过程中发现系统提前劣化，优先检查数据库连接池、线程池和服务端 TCP 连接数，这三个位置是大多数性能瓶颈的高发区。之后想继续深入，可以研究 JMeter 分布式压测、InfluxDB + Grafana 的实时监控链路，以及结合业务代码做全链路压测分析。