JMeter接口压测实战：从安装配置到性能调优全流程指南

JMeter接口压测这件事，桌面上的坑往往比压测本身的坑更多。我见过不少同事卡在安装配置，卡在证书导入，卡在一跑就内存溢出，最后误以为JMeter不好用。其实只要把整个流程捋顺，JMeter是性能测试里最顺手的那把螺丝刀。今天这篇，咱们就从Windows上的安装开始，一路讲到并发压测、参数化、断言、HTTPS录制，最后把常见问题一次性说清楚——完全按照我自己踩坑后的标准流程来。

1. 动手前的准备：JMeter与JDK环境的正确安装

1.1 先装JDK还是先装JMeter

先说结论：先装JDK，再装JMeter，顺序反了会各种报错。

JMeter本质上是跑在Java虚拟机上的一个图形化工具，它本身不提供运行环境。很多人下载了JMeter压缩包，解压后双击 jmeter.bat 发现窗口一闪而过，或者提示 "Java not found"，十有八九就是JDK没装好，或者环境变量配错了。我见过最典型的场景是：电脑上装过某款软件自带JRE，Java命令能跑，但JMeter启动时找不到完整JDK的编译组件，导致一些插件无法加载。

所以第一步别急着下载JMeter，先把JDK版本确定好。JMeter 5.x 官方建议使用 Java 8 以上版本，我自己长期使用 JDK 8（1.8）和 JDK 11 切换着跑。如果只做接口压测，JDK 8 的稳定性和兼容性最好；如果后续要用到更多现代特性，或者配合新版插件，可以上 JDK 11。没必要追求最新版 JDK 17、21，某些老插件反而会不兼容。

JDK 的获取方式可以去 Oracle 官网下载，也可以找 OpenJDK 的发行版。不管从哪下载，安装完一定要记得配置环境变量，这是新手最容易忽略的环节。

1.2 Windows下的安装与环境变量配置

Windows 下配置环境变量，核心就是三个：JAVA_HOME、PATH、CLASSPATH。写清楚给大家参考，我以 JDK 1.8 安装在 C 盘为例：

JAVA_HOME=C:\Program Files\Java\jdk1.8.0_202 PATH=%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin CLASSPATH=.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar

配置路径在"此电脑-属性-高级系统设置-环境变量"里操作。新建 JAVA_HOME，把JDK安装路径填进去；在 Path 里新增 %JAVA_HOME%\bin；如果系统没有 CLASSPATH 就新建一个。PATH 这里有一点要注意：不要删掉原来已有的 PATH 内容，用分号隔开追加即可。

JMeter 安装其实只需要两步：下载对应平台的压缩包，解压到某个目录。以 apache-jmeter-5.6.3 为例，解压到 D 盘后，建议同样配置一个 JMETER_HOME 环境变量，再把 bin 目录加进 PATH，这样后续命令行操作会方便很多：

JMETER_HOME=D:\apache-jmeter-5.6.3 PATH=%JMETER_HOME%\bin

2. 核心概念与第一个接口压测脚本

2.1 JMeter工作原理简述

很多新手第一次打开JMeter，看到左侧那棵“测试计划”树直接懵了。其实它就是一个可视化的流程编排器，核心模型可以概括为：线程组模拟用户，取样器发送请求，监听器收集结果。

线程组决定“有多少用户在跑”，HTTP请求取样器决定“用户干了什么”，聚合报告监听器决定“我们看到什么”。中间还可以插入逻辑控制器、断言、定时器、前置/后置处理器。对于接口压测来说，你最先需要理解的就是这三样东西，搞懂之后其他都是锦上添花。

如果你想更形象一点，可以把JMeter想象成一个“数字机器人车间”：线程组是车间的工人数量，每个工人手里拿着一份操作单（HTTP请求），做完一次操作后按流程记录成绩（监听器）。当所有工人同时开工时，就是一次并发压测。

2.2 创建测试计划、线程组、HTTP请求

在JMeter里，左侧树默认有一个“测试计划”。点右键，添加一个线程组，然后在线程组上右键添加“Sampler-HTTP请求”，这样一个最基础的压测脚本就成型了。

线程组里有几个关键参数需要你先弄明白：

• 线程数：模拟的用户数量。压测里常说的“100并发”，在线程组里就是线程数=100。
• Ramp-Up时间：所有线程启动完成所花的时间。如果Ramp-Up设为10秒，代表100个线程在10秒内陆续启动，而不是瞬间全部上线。
• 循环次数：每个线程执行的请求次数。勾选“永远”可以持续施压，配合调度器设置持续时间。

