企业官网建设流程全解析

做了这么多年性能压测，Apache Jmeter在我手里至少用了上千个小时，一直有个体会：压测工具本身只是用来制造压力的，真正能回答“系统到底行不行”的，是压力过程中被压机器的CPU、内存、磁盘、网络这四类指标。很多新人一上来就盯着Jmeter聚合报告里的吞吐量和响应时间，跑完一轮数据挺漂亮，可一旦问起服务端资源占用，或者系统瓶颈到底在哪，就答不上来了。这就是典型的“只会压、不会测”。

这篇文章我会从一个完整的Apache Jmeter压力测试实践出发，从方案设计、环境准备、脚本编写到执行压测，再到CPU、内存、磁盘、网络的性能监控，一条线全部串起来。不管你是在Windows上刚装好Jmeter，还是已经在写接口压力测试脚本，这篇内容都能给你一套可以直接照着做的思路和方法。最后还会整理我在实际项目里踩过的坑，看完起码能帮你避开大半。

1. 压力测试方案：先搞清楚要压什么、压到多少算通过

1.1 压测目标与场景建模：QPS目标从哪来

很多人做压力测试，上来就打开Jmeter，线程组随便填个100、200，跑起来就算完事了。这样压出来的结果没有任何说服力。真正专业的做法，是先想清楚两个问题：第一，这个接口平时有多少流量；第二，我们要压到的目标值是多少。

先拿一个最常见的接口来举例：订单查询接口。假设线上统计过，这个接口日均调用量是3000万次，而且流量并不是平均分布的，白天8小时占了全天流量的绝大部分。那么高峰时段的平均QPS大概是：

QPS = 日请求量 / 高峰秒数 = 30000000 / (8 * 3600) ≈ 1041

再乘一个高峰波动系数，按常见经验取2~3倍，那这个接口的压测目标TPS可以定在2000~3000左右。这只是单接口的一个粗略估法，如果是整条链路压测，还需要把下游数据库、缓存、第三方依赖的容量一起考虑进去。

定了目标之后，才轮到场景建模。压测场景一般分三类：单接口基准压测、混合场景压测、峰值稳定性压测。单接口压测用来摸清单个服务的处理上限；混合场景模拟真实用户操作的比例，比如订单查询60%、下单20%、支付20%；峰值稳定性压测则是在最高并发下连续跑20~30分钟，用来发现内存泄漏、连接池耗尽这类长时间才会暴露的问题。“压力测试怎么测”从来不是玄学，按这三个场景分别设计才能把问题看透。

1.2 压测方案要考虑的三件事：数据、环境和隔离

定好目标之后，还要在方案里把数据、环境和隔离这三件事安排明白，否则压测结果是不可信的。

第一件事是测试数据。压测最怕的一件事，就是用几条数据反复请求，结果数据库缓存全被命中，响应时间好看得离谱，但一上真实环境立刻现原形。正确做法是准备一批与线上数据量级接近的测试数据，通过CSV参数化或从数据库读取，让请求尽可能分散落到不同主键上。还有一个常被忽略的点：测试数据的分布要贴近真实，比如订单状态有已完成、待支付、已取消，比例也要模拟线上。

第二件事是测试环境。压测机最好和被压服务分开部署，不要让压测工具和被测服务抢同一台机器的CPU和内存。如果必须在测试环境压，也要确保这个环境没有被其他团队共用，不然资源监控数据会混入大量噪声。

第三件事是变更控制。每次压测前，记录下被测服务的版本、JVM参数、数据库连接池配置、Nginx配置。压测中发现瓶颈之后，调优时只改一个变量，复测一次，这样定位问题和归因才清晰。

1.3 为什么选Jmeter而不选其他压测工具

市面上能做压力测试的工具不少，ab、wrk、Locust、LoadRunner都有各自的场景。我大部分项目还是优先用Apache Jmeter，不是因为它最强，而是因为它在“功能全面”和“上手门槛”之间平衡得最好。

对大多数Web接口和业务系统来说，Jmeter的HTTP取样器完全够用；遇到需要连数据库做压测的，直接用JDBC请求；需要模拟复杂业务链路时，有IF控制器、循环控制器、随机控制器这些逻辑组件可以组合。最关键的一点是，Jmeter配合PerfMon插件可以做到压测和监控在同一套工具里完成，后面我会详细讲这个方案。

2. 环境准备与Jmeter安装配置

2.1 Windows环境安装JDK与Jmeter

先说Windows下怎么装。Jmeter依赖Java运行环境，所以第一步是装JDK。Jmeter 5.x版本建议用JDK 8以上，JDK 11或者JDK 17都行。安装JDK时记住安装路径，装完后配置环境变量：新建JAVA_HOME，值是JDK的安装目录，比如C:\Program Files\Java\jdk-17；再把%JAVA_HOME%\bin加到Path变量里。

配置完可以在命令行执行下面这段验证：

java -version

能看到Java版本号就说明环境没问题。接下来去Apache官网下载Jmeter的zip包，选最新的二进制版本，比如apache-jmeter-5.6.x.zip。下载后解压，这里有个很实用的建议：解压路径不要带中文和空格，否则后面执行脚本时可能出现莫名其妙的路径问题。我一般习惯解压到D:\tools\apache-jmeter-5.6这样的纯英文目录。

进入解压目录的bin文件夹，双击启动jmeter.bat。如果双击后没反应或者闪退，先不要急着重装，大概率是JAVA_HOME没配好，或者JDK位数和Jmeter不匹配。64位系统装32位JDK也会导致启动异常。在命令行手动执行一次jmeter.bat，看到报错信息再针对性处理，这是排查启动问题最快的方式。

2.2 启动Jmeter前的几个关键配置

Jmeter默认启动参数比较保守，脚本复杂或压测机本身配置不差时，建议先调整一下JVM堆内存。打开bin目录下的jmeter.bat，找到这段配置：

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

想省事可以直接改成set HEAP=-Xms2g -Xmx4g，但要注意这个内存是给Jmeter自身用的，开太大了会挤压压测机上的其他程序，反而影响压测效果。我习惯的配置是压测机内存8G时给Jmeter分2~4G，16G内存时给4~6G。

另外要养成一个好习惯：Jmeter的GUI模式只用来开发和调试脚本，真正跑压力测试一定用命令行模式。原因很简单，GUI模式本身就会消耗CPU和内存，尤其开多个监听器时，压测结果会被本机性能严重影响。在线程数超过50的场景，我见过不少人在GUI里跑压测，结果压测机自己先卡死的案例。

命令行执行压测的标准姿势是这样：

jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir

简单解释一下：-n代表非GUI模式，-t指定测试计划文件，-l指定原始结果文件路径，-e -o在压测结束后自动生成HTML报告到指定目录。后面案例部分我会再演示一次。

2.3 准备被压接口和测试数据

环境装好之后，不要急着写脚本。先把被压接口的信息整理清楚，包括接口地址、请求方法、请求头、参数格式、是否带Token鉴权。以订单查询接口为例，它可能是这样的：

GET http://your-server/api/order/query/{orderId} Header: Authorization: Bearer <token>

接口如果有鉴权，需要在压测脚本里处理Token获取。常见做法有两种：一是先用一个登录请求获取Token，再用JSON提取器提取出来，设置成全局变量供后续请求使用；二是直接从测试环境拿到一个长期有效的Token，放进HTTP信息头管理器里。前者更接近真实场景，后者胜在简单稳定。我自己做压力测试时，如果目标是测接口性能而不是测登录链路，会用第二种方案，避免登录鉴权成为瓶颈干扰判断。

测试数据也要提前准备好。订单ID不能只有一两条，否则数据库缓存命中率过高，压出来的数据不真实。我会预先在数据库里造一批订单数据，比如10万条状态各异的订单，导出成CSV文件作为参数化数据源。

3. 核心实操：用Jmeter编写并执行接口压力测试脚本

3.1 按这个步骤创建一个HTTP接口压测计划

打开Jmeter GUI后，左侧默认有一个“Test Plan”。右键点击它，添加线程组，然后在线程组上右键依次添加：HTTP请求采样器、HTTP信息头管理器、响应断言、聚合报告。这是最基础的一组配置。

点开HTTP请求采样器，需要填的内容包括：协议（http或https）、服务器名称或IP、端口号、请求方法、请求路径。如果接口是GET http://your-server/api/order/query/1001，就填服务器名your-server，路径/api/order/query/1001。实际压测时订单号不能写死，这里先留个占位符，后面参数化再替换。

HTTP信息头管理器里加一行请求头：Authorization: Bearer ${token}。这里的${token}是一个变量，后面可以通过CSV数据文件或者在脚本里定义的变量来赋值。

响应断言的作用是判断请求是否真的成功。比如接口设计为业务失败时返回{"code":500}，那就在响应断言里添加一个“响应文本”断言，模式匹配"code":200。这样即使HTTP状态码是200，业务失败也会被统计为错误，结果更真实。

3.2 线程组参数怎么设：并发数、Ramp-Up、循环次数

线程组是压测的“总开关”，这里有三个核心参数：线程数、Ramp-Up Period、循环次数。

线程数代表并发用户数。第一次摸底压测时不要一上来就500并发，我习惯从50开始，逐步往上加。Ramp-Up Period是线程启动耗时，比如线程数100、Ramp-Up填10，意思是10秒内启动完100个线程，相当于每秒增加10个并发。这个值设得太小会导致启动瞬间压力突刺，设得太大则压力曲线过于平缓，都偏离真实情况。

循环次数可以填具体数字，也可以勾选“永远”，然后通过调度器来限制压测时长。比较推荐用调度器方案：勾选调度器，填持续时间，比如600秒，这样每个线程会持续循环发送请求，直到压测时间结束。对接口压力测试来说，持续压测模式比固定循环次数更接近真实流量的形态。

梯队加压是我每次压测必用的手法。比如计划分别压50、100、200三个档位，我会准备三套线程组参数，或者直接用Jmeter的Stepping Thread Group插件实现自动阶梯加压。第一轮50并发跑5分钟，记录各项数据；第二轮100并发；第三轮200并发。每一轮结束都看一眼聚合报告和服务端监控，确认没有异常再继续加压，这样找到的瓶颈点才是可信的。

3.3 参数化、关联和断言：脚本不是写出来就能跑的

很多新手写Jmeter脚本，喜欢把请求参数写死。订单ID固定是1001，用户ID固定是001，跑下来的结果又稳定又好看，可这个数据根本不能说明系统真实的性能水平。参数化的意义，就是让每一次请求都带上不同的数据，尽量模拟真实用户的行为。

最常用的参数化方式是CSV数据文件。准备一个order_ids.csv文件，里面每一行是一个订单号：

1001 1002 1003 ...

在线程组上右键添加“配置元件 -> CSV数据文件设置”，填写CSV文件路径，变量名称填orderId，然后HTTP请求路径改成/api/order/query/${orderId}即可。

关联在接口压测里也非常常用。比如登录接口返回一个Token，后面下单、查询接口都要带这个Token。很多人不知道怎么处理，直接用固定Token顶替。正确做法是在登录请求上添加JSON提取器，配置一个变量名token，JSON路径表达式填$.data.token，再把HTTP信息头管理器里的Authorization设置为Bearer ${token}。这样每次压测都走真实的登录过程，Token会动态获取。

断言方面，响应断言是最基础的，更实用的是“持续时间断言”。比如接口要求P95响应时间低于500毫秒，那就添加一个持续时间断言，设置最大持续时间为500ms。这样凡是超过500ms的请求都会被标记为失败，压测过程中就能实时看到有多少请求不达标。

3.4 加思考时间：压测数据真实性的一个关键细节

真实用户不会像机器一样每秒钟不间断地疯狂点击接口，他们看完一个页面再操作下一个，中间总会有一个思考间隔。如果完全不加间隔，压出来的是“极限压力”而不是“真实压力”。

在脚本中可以通过添加“Constant Timer”（固定定时器）来实现思考时间。通常我会设置在1000~3000毫秒之间，具体值取决于业务场景：简单的按钮点击间隔可以短一些，复杂页面浏览间隔要长一些。

但这里有一个细节：如果做的是容量摸底压测，找系统极限，那要不要加思考时间其实影响不大，因为我们要测的是系统最多能扛多少QPS；如果做的是模拟线上流量压测，那就建议加上，否则结果会偏高。我在方案设计时会把两种场景分开，避免混在一起说不清楚。

4. 性能监控：CPU、内存、磁盘、网络一个都不能少

4.1 为什么压测过程必须同步监控服务端资源

只看Jmeter的响应时间和吞吐量，做不了瓶颈定位。举个例子：压测到200并发时响应时间从50ms涨到2000ms，原因可能是服务端CPU被打满了，也可能数据库连接池耗尽，也可能是网络带宽到了上限。这三种情况处理方式完全不同，不把CPU、内存、磁盘、网络的数据拉出来对比，就只能靠猜。

再加上一个更常见的场景：响应时间很低，吞吐量也很稳定，但服务端CPU已经跑到95%了。这时候如果你继续加并发，系统随时可能雪崩。所以资源监控不只是定位问题的工具，更是压测过程中的“安全气囊”，提前发现风险，及时止损。

4.2 轻量监控方案：几条命令看完Linux服务器的四项指标

如果只是摸底压测，不想额外安装监控平台，Linux自带的几个命令完全够用。

看CPU最常用的命令是top，执行后能实时看到CPU使用率、负载均衡、各进程CPU占用。vmstat 1可以每秒刷新一次，输出进程、内存、分页、IO、CPU等系统的总体信息。很多人看到top命令输出里有一行类似下面这样的内容，往往一头雾水：

%Cpu(s): 0.4 us, 0.2 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

我来拆解一下：us是用户态CPU占用率，指应用代码在跑；sy是内核态CPU占用率，指系统调用、进程调度等在跑；ni是进程优先级调整过的占用；id是空闲比例；wa是CPU等待IO的时间；hi和si分别指硬中断和软中断。如果wa很高，说明磁盘或网络IO是瓶颈；如果si很高，说明网络包处理压力大。上面这组数据99.4%空闲，说明CPU远远不是瓶颈，真正该去查的是别的环节。

内存用free -h看一眼就明白：

free -h

重点关注的是available这一列，它代表真正可用的内存，而不是只盯着free列。内存够不够用要看的是系统还有多少余量，以及有没有频繁使用Swap分区。如果Swap的使用率一直在增长，说明物理内存很可能不足。

磁盘IO用iostat -x 1：

iostat -x 1

重点关注util列，这个值接近100%时说明磁盘IO已经饱和，再高的await说明IO请求排队时间很长。对数据库机器来说，磁盘性能往往是最大的瓶颈。

网络带宽用sar -n DEV 1查看：

sar -n DEV 1

每条网卡都会输出两行，rKB/s是每秒接收的KB数，sKB/s是每秒发送的KB数。拿网卡的理论带宽（比如千兆网卡约125MB/s）和当前数值对比，就能算出带宽的利用率。

4.3 推荐方案：Jmeter PerfMon插件做实时监控

上面这些命令适合临时查看，但压测过程中要持续观察，并且把监控数据和压测结果放到同一张时间轴上对比，效率最高的方案是用Jmeter的PerfMon Metrics Collector插件配合ServerAgent。

ServerAgent需要部署在被压服务器上。下载对应的压缩包后解压，Linux下执行startAgent.sh，Windows下执行startAgent.bat，默认监听端口是4444。然后回到Jmeter，通过Plugins Manager安装PerfMon插件，添加一个监听器“jp@gc - PerfMon Metrics Collector”，在插件界面的Hosts列表里填被压服务器的IP、端口4444，然后在Metrics列表里添加要监控的指标：CPU、Memory、Disks I/O、Network I/O，甚至还能监控TCP、JVM等。

配置好后启动压测，PerfMon监听器会实时画出各指标曲线。想判断瓶颈是不是CPU，就看CPU曲线是否随着并发上升打到90%以上；想判断是不是磁盘慢，就看Disks I/O曲线是否出现持续高位。这种维度的交叉对比，是定位性能瓶颈的关键手段。

需要注意一点：ServerAgent本身也会消耗一点点被压服务器的资源，控制好监控频率和指标数量就能把影响降到最小。另外，生产或测试环境的防火墙要放行4444端口，否则Jmeter这边会一直显示连接不上。

4.4 指标怎么解读：CPU、内存、磁盘、网络的合理区间

拿到一堆监控数据之后，还是得知道多少算正常、多少算危险。我整理了一个可以参考的表格：

这里特别提醒一下：CPU使用率并不是越低越好。如果压测已经打上去了，CPU却长期趴在5%以下，说明请求大概率阻塞在别的地方——可能是数据库锁等待、网络延迟或者连接池排队。这时候看服务端的线程栈和网络监控比继续加并发更有价值。

5. 完整压测案例：一个订单查询接口的渐进式压测

5.1 案例背景与测试环境

现在把前面的理论串起来，完整走一遍实际案例。背景是一个订单查询接口，目标值是满足峰值场景下的TPS 2000，响应时间P95小于500ms，错误率小于0.1%。

测试环境是三台机器：一台压测机，运行Jmeter；一台应用服务器，4核8G，部署了Tomcat应用和订单查询接口；一台数据库服务器，MySQL 8.0。应用服务和数据库分机部署，避免资源互相干扰。压测机和应用服务器之间走专线网络，带宽千兆，排除网络带宽瓶颈的干扰。

测试数据提前准备了20万条订单数据，覆盖各种订单状态，通过CSV文件参数化。Token用固定测试Token，因为这次只压查询接口，不压登录链路。

5.2 渐进式加压过程与观察点

第一轮，50并发，持续5分钟。执行命令：

jmeter -n -t order_query_50.jmx -l result_50.jtl -e -o report_50

50并发跑下来，聚合报告显示TPS大约460，P95响应时间80ms，错误率0。同时看PerfMon监控曲线，应用服务器CPU使用率在25%左右，内存稳定，磁盘IO几乎为零。这个结果说明系统在50并发下非常轻松，可以继续加压。

第二轮，把线程数加到100，Ramp-Up设为10秒，持续5分钟。TPS来到了900左右，P95响应时间100ms，错误率仍然为0。服务端CPU上升到45%，依然有比较大的余量。

第三轮，线程数加到200。这一轮开始出现明显变化：TPS到了1600之后就不再线性增长了，P95响应时间飙升到800ms，错误率0.5%。查看监控曲线，应用服务器CPU已经跑到95%以上，内存、磁盘、网络都还有余量。到这里可以基本定位：瓶颈在应用服务器的CPU，而不是下游数据库或网络。

通过这个渐进过程，我们可以得出一个初步结论：单机4核8G的应用服务器，这个订单查询接口的实际处理上限大约在1600~1700 TPS。要达到2000 TPS的目标，要么扩容应用服务实例，要么优化接口的计算逻辑降低CPU消耗。接下来就拿着这份数据去和开发沟通，方向非常明确。

5.3 生成HTML报告并输出压测结论

压测结束后，Jmeter命令行模式会自动生成一个HTML报告，打开report_50目录下的index.html就能看到完整的压测结果，包括吞吐量曲线、响应时间分布、错误率统计等信息。

写压测报告时，我的习惯是把下面几个信息全部带上：

• 测试时间、压测脚本版本、被测服务版本
• 压测机和应用服务器配置、网络情况
• 各档位并发的TPS、响应时间P50/P95/P99、错误率
• 服务端CPU、内存、磁盘、网络的监控曲线截图
• 瓶颈定位结论和推荐优化方案

如果优化后要复测，比如开发把接口查询逻辑做了优化，就用同一个脚本、同一种数据、同样的并发档位再压一轮，和上次的数据做对比。只有控制变量，压测结论才有参考价值。

6. 常见问题与避坑实录

6.1 压测常见问题速查表

我把这几年做接口压力测试遇到的高频问题整理成了一张表，遇到对应现象可以直接查：

这里也要区分一下JMeter这类接口压测工具和专门的CPU压力测试工具。像R23（Cinebench R23）这类软件，是单独压CPU计算能力的，用来测硬件散热和稳定性；而Jmeter压的是业务接口，目标是看整个服务链路在流量冲击下的表现。很多人一搜“压力测试”就把这两个概念混在一起，其实它们应用场景完全不同。如果只是想验证电脑CPU是不是稳定，用R23跑一轮就行；如果想知道线上接口能扛多少并发，那才用到Jmeter。

6.2 服务端CPU异常占用排查思路

压测过程中偶尔会遇到一种情况：明明并发还没有加多少，服务端CPU却已经飙上去了，甚至压测结束了CPU还下不来。面对异常CPU占用，第一步是定位是哪个进程在消耗CPU。

Linux下用top看进程，找到CPU占用最高的PID之后，再用top -Hp PID查看这个进程内哪个线程在跑；如果需要更详细的信息，可以抓线程快照分析：

jstack PID > thread_dump.txt

看一下线程栈，基本就能区分是业务代码在死循环、GC线程在频繁回收，还是有线程在持续占用CPU。

排查过程中还要留意一种特殊情况：CPU占用高不一定是压测流量导致的。比如Windows环境下，我遇到过“服务主机DCOM占用CPU高”的现象，任务管理器里服务主机进程CPU占用居高不下，但被压的Java进程CPU反而正常。这种情况通常和COM组件、计划任务或者某些后台服务频繁启动有关，常见处理思路是更新系统组件、关闭无关的计划任务、在服务管理里停掉不需要的后台服务。所以我做压测前有一个习惯：先花两分钟看一眼被压服务器有没有奇怪的进程在跑，避免把别的问题算到压测头上。

如果你还想看CPU温度，Linux下可以装lm-sensors，执行sensors命令直接读取每个CPU核心的温度。温度信息在长时间稳定性压测里很有用，特别是夏天机房温度高的时候，CPU过热降频会导致压测数据出现异常波动。

6.3 压测过程中的几条实在心得

最后分享几个我在实际项目里沉淀下来的习惯。第一，压测环境和生产环境差距越大，压测结论的参考价值就越低。条件允许的话，尽量在和生产同等配置的环境上压，或者直接把压测放到生产集群的某一个独立节点上，用集群流量隔离的方式来做。

第二，压测脚本本身也需要被审查。我以前犯过一个错误：脚本里把请求参数写死，导致所有请求都命中了Redis缓存，接口的P95响应时间只有20ms，整个团队都很兴奋。后来把参数随机化重新压，P95直接涨到300ms。从此之后，每次压测前我都会检查一遍脚本里的参数化配置，确认数据是分散的。

第三，连续压测时间不要太短。很多人做压测只压3分钟，看着没问题就收工。3分钟暴露不了JVM堆内存的缓慢增长，也暴露不了数据库连接池随着时间慢慢耗尽。起码跑到20~30分钟，长稳测试对线上系统才更有参考意义。

在做压测项目的这些年里，我最深刻的体会是：压测报告里最有说服力的，不是聚合报告上那一排数字，而是“当并发加到某个值时，CPU、内存、磁盘、网络这四类指标中，哪一个先到达了极限”。只要把这个先后顺序搞清楚了，系统的容量边界和优化方向就都浮出水面了。做压力测试，本质上是在给系统找上限，但找上限的同时，也是在为稳定性画一条安全线。