企业官网建设流程全解析

做性能压测的人应该都遇到过这种情况：领导一句话“系统能扛住多少并发”，你打开 JMeter、调线程数、跑完看报告，发现聚合报告里错误率飘红、响应时间暴涨，然后开始猜是哪台机器扛不住了。这个主题最容易翻车的地方不是不会用 JMeter，而是把“并发数”理解错了。4000 并发在 JMeter 里不一定等于 4000 个线程，更不等于 4000 个用户同时点击。如果你正打算压一个真实业务系统，想搞明白 4000 并发到底该怎么设计场景、怎么配置线程组、怎么判断瓶颈在哪，这篇文章可以帮你少走弯路。

我会按实际压测的推进顺序来写：先说什么叫 4000 并发、需要什么样的资源和前置条件；再讲 JMeter 压力机本身怎么配置才不会被自己压垮；然后从脚本设计、参数化、断言到监听器，一步步说清楚；最后落到结果分析和瓶颈定位，包括怎么为二次压测做基础。

这不是照着官方文档念一遍，而是按照我实际压测时踩过的坑来写。你可能会发现，真正跑到 4000 并发之前，最先挂掉的往往不是被测系统，而是 JMeter 所在的压力机。

1. 4000 并发到底意味着什么：先搞清楚需求再动手

很多人在压测准备阶段犯的第一个错误，就是把“4000 并发”直接映射成“JMeter 线程数设为 4000”。这个理解如果不纠正，后面所有配置和判断都会偏。我先把这个概念捋清楚。

1.1 并发数、线程数、在线用户数不是一回事

在 JMeter 里，一个线程代表一个虚拟用户。线程启动后，会按照你配置的脚本循环执行请求。如果你设置了 4000 个线程，且每个线程不等待、持续发请求，那 JMeter 压力机瞬间产生的请求量会非常大。这个叫“严格并发”或“瞬时并发”，通常用于测试系统能承受的极限压力。

但真实业务里，4000 个用户在线，不等于 4000 个请求同时打到服务器。如果一个用户的操作频率是每 10 秒发一个请求，4000 个在线用户平均每秒也就是几百个请求。区别非常大。

所以看到“4000 并发”这个需求时，第一件事不是打开 JMeter，而是反问清楚：这个 4000 是同一时刻活跃请求数，是系统在线用户数，还是你领导随口说的一个目标值。如果需求本身模糊，建议先从业务角度拆一下，比如注册登录这类高并发操作的峰值 QPS、每秒请求数大概是多大，再换算成 JMeter 合适的线程数。

另外还要考虑业务模型。压测通常不是单个接口压，而是按照真实用户比例分配流量。比如一个电商下单流程，浏览商品、加购物车、下单、支付的调用比例可能是 60%、20%、15%、5%。如果 4000 个虚拟用户全部只打下单接口，那不是性能压测，是单接口打满测试，结果对容量规划参考意义有限。

1.2 4000 并发属于什么量级：普通项目和中大型项目的分水岭

从压测经验来看，4000 并发已经不低了。很多中小型业务的峰值并发在几百到两千左右，能稳定扛住 4000 并发的系统，在架构上通常已经做了负载均衡、缓存、读写分离、异步削峰等设计。如果你负责的是一个单体应用，数据库和业务逻辑都在一台机器上，那 4000 并发大概率会把系统打穿。

所以当目标定成 4000 并发时，压测本身要分阶段推进：

• 第一阶段：先跑 200 并发，验证脚本正确性和链路连通性。
• 第二阶段：500 并发，观察响应时间、错误率、CPU、内存。
• 第三阶段：1000 并发，看曲线有没有明显拐点。
• 第四阶段：逐步升到 2000、3000、4000，找到拐点位置。

不要一把梭直接上 4000。这个习惯必须养成，因为你不知道压力机、网络、下游中间件到底哪一个先扛不住，分阶段才能定位问题。

注意：4000 并发是目标，不是起点。任何性能压测都应该从小并发开始，逐步逼近目标，过程中记录每一步的响应时间、吞吐量和错误率。

2. 跑 4000 并发之前，先把压测环境和 JMeter 本身搞定

这一步最容易被忽略。很多人的 JMeter 跑 300 并发都很流畅，一到 1000 以上就报连接超时、内存溢出、无法分配线程，甚至压力机直接卡死。这不是被测系统的问题，是压测端没准备好。

2.1 压力机的硬件要求：别用办公笔记本压 4000 并发

JMeter 本身是 Java 应用，每个线程都会占用一定的 CPU 和内存。特别是脚本里有 JSON 提取器、正则表达式、断言时，CPU 消耗会成倍增长。

如果你想在本机跑 4000 线程，建议尽量不要用日常办公的笔记本。原因有两个：

• 笔记本的 CPU 主频和散热不足以支撑大量线程轮转，容易导致线程调度延迟，压测结果失真。
• JMeter 的 GUI 模式本身就会消耗资源，用 GUI 跑高并发几乎一定会遇到瓶颈。

我比较推荐的做法是：单独准备一台压测机，最低配置 8 核 CPU、16GB 内存起步，如果是 4000 并发这种量级，建议 16 核 CPU、32GB 内存，并确保压力机和被测服务器之间网络带宽充足。如果你是公司环境，最好让压力机与被测系统在同一个内网，避免公网延迟和带宽抖动影响数据。

如果你只有普通电脑，也不是不能试，但需要降低预期：

• 减少线程数，比如 4000 并发任务拆成 4 台压力机，每台跑 1000 线程。
• 关闭 GUI，使用命令行模式运行。
• 减少不必要的监听器、断言和日志输出。

2.2 JMeter 内存配置：默认堆内存根本撑不起 4000 线程

JMeter 默认的内存上限是 1GB 或 2GB，取决于安装版本和启动脚本。这个配置跑两三并发练手没有问题，跑到 4000 线程时很容易出现 OutOfMemoryError，因为每个线程栈、采样结果、响应数据都会占用 JVM 堆内存。

修改方式也很简单，找到 JMeter 安装目录下的bin目录，编辑jmeter.bat（Windows）或jmeter.sh（Linux/macOS）文件，调整HEAP参数。例如：

# Windows 下的 jmeter.bat set HEAP=-Xms4g -Xmx8g -XX:MaxMetaspaceSize=2g

# Linux/macOS 下的 jmeter.sh HEAP="-Xms4g -Xmx8g -XX:MaxMetaspaceSize=2g"

这里给的是参考值，不是唯一标准。如果你本机内存只有 16GB，压测机的 JMeter 堆内存设置成 8GB，加上操作系统开销，整体是可控的。如果设置成 12GB 甚至更高，反而可能导致系统自身内存不足，触发频繁垃圾回收。

修改完 JVM 参数后，建议启动 JMeter 时确认参数是否生效。最直接的方式是在 GUI 界面打开“帮助 -> 关于”，查看内存信息，或者在命令行模式看启动日志里的 JVM 参数。

2.3 使用命令行模式跑压测：高并发必须放弃 GUI

JMeter 的 GUI 模式适合编写和调试脚本，不适合执行高并发压测。原因很简单：GUI 界面需要实时渲染曲线、表格和日志，这个渲染过程会消耗大量 CPU 和内存。你可能会发现，跑到 2000 并发时，JMeter 界面已经卡得不成样子，但被测系统其实还很正常。

正确做法是：

1. 先在 GUI 模式里调试脚本，用 2 到 5 个线程验证请求是否正确。
2. 保存脚本为.jmx文件。
3. 关闭 GUI，使用命令行模式执行压测。

命令行执行示例：

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

参数解释：

• -n：非 GUI 模式。
• -t：指定 JMX 脚本路径。
• -l：保存原始采样结果的 JTL 文件路径。
• -e：测试结束后生成 HTML 报告。
• -o：HTML 报告的输出目录，目录必须为空或不存在。

跑 4000 并发时，建议把 JTL 文件的输出路径放到机械硬盘或固态硬盘空间充足的位置，因为高并发下会产生大量采样数据，每秒可能几十 MB。如果磁盘速度不够，JMeter 会因写入阻塞而影响压测线程，导致结果不准确。

注意：命令行模式跑压测时，不要同时打开 JTL 文件去实时查看，否则会占用文件句柄并拖慢性能。

3. 设计 4000 并发测试计划：从业务链路到 JMeter 配置

当压测平台和环境准备完毕，接下来要解决的核心问题就是“测试计划怎么设计”。这一步直接决定了压测结果是否可信。我见过太多人写 JMeter 脚本时只关心 HTTP 请求路径，却忽略了参数关联、断言、数据隔离和结果采集，最后跑完报告一堆错误，根本不知道是系统问题还是脚本问题。

3.1 测试计划的组成：线程组、HTTP 请求、参数化、断言、监听器

一个标准 JMeter 压测测试计划，通常包含这几个核心元素：

• 线程组
• HTTP 请求采样器（包括请求头、请求体）
• 配置元件（HTTP 请求默认值、HTTP 信息头管理器、用户自定义变量）
• 前置处理器（用于参数化，如用户参数、JDBC 预取）
• 后置处理器（用于提取响应结果，如 JSON Extractor）
• 断言（响应断言、JSON 断言）
• 监听器（聚合报告、汇总报告、简单数据写入器）

如果是压测一个登录后查询用户信息的接口，流程大致是：

登录接口 -> 提取 Token -> 使用 Token 查询用户信息 -> 断言返回结果

设计时要注意，登录接口一般不直接压 4000 并发，因为登录本身涉及密码加密、验证码、会话创建等复杂逻辑，会导致压力集中到单个服务。更合理的做法是：单独压登录、单独压查询，或者按业务比例混合压测。

3.2 线程组参数配置：如何用 4000 线程模拟目标并发

线程组里有几个参数非常关键：

• 线程数：虚拟用户数。
• Ramp-Up 时间：在多长时间内启动全部线程。
• 循环次数：每个线程执行几次请求，配置为“永远”时通常搭配调度器使用。
• 调度器：持续时间、启动延迟等。

如果你用 4000 线程模拟 4000 并发，Ramp-Up 时间建议不要设成 0。设成 0 意味着所有线程在同一瞬间启动，瞬间请求量会特别猛，容易把被测系统直接打挂，而且很难判断系统是正常崩溃还是异常崩溃。

我一般这样设置：

• 目标并发 4000 线程。
• Ramp-Up 时间设为 60 到 120 秒，让线程逐步启动，观察系统在渐进压力下的表现。
• 持续运行时间设为 15 到 30 分钟，观察长时间运行下是否存在内存泄漏、连接池耗尽等问题。
• 循环次数勾选“永远”，让线程持续发送请求直到运行时间结束。

如果你的业务模型是“4000 个用户每人只操作一次”，那可以把循环次数设为 1；如果你要测试的是持续高负载下的稳定性，则需要循环运行一段时间。

3.3 参数化与数据隔离：4000 并发不能所有用户都用一个账号

这是压测中最容易“假通过”的一个原因。假设你要压测一个查询接口，JMeter 脚本里写死了用户 ID，4000 个线程全部查询同一条数据。这时候 Redis 缓存命中率可能特别高，数据库压力很小，系统响应也确实很快。但压测结果不能代表真实业务。

更好的做法是使用 CSV 数据文件，准备一批测试账号数据，让每个虚拟用户使用不同的账号、手机号、订单号。以登录接口为例，你可以准备一个users.csv文件：

username,password user001,pwd123456 user002,pwd123456 user003,pwd123456

然后在 JMeter 里添加“CSV 数据文件配置”，设置：

• 文件名：/path/to/users.csv
• 变量名称：username,password
• 是否允许多线程共享：可以设为“否”，让每个线程取不同行数据。

这样 4000 个虚拟用户会遍历 CSV 文件中的账号，更接近真实用户分布。如果账号数量不够 4000，可以让循环策略设置为“遇到文件末尾自动重新读取”，但要注意复用相同账号可能触发重复登录踢出或会话冲突，最好准备足够多的测试数据。

除了账号、密码、订单号等业务数据，压测过程中还往往需要处理动态数据关联。例如登录后会返回一个 Token 或 SessionID，后续查询接口需要带上这个动态值。JMeter 里可以用“JSON 提取器”或“正则表达式提取器”从登录响应中提取 Token，然后通过${token}变量传入后续请求。这一步如果没做对，4000 并发跑出来可能满屏 401、403 或 500，但这些问题不是系统扛不住，而是脚本没关联好。

3.4 断言要精确：别把错误判断成成功

压测时加断言的目的，是确保请求真的成功，而不是只看 HTTP 状态码。很多接口在异常时会返回 HTTP 200，但响应体里是一个错误码或错误消息。比如登录接口返回 200，但业务码是 50001，表示密码错误。如果你只按 HTTP 状态码判断成功，这类请求会被当作成功请求统计进报告，严重误导结果。

常用的做法是添加“响应断言”，检查响应体里是否包含某个业务成功标识。例如：

• 检查字段：响应文本
• 匹配规则：包含
• 测试模式："code":0或"success":true

这样断言失败后，JMeter 会将该请求标记为失败，聚合报告中的错误率才具备参考价值。

需要提醒的是，断言也不是越多越好。如果你对每个 JSON 字段都做断言，JMeter 处理响应体的时间会显著增加，导致压测机自身成为瓶颈。我的经验是：断言只做关键的，比如业务成功码、结果非空、响应代码。

3.5 监听器：压测过程看哪些数据，压测结束看哪些数据

GUI 模式调试时，可以加“查看结果树”来观察请求和响应内容，但这货在高并发下绝对不能开。它会保存每个请求的完整响应体，4000 并发跑几分钟，内存必爆。

真正跑 4000 并发时，建议监听器保持最简配置：

• 添加“简单数据写入器”，把采样结果写入 JTL 文件。
• 压测结束后，用“聚合报告”或“汇总报告”打开 JTL 文件，离线分析。
• 需要在压测过程中实时观察的话，可以用命令行模式加-e -o参数，跑完后生成 HTML 报告，或者配合 Grafana + Prometheus + JMeter Exporter 做实时监控。

如果你必须实时看聚合数据，也不要长时间盯着 GUI。可以每隔一段时间手动刷新，或者用第三方监控工具查看 JTL 文件。

注意：压测过程中永远不要开“查看结果树”。这个元件是编完脚本用来调试的，不是用来跑性能的。

4. 4000 并发下的常见报错与排查流程

跑到高并发时，JMeter 会报各种各样的错误。看到报错先别慌，也不要第一时间怀疑被测系统，按顺序排查。

4.1 连接超时、Socket 异常、Connection Reset：先判断是压力机还是被测系统

这些报错非常常见，但原因可能截然不同：

• 如果错误率在低并发时是 0%，随着并发升高才开始出现，多半是被测系统的连接池、数据库连接池或处理线程池被占满。
• 如果错误率从低并发就有，且压力机 CPU、内存非常高，可能是压测机线程数配置超过资源上限，线程调度不过来导致请求发送延迟或失败。
• 如果错误集中发生在某个节点之后，比如 3000 并发附近，可能是被测系统某个中间件达到瓶颈，比如 Nginx 的 worker_connections 不够，或者 Redis 连接数触顶。

排查时建议先看被测系统监控，比如 CPU、内存、磁盘、进程数、网络连接数、数据库活跃连接数。如果这些指标都没有到极限，再看压力机。很多人一上来就改 JMeter 超时时间，结果超时从 3 秒改成 30 秒，错误确实消失了，但这不是系统性能变好，而是掩盖了真实瓶颈。

4.2 内存溢出、无法创建线程：压力机资源不足

错误信息如果包含OutOfMemoryError、unable to create native thread，说明压力机自身资源不足。处理方式：

• 增大 JMeter JVM 堆内存，但不要超过物理内存的一半。
• 减少监听器和日志输出。
• 降低线程数，改用分布式压测，让多台压力机分担负载。

4.3 响应时间逐渐变长：先看 GC 和连接池

当并发数越来越高，响应时间呈线性或指数上升时，通常不是网络抖动，而是某个资源被耗尽。常见情况：

• Java 应用发生频繁 Full GC，应用线程停滞。
• 数据库慢查询逐渐增多。
• 连接池等待时间拉长。
• 线程池队列堆积，任务排队。

这种问题在聚合报告上表现很明显：最小响应时间正常，平均响应时间一般，90% 响应时间高，最大响应时间特别高。这说明系统有少数请求被长时间阻塞，大概率是排队等待资源。

4.4 错误信息“NoHttpResponseException”：HTTP 连接被服务端关闭

这是一个非常经典的报错。服务端在连接空闲一段时间后主动关闭了 keep-alive 连接，但 JMeter 客户端仍然尝试使用该连接发送请求，服务端已经关闭，于是报错。

排查思路：

• 查看被测系统的 HTTP 连接超时配置。
• 检查 JMeter 超时时间设置。
• 如果只是少量出现，且系统吞吐量正常，可以不处理；如果错误率持续上升，需要调整服务端 keep-alive 超时时间或客户端连接复用策略。

在压测脚本里，可以通过 HTTP 请求默认值配置连接超时和响应超时：

• 连接超时：3000 毫秒
• 响应超时：30000 毫秒

但要记住，这只是客户端的请求等待时间，不是被测系统的性能指标。系统处理需要 2 秒，你把超时改成 200 毫秒，那错误率假高；系统处理需要 1 秒，你把超时改成 30 秒，那错误率假低。

5. 从 4000 并发结果中找出系统瓶颈

压测跑完之后，最核心的工作不是报告截图发了就完事，而是通过报告判断系统还有多少余量、瓶颈在哪里、是否需要优化。我一般会先看结果趋势曲线，再看聚合报告，最后结合监控数据做综合定位。

5.1 聚合报告怎么看：错误率、吞吐量、响应时间、分位数

聚合报告里几个指标要重点关注：

看报告时，我一般先看 Error% 和 90% Line。如果 Error% 接近 0，90% Line 在业务可接受范围内，基本可以判断系统在当前并发下是稳定的。如果 Error% 超过 1%，需要优先排查错误原因；如果 90% Line 已经超过 3000 毫秒，说明多数用户已经开始感知到卡顿。

5.2 判断系统瓶颈的三种常见模式

第一种：错误率随并发升高而快速上升，同时吞吐量下降。这种情况通常是被测系统某个资源耗尽，比如数据库连接池打满、线程池拒绝任务、Redis 连接数触顶。系统有保护机制，但效果是阻挡了多余请求。

第二种：响应时间缓慢上升，错误率不高，但吞吐量趋于平稳。说明系统已经接近处理上限，每个请求都需要排队，但队列还没满，所以不报错。这种情况下系统处于亚健康状态，随时可能在高压下崩溃。

第三种：吞吐量随并发先上升后下降，呈明显倒 V 形。说明系统在某个并发点之后，线程调度和上下文切换消耗开始超过并发带来的收益，性能开始下降。这个拐点就是系统的推荐并发上限。

5.3 结合系统监控定位瓶颈

JMeter 报告只能说明系统“表现得怎么样”，不能告诉你“哪一层出了问题”。要定位瓶颈，必须结合被测系统的监控数据。

需要关注的指标：

• 应用服务器：CPU 使用率、内存使用率、GC 频率与停顿时间、活跃线程数、连接池使用率。
• 数据库：CPU、活跃会话数、慢查询数量、连接数和锁等待。
• 中间件：Nginx 的连接数、请求队列长度，Redis 的内存、命中率、连接数。
• 网络：带宽占用、TCP 重传率、连接数。

如果应用服务器 CPU 达到 90% 以上且 GC 频繁，优先检查应用代码和 GC 参数。如果数据库慢查询数量在并发升高后急剧增加，需要检查 SQL 索引和执行计划。如果是连接数被占满，需要检查连接池大小和释放逻辑。

我曾经遇到过一个很典型的案例：4000 并发下错误率飙升，但应用服务器 CPU 和内存都很正常，最后定位到是数据库连接池最大连接数设成了 100，而压测线程数 4000，导致大量线程在等待数据库连接。这个问题的根源不是应用处理不了，而是连接池配置严重不足。

5.4 二次压测：每次压测前要保证环境一致

性能压测最怕环境不干净。如果你第一次压测结束之后，服务器上还残留大量日志文件、进程连接、临时文件，第二次压测结果就会和第一次差很多。所以在正式压测和二次压测前，建议做这几件事：

• 停止被测系统的非必要服务。
• 清理旧的日志文件，或让日志输出不写到高并发生路径。
• 重启被测系统，让内存和线程池回到初始状态。
• 确认压测机资源没有被其他任务占用。
• 关闭本机自动更新、杀毒软件等可能干扰性能的程序。

做过一轮压测之后，如果你的优化动作是改代码、改 SQL、改连接池，那么二次压测必须保证参数只变一个维度，才能判断优化是否有效。如果同时改了线程池大小、数据库 SQL、Redis 缓存，结果变好了也不知道是哪一步起的作用。

6. 从 4000 并发到批量压测：脚本管理和结果归档

如果只是一个接口，跑一次 4000 并发，那脚本随便写写也可以。但实际工作中，压测往往要反复执行，比如回归测试、版本对比、容量规划，这时候脚本管理和结果归档就显得特别重要。

6.1 一个 JMeter 脚本如何做到可复现

我见过很多同学手里的 JMeter 脚本只有自己能看懂，换台电脑就跑不起来。路径写死、变量没有统一管理、断言随意写，这都会影响复现。建议从一开始就做基础规范：

• 所有服务器地址、端口、协议统一放在“用户自定义变量”元件里，不写死在请求路径中。
• 测试数据文件路径使用相对路径，或者通过命令行参数传入。
• CSV 文件尽量和 JMX 文件放在同一目录下，避免换机器后路径失效。
• 线程数、并发目标、持续时间也用变量代替，方便命令行执行时覆写。

JMeter 支持使用-J参数传递变量，例如：

jmeter -n -t test.jmx -Jthreads=4000 -Jduration=600

脚本里将线程数写成${__P(threads,100)}，将持续时间写成${__P(duration,300)}，这样同一个脚本既可以跑 100 并发，也可以跑 4000 并发，不改文件内容。

6.2 结果归档的三个要素：JMX、JTL、HTML 报告

压测完成之后，不要只发一张截图。性能压测最重要的价值是“历史可比性”。如果这个月压测 4000 并发通过，下个月系统架构升级后同样压 4000 并发，对比两次报告就能知道升级是变好还是变差。

所以每次压测至少保存三样东西：

• JMX 脚本文件，记录压测场景。
• JTL 原始结果文件，记录所有采样数据。
• HTML 报告目录，方便直接查看图表。

另外建议在报告目录里加一个README.md或环境说明.txt，记录压测时间、构建版本、服务器配置、数据库配置、优化动作。这些信息在后续复盘时很关键，否则一个月后你看着报告已经忘了当时测的是什么环境。

6.3 压测中常见的“看起来很高端但实际没用”的做法

再补充几个我比较反对的压测习惯：

第一个，为了压测数据好看，把 Ramp-Up 时间改成 0。这样能测出瞬时极限，但得到的响应时间曲线基本都是直线飙升，对容量规划没有实际参考意义。

第二个，压测启动瞬间就把 4000 线程全部发出去，导致错误率很高，然后把责任归结为系统不行。真实业务中用户请求是逐渐增加的，不是瞬间涌入。

第三个，压测过程中没有任何监控数据，只凭 JMeter 聚合报告就下结论。聚合报告告诉你系统快慢，但不会告诉你快在哪、慢在哪、为什么慢。

第四个，为了压出更好的数据，在 JMeter 脚本里大量使用 CSV 数据随机取值，但每个请求都命中缓存。虽然看起来吞吐量很高，但真实场景中缓存命中率不一定这么高，结果不具备可参考性。

7. 4000 并发压测落地前，最后再检查这几件事

写到这里，基本从环境、配置、脚本、执行、分析、归档都说了一遍。最后再按照我自己的习惯，列一个压测前的最终检查清单。你不用全盘照抄，但可以根据自己的项目调整。

• 是否明确 4000 并发的业务含义：瞬时并发、在线用户数、目标 QPS？
• 压力机硬件是否足够：CPU 核数、内存、磁盘读写能力。
• JMeter JVM 堆内存是否已调大。
• 是否使用命令行模式跑高并发。
• 测试数据是否足够，并已做参数化。
• 动态数据关联是否正确，Token、SessionID 是否提取成功。
• 断言是否准确，能否区分业务成功和业务失败。
• 是否关闭不必要的监听器和日志输出。
• 线程数、Ramp-Up、持续时间是否符合业务场景。
• 压测前是否重启被测服务并清理环境。
• 是否有应用服务器、数据库、中间件的监控方案。
• 压测报告和原始结果是否约定好归档位置。

这些问题里，最容易被忽略的是第一项和最后一项。概念没理清楚，压测结果就会偏差；结果没有归档，压测价值就会减半。

如果你是第一次尝试高并发压测，我更建议不要把第一次目标定成 4000。先从 500 并发跑起来，看压力机表现、看被测系统监控、看 JMeter 的 GC 和内存占用，跑通流程后再往上提。一次跑成不代表方案成熟，多次稳定复现才是真正压测能力的体现。

当你真的把 4000 并发跑完，并且能从报告中讲清楚“系统在什么并发下开始拐弯、瓶颈出现在哪一层、优化后能得到什么改善”时，这个项目带给你的价值就远超一个简单的压测报告了。