我第一次做压测时，把100个线程的Ramp-Up设成0，结果一启动，服务瞬间被打满，日志爆出一堆连接超时。后来才意识到，Ramp-Up时间不是随便填的，它其实是在模拟真实用户逐步进入系统的过程。一般建议线程数除以期望每秒启动的用户数，就是合理的Ramp-Up值。

HTTP请求取样器里，最常用的配置是协议、服务器名称或IP、端口号、HTTP方法、路径、参数。比如你想压测一个登录接口：

协议：http 服务器名称或IP：test.example.com 端口号：8080 HTTP方法：POST 路径：/api/login

参数可以在下方的“参数”表格里填写，也可以切到“Body Data”里写JSON。很多人以为GET和POST就是填个路径的事，其实POST接口如果后端接收的是JSON体，你必须切换到Body Data，写成类似 {"username":"test","password":"123456"} 的格式，否则压测结果全是400。

2.3 单用户1分钟冒烟测试怎么做

网络上常看到“jmeter 单用户1分钟”这个搜索词，其实就是冒烟测试，也叫基线测试。目的是先用最少的负载验证脚本是否正确，顺便拿到一个参考的响应时间。

操作很简单：线程组里，线程数设为1，Ramp-Up设为0，循环次数勾选“永远”，然后在线程组下方勾选调度器，配置持续时间为60秒。运行结束后，打开聚合报告，查看“平均值”“错误率”“吞吐量”这三项。如果单用户1分钟内错误率都是0，说明你这个接口的请求格式、参数、鉴权都通了，可以放心去加大压力。

这一步看起来简单，但我见过太多人一上来就放1000线程去压一个还没验证过的脚本。压力一上来，脚本自身的变量写错、断言使用不当、Header缺失这些问题全被放大，最后调了半天才发现是脚本问题，不是系统瓶颈。所以单用户1分钟，是压测前必不可少的“体检”环节。

2.4 添加监听器与简单运行

在测试计划上右键，添加监听器，里面最常用的三个：查看结果树、聚合报告、用表格查看结果。

查看结果树适合调试，它会把你请求的完整过程列出来，包括请求头、响应体、响应时间。调试阶段一定要开着它，双击某条记录可以看红色/绿色，绿色代表断言通过，红色代表失败。压测阶段建议关掉它，因为查看结果树会消耗大量内存，影响压测结果“纯度”。

聚合报告是压测结果的核心报表。你可以在里面看到样本数、平均响应时间、中位数、90%响应时间、99%响应时间、吞吐量、错误率等指标。注意，聚合报告里的“吞吐量”单位是每秒请求数（requests/sec），但很多人会误以为是总请求数，这两者差别很大。

配置好监听器后，点击工具栏上的绿色三角按钮就是启动。启动时可以留意一下左上角的绿色方框，那表示测试正在运行。等线程跑完或到达调度器设置的时间，JMeter会自动停止。简单跑一次，如果你能看到聚合报告里的样本数大于0，说明你已经完成了人生中第一次JMeter接口压测。

3. 脚本进阶：参数化、断言与登录接口

3.1 用CSV参数化模拟真实用户

压测最大的谎言之一就是“所有用户用同一个账号压”。真实场景里，100个用户应该有100个不同的账号、手机号、商品ID。如果你全用一个固定参数，服务端可能做了缓存或者账号风控，压出来的数据根本不真实。

解决办法是参数化，最常用的是CSV数据文件。你可以在jmeter的bin目录下准备一个users.csv，每一行是一组参数，比如：

username,password user01,123456 user02,123456

然后在测试计划里添加“配置元件-CSV数据文件设置”。重点字段有四个：文件名、变量名称、分隔符、线程共享模式。文件名建议写绝对路径，变量名称例如 username,password，分隔符填逗号。线程共享模式选择“当前线程”，这样每个线程取一行，不会互相抢数据。

之后在HTTP请求的参数值里写成 ${username} 和 ${password}，JMeter就会自动从CSV里取值。如果你的数据量不够线程数，JMeter会循环读取，这个需要注意，否则可能出现重复使用的情况。

3.2 断言怎么写才有效

断言的作用，就是让JMeter自动判断接口返回是否符合预期。没有断言的压测，只知道发了多少请求，但不知道这些请求到底成功没有。

很多新手会在“查看结果树”里用眼睛看响应体，这在小并发下还能忍，一旦上了500线程，眼睛根本看不过来。所以必须用响应断言来做自动化判断。

添加方式：在HTTP请求上右键，添加“断言-响应断言”。最常用的配置是把“测试字段”选为“响应文本”，然后在“模式匹配”里填写你要检查的字符串，比如登录接口成功后返回的 "success" 或 "token"。

这里有个关键坑：如果返回结果里有中文，JMeter可能会因为编码问题出现乱码，导致断言失败。解决办法是在HTTP请求下方添加“前置处理器-用户参数”，或者修改jmeter.properties里的 sampleresult.default.encoding=UTF-8。我自己更推荐直接用BeanShell断言或者JSON断言处理复杂响应，比如判断某个JSON字段的值是不是等于200。

JSON断言在JMeter里叫“JSON断言”，需要填写“JSON Path”和“Expected Value”。比如接口返回 {"code":0, "data":{...}}，JSON Path写 $.code，Expected Value写 0。注意JSON路径的语法和XPath不一样，初次使用容易写错，建议先调试通过再批量压测。

3.3 登录接口与Token传递的常规做法

登录接口几乎是每个压测项目的必经之路。最常见的问题是：登录接口拿到了token，但后面的业务接口怎么用它？

做法是用“正则表达式提取器”或“JSON提取器”从登录响应中提取token，然后通过变量传递给后续请求。以JSON格式返回为例，在登录HTTP请求上右键，添加“后置处理器-JSON提取器”：

变量名称：access_token JSON Path：$.data.token 默认值：NOT_FOUND

然后在后续HTTP请求里添加Header管理器，写入：

Authorization: Bearer ${access_token}

这样整条压测链路就串起来了。要注意的是，线程组内的变量作用域是默认的，如果你用了“仅一次控制器”来控制登录只执行一次，但后面的请求又在同一个线程内，变量是可以正常复用的。

还有一点经验：如果登录本身就有验证码，压测环境一定要绕过验证码，让开发配合做个开关。千万别傻乎乎地在压测脚本里硬编码验证码，那样测出来的结果毫无意义。

3.4 请求默认值的作用

一个测试计划里可能有几十个HTTP请求，如果每个都填一遍协议、服务器名、端口号，不仅累，还容易改错环境。这个场景下用“HTTP请求默认值”最合适。

在线程组上右键，添加“配置元件-HTTP请求默认值”，把公共的协议、服务器名称、端口填进去。后面新建HTTP请求时，这些公共字段就不用重复填，只要填路径和参数即可。

这个配置元件还有个隐藏好处：切换环境特别方便。测试环境改成 staging.example.com，生产环境改成 prod.example.com，改完默认值，整个脚本的请求地址全部同步变化。我在实际项目中就用这个办法管理了四套环境的压测脚本，省下的时间很可观。

4. 真实场景压测：并发数确认、上传文件与HTTPS

4.1 怎样确认系统的并发数

每次接到压测需求，总有业务方问：“你们帮我压一下，看看系统能支撑多少并发。”这个问题其实暴露了一个常见误区：并发数不是压测测出来的，而是由业务场景和系统容量共同决定的。

确认并发数通常有两种途径。一种是从业务侧推导：根据日活的峰值时段、平均每个用户操作频率、关键接口的调用比例，估算出峰值QPS，再换算成需要的并发线程数。换算公式可以简化成：并发数 = 目标QPS × 平均响应时间。举个例子，目标QPS是200，平均响应时间0.5秒，那并发数大概就是100。

另一种是探索式压测：从一个较低并发开始，比如100，持续跑5分钟，看响应时间、错误率、吞吐量。如果系统稳定，再逐步增加50或100，直到出现响应时间明显上升、错误率超过5%或者吞吐量不再增长的点，那个点附近就是当前系统的容量上限。

我在实际项目里通常会画一条“吞吐量-并发数”的趋势线。健康系统的表现是：并发上升时吞吐量跟着上升，响应时间保持在低位；当并发超过某个阈值后，吞吐量开始持平甚至下降，响应时间飙升，说明系统已经过载。这个阈值才是你压测最想找的东西。

4.2 上传文件接口的JMeter实现

上传文件接口在JMeter里看起来有点绕，其实核心就是用HTTP请求里的“Files Upload”选项卡。

操作方法：在HTTP请求取样器里，把HTTP方法设为POST，切到“Files Upload”，点击添加，填写文件路径、参数名称、MIME类型。这里的参数名称必须和后端接口定义的字段名一致，比如后端接收的是 file，就填 file，而不是填文件名。MIME类型按文件类型填，常见的 image/jpeg、application/octet-stream 都可以。

要注意的是，如果上传接口同时还需要带其他业务参数，不能切到“Parameters”选项卡去填，否则文件会冲突。正确做法是在“Body Data”里以multipart形式拼接，或者用“HTTP信息头管理器”把 Content-Type 设为 multipart/form-data; boundary=...。我建议直接用Files Upload自带的格式，配合测试计划根节点下的“HTTP请求默认值”，可以避免很多低级错误。

压测上传文件时还有一个资源占用的问题：JMeter所在机器需要不停读取本地文件并发送，文件越大，占用的内存和网络带宽越高。如果你压的是图片上传接口，建议准备一批几百KB到几MB不等的测试图片，用小文件混合大文件模拟真实场景。

4.3 HTTPS接口与安全证书处理

现在大部分线上接口都是HTTPS，直接用JMeter去压HTTPS，经常会出现“SSL证书”相关的报错，新手很容易卡在这一步。

推荐的做法不是去代码里绕过证书，而是把服务端的证书导入JMeter使用的JDK信任库。操作步骤不算复杂：先从服务端导出证书，通常是 .crt 或 .cer 文件，然后用JDK自带的keytool命令导入。

keytool -import -alias myserver -keystore "%JAVA_HOME%\jre\lib\security\cacerts" -file D:\server.crt

默认密码是 changeit。导入过程中会让你确认是否信任，输入 yes。导入完成后重启JMeter，HTTPS请求就能正常发出。如果你只是临时测试，也可以在HTTP请求的高级选项卡里把“Implementation”改成“HttpClient4”，并在JMeter的 system.properties 里配置忽略证书，但这种方式不适合正式压测数据，因为不能完全模拟真实的TLS握手。

4.4 录制HTTPS脚本和WebDriver Sampler处理复杂流程

很多接口压测脚本其实是从浏览器操作转化来的。JMeter提供了一个HTTP代理服务器，可以用来录制浏览器里的HTTP请求。操作路径是：测试计划右键，添加“非测试元件-HTTP代理服务器”，然后设置端口，比如8888，再把浏览器的代理指向本机8888。做完这步，你在浏览器里的操作就会被JMeter记录成一个个取样器。

如果是HTTPS协议，需要在浏览器侧安装JMeter生成的证书，否则只能录到CONNECT请求，看不到真正的接口内容。录制完成后，记得要通过“HTTP请求默认值”和参数化，把动态值替换掉，否则回放时大概率失败。

如果有些场景不是单纯HTTP请求，而是需要真实浏览器渲染页面才能触发的接口，比如人脸识别这类技能依赖前端JS计算或硬件调用的系统，直接用HTTP取样器会漏掉很多关键环节。这时候就要用到插件 jp@gc - WebDriver Sampler。

这个插件依赖Selenium，可以驱动真实浏览器执行点击、输入、上传图片等操作，同时记录浏览器发出的网络请求。配置WebDriver Sampler时，需要在JMeter插件管理器里安装“Selenium/WebDriver Support”和“jmeter-plugins-webdriver”，然后在取样器里选择浏览器类型，写一段Groovy或Java脚本。Groovy脚本大概长这样：

WDS.browser.get('https://test.example.com/login') WDS.browser.findElement(By.id('username')).sendKeys('test') WDS.browser.findElement(By.id('password')).sendKeys('123456') WDS.browser.findElement(By.id('loginBtn')).click() WDS.sampleResult.sampleStart() WDS.browser.get('https://test.example.com/face/verify') WDS.sampleResult.sampleEnd()

这类浏览器级压测比纯HTTP压测更接近真实用户，但消耗的资源也非常大，通常只在接口层压测无法覆盖前端交互性能时才使用。

5. 性能测试的执行与结果分析

5.1 常用性能测试操作说明

性能测试不是“把线程调大然后点击运行”这么简单。业内一般会分成几种类型：基准测试、负载测试、压力测试、稳定性测试。它们的区别用一个表格可以看得比较清楚。

拿“jmeter如何做性能测试”这个问题来说，完整的操作流程是：确定测试目标、准备测试数据、设计脚本、小并发冒烟、逐步加压、收集监控数据、分析瓶颈、输出报告。多数人只做到了“压一下看看”，并没有形成闭环，导致压测报告出来后，开发不知道该改哪里。

性能测试操作说明中还有一个关键点：不要在JMeter所在机器上同时跑浏览器、看视频、编译代码。性能测试对资源非常敏感，JMeter本身虽然是轻量级工具，但在高并发下单机也会出现瓶颈，一般建议JMeter机器的CPU、内存使用率不要超过70%，否则结果会失真。

5.2 查看结果树与聚合报告怎么看

结果树和聚合报告是大家最常用的两个监听器，但很多人只会看红色和绿色。

结果树里，每一行记录代表一次完整请求，点击可以看到请求头和响应体。调试阶段，我习惯只看三类东西：HTTP状态码是否正常，响应体关键字段是否符合预期，响应时间是否在合理范围。如果出现红色，不要急着改脚本，先打开响应体看具体的错误信息，很多问题都是参数没传对、Header缺失、服务端内部报错。

聚合报告的指标识别是个必修课：

• Samples：总请求数。
• Average：平均响应时间，单位毫秒。这个指标容易被极值拉偏，还要结合中位数看。
• Median：50%的请求在这时间内完成，反映大多数用户的感受。
• 90% Line：90%请求都在这个时间内完成，这个指标比平均响应时间更可靠。
• Error %：错误率。接口压测一般要求低于0.1%，带了异常流程的可以放宽。
• Throughput：吞吐量，每秒完成的请求数（requests/sec）。

实际分析时，如果平均响应时间正常，但90% Line很高，说明存在明显的长尾请求，这时候要关注是不是慢SQL、GC停顿、或个别节点抖动导致的。如果吞吐量上不去，响应时间也不高，问题可能出在JMeter客户端瓶颈或网络带宽，而不是服务端性能。

5.3 如何从压测中定位瓶颈

压测的目的不是为了得到一个“并发多少，报错多少”的数字，而是为了回答一个问题：系统到底卡在哪了？

定位瓶颈的基本思路是分层排查。先把压测结果分成客户端、网络、服务端三段。客户端看JMeter所在机器的CPU和内存，如果JMeter自身消耗过高，先要排除客户端瓶颈。网络段看请求往返时间，通过Ping或Traceroute确认是否存在丢包，尤其是跨机房压测时，网络抖动经常被误判为接口性能差。

服务端是排查重点。我习惯在压测同时开启以下几项监控：CPU和内存使用率、磁盘IO、网络连接数、Tomcat线程池、数据库连接池、慢查询日志。如果服务端CPU长时间100%，大概率是逻辑计算或GC问题；如果数据库连接池被占满，说明接口的SQL或连接释放存在问题；如果线程池排队增多，说明容器配置不匹配。

实操中最常见的误判是把“高并发下出现超时”一锅端地归结于“系统性能差”。实际上很多超时来自服务间调用链过长，比如订单接口同时调用了库存、优惠券、用户三个服务，压测下单接口时，真正瓶颈是其中的某个下游服务。这时候必须在JMeter里同时压测各个下游接口，做对比分析，才能快速锁定根因。

5.4 压测虚拟机环境与本地服务的注意事项

很多人在自己电脑上装了虚拟机，里面部署了一套服务，然后想用JMeter压一下，结果发现性能数据惨不忍睹。这里要提醒一个认知误区：在同一台物理机上跑JMeter和目标服务，它们会互相抢CPU、内存、磁盘，测出来的数据没有实际参考价值。

如果必须测试自己安装的虚拟机，至少要保证JMeter跑在宿主机上，目标服务在虚拟机里，两者通过NAT或桥接网络互通。先确认虚拟机端口能通，再开始压测。其次，虚拟机的资源限制要清楚，尤其要关注vCPU分配和内存大小。压测时，虚拟机的CPU不要设成“不限制”，否则物理机多核被耗尽，影响JMeter端。

另外，虚拟机里的服务性能往往不等于生产环境性能。压虚拟机更多是用来验证脚本流程和业务逻辑，而不是给出最终的容量评估。我在给一些客户做内部培训时，经常强调：虚拟机压测结果可以作为相对对比，比如优化前后对比、代码版本对比，但绝对值不能直接用于容量规划。

6. 常见问题与排查技巧实录

6.1 测试人脸识别系统这类特殊接口

“jmeter人脸识别系统压力测试”是我经常被问到的一个需求。人脸识别接口和普通接口不太一样，它通常涉及图像上传、预处理、特征提取、匹配比对几个阶段，响应时间长、资源消耗大，而且往往会依赖GPU或专门的识别服务。

压这种人脸识别系统，核心脚本设计要注意三点。第一，准备一批真实有效的测试图片，最好涵盖不同大小、角度、光照条件的样本，不要用同一张图片反复压，否则服务端可能有缓存，测不出真实性能。第二，由于识别接口响应时间可能达到几秒甚至十几秒，线程组的Ramp-Up时间要适当拉长，避免所有线程同时打到识别服务上，导致瞬间雪崩。第三，关注服务端的CUDA占用率、显存使用率、导出服务的线程池状态，这些指标比JMeter结果更关键。

另外，人脸识别接口通常需要鉴权，压测前确认鉴权方式，在脚本里通过CSV参数化准备多个有效token。如果token在短时间内失效，脚本执行中会出现大量401，直接影响结果真实性。建议让开发提供压测专用token，或者配置一个token刷新逻辑。

6.2 连接不上目标地址

压测时最常见的一个错误是“Connection refused”或“Connection timed out”。很多人的第一反应是网络有问题，但实际上原因可能很多。

先确认目标服务是否可达。最简单的排查方式是在JMeter同一台机器上用命令行手动访问一下：

curl -v http://target-ip:port/api/health

如果curl能通而JMeter不通，重点检查JMeter里的请求默认值和HTTP请求中是否填了错误的协议或端口。如果curl也不通，那就要检查防火墙、服务状态、网络路由。还有一点很隐蔽：JMeter的HTTP请求默认值如果配置了HTTPS协议，后面某个HTTP请求里又漏改协议，就会以错误协议访问，导致连接失败。

如果是压测本机启动的服务，比如springboot项目占用了8080端口，JMeter里服务器名称可以填 127.0.0.1 或 localhost，注意别填成虚拟机IP。很多本地服务默认只监听127.0.0.1，这时候如果你用局域网IP访问，自然连不上。

6.3 内存溢出与结果数据量过大

JMeter卡死、报OutOfMemoryError，这几乎是高并发压测的必经之路。原因是JMeter默认启动的内存在 bin 目录下的 jmeter.bat 里被限制了，通常是 -Xms512m -Xmx512m。一旦测试计划复杂、监听器开得多、查看结果树一直开着，内存很快就被撑爆。

解决办法是修改JMeter启动参数。在 jmeter.bat 里搜索 HEAP，把 -Xms 和 -Xmx 调大，我一般会设置为 -Xms2g -Xmx4g，具体大小取决于机器内存。另外，如果你的压测脚本非常大，比如上千个取样器，建议调整元空间参数：

set HEAP=-Xms4g -Xmx4g -XX:MaxMetaspaceSize=1g

修改后缀名为 vmoptions 的文件也可以，但批处理里的 HEAP 参数是主入口。改完后重启JMeter，再看结果。

结果数据量太大是另一个坑。我用JMeter压过一晚上生成10GB日志的场景，如果启用了详细日志和查看结果树，磁盘瞬间就被写满。正确的压测方法是：正式压测时不要开查看结果树，只开聚合报告和简单数据写入器。如果你需要完整记录每个样本，可以在简单数据写入器里配置只输出核心字段，而不是把请求和响应体全写下来。

6.4 一个小技巧：用jp@gc插件补充监控

最后分享一个我每次压测都会做的补充配置：安装 jp@gc - PerfMon Metrics Collector 插件。这是一个很有用的辅助工具，可以把目标服务器的CPU、内存、磁盘、网络指标同步显示在JMeter监听器里。

使用方法和WebDriver Sampler类似，需要通过JMeter插件管理器安装“PerfMon”插件，然后在目标服务器上启动一个ServerAgent服务。监听器里添加 PerfMon Metrics Collector，配置好目标服务器的IP、端口和需要收集的指标，然后和压测脚本一起启动。这样在分析聚合报告时，你可以同时看到服务端资源使用情况，不会再出现“报错率很高但不知道服务器当时在干什么”的窘境。

需要注意，PerfMon采集结果也会占用一点网络资源，高并发压测时建议单独用一个内网口，或者把采集间隔放宽到2秒。这个小东西是我压测工作台上的常客，每次压完，我都会把JMeter结果和服务端监控截图放一起，写进压测报告里，开发同学看到后定位问题的效率会高很多。