1. 从下载到跑通第一个测试计划JMeter 5.6 的环境底座如果你刚接触性能测试第一次打开 JMeter 5.6 大概率会有两个困惑一是这玩意儿解压完一堆目录哪个该点二是界面点来点去怎么才能让一个请求真正发出去。我最早做接口测试时也纠结过后来发现只要把环境底座这三件事搞明白后面所有复杂的脚本都是在上面搭积木。这篇文章不是官方文档的翻译而是我这些年用 JMeter 做接口测试和压力测试踩出来的经验整理从安装配置讲到参数化、断言、证书、常见报错排查最后落到真实的高并发压测场景。不管你之前有没有接触过 JMeter看完至少能独立搭出一套可复用的测试工程。JMeter 是 Apache 基金会下的开源测试工具最初为 Web 应用压力测试而生现在已经能覆盖 HTTP、数据库、消息队列、FTP 等多类协议的测试需求。5.6 这个版本是很多人从旧版本迁移过来的节点它的 JDK 要求和组件行为跟 3.x、4.x 有明显差异所以环境这块必须先对齐。1.1 JDK 版本与安装包的取舍JMeter 5.6 是基于 Java 开发的所以运行前提是本机装了 JDK。这里我强烈建议直接上 JDK 8 或 JDK 11 的 LTS 版本JDK 17 也能跑但部分老插件在模块化之后会有反射报错反而给自己找麻烦。判断标准很简单JMeter 官方发布包对应的 JDK 兼容范围你按最低门槛往上取一档就是最稳的。安装包本身分两种一种是apache-jmeter-5.6.zip这样的压缩包另一种是带_bin后缀的二进制包。两者区别在于是否包含源码做测试用前者就够了解压即用不需要执行安装程序。下载来源认准 Apache 官网的下载页别从第三方站点拿避免捆绑或者版本被改动。下载下来解压到一个没有中文路径、没有空格的目录比如D:\tools\apache-jmeter-5.6这个细节看着小但很多人脚本跑不起来就是路径里带了中文或者空格导致的。解压后的bin目录里有几个关键文件你需要认识文件作用jmeter.bat/jmeter.sh图形界面启动脚本Windows 用 batjmeter-server.bat分布式压测时的从机启动脚本jmeter.properties核心配置文件改语言、日志、结果保存等都在这user.properties用户级覆盖配置升级版本时不用动主配置启动前建议先改一件事在jmeter.properties里把languagezh_CN打开界面就能切到中文。另外如果你发现 JMeter 界面字体发虚或者中文显示成方块那是 JVM 字体渲染问题可以通过调整jmeter.bat里的 JVM 参数或者换 JDK 版本解决这个后面讲报错时会再提到。1.2 图形界面与命令行模式的分工很多人有个误区以为压测就是打开图形界面点开始。实际上 JMeter 有个非常重要的原则图形界面只用来编写和调试脚本真正的压测必须用命令行模式跑。原因很直接图形界面本身要消耗大量内存和 CPU 来渲染监听器、画图表这会污染压测结果。你开着界面跑 500 并发测出来的响应时间里可能有一大半是界面渲染拖累的。正确做法是脚本调通后保存为.jmx文件然后用命令jmeter -n -t test_plan.jmx -l result.jtl -e -o report_output这里-n表示非 GUI 模式-t指定脚本-l指定结果文件-e -o表示测试结束后直接生成 HTML 报告到指定目录。生成的报告目录必须为空否则会报目录已存在的错这也是一类高频报错。命令行模式下的参数调优同样重要。默认 JVM 堆内存可能只有 1G并发量上去后容易 OOM可以在jmeter启动脚本里把HEAP调整到-Xms2g -Xmx2g -XX:MaxMetaspaceSize512m这样。具体调多大取决于你的并发规模和服务端返回数据量我一般按每 100 并发预留 1G 堆内存来估再留点余量。提示命令行跑压测时监听器里不要挂查看结果树这类内存杀手改在调试阶段用正式压测时用聚合报告或者直接靠生成的 HTML 报告分析。2. 测试计划里那堆元件到底谁管谁线程组、控制器与取样器打开 JMeter 左侧那棵树新手最容易懵的就是元件太多不知道该拖哪个。其实整棵树的逻辑非常清晰从上到下就是用户怎么来线程组→ 来了做什么控制器取样器→ 做的过程中怎么处理数据配置元件、前置后置处理器→ 做完怎么看结果监听器。把这四层搞清楚脚本组织就不会乱。2.1 线程组的并发模型与三种调度方式线程组是整个测试计划的入口它决定了有多少虚拟用户、怎么发起、发多久。这里有几个参数必须吃透线程数Number of Threads虚拟用户数一个线程模拟一个用户。Ramp-Up 时间所有线程在多长时间内启动完。比如 100 线程配 10 秒就是每秒启动 10 个。循环次数每个线程执行多少次。很多人直接忽略 Ramp-Up填个 100 线程 1 秒启动结果瞬间把被测服务打挂测出来的数据全是超时。实际上 Ramp-Up 是模拟真实用户逐步进入的过程除非你要做瞬时尖峰测试否则合理设置能让结果更接近真实业务。线程组还有三种模式要区分。普通线程组是用户真正发起请求的setUp线程组会在普通线程组之前执行适合做登录获取 token、准备测试数据tearDown线程组在所有线程组之后执行适合清理数据。我做过一个压测项目前 20 个请求要先拿到一个全局唯一编号作为后续接口参数就是靠setUp线程组里调一次接口写进属性然后其他线程组读取避免了每个线程都去重复调用。调度器模式也值得说。勾选调度器后你可以指定持续时间和启动延迟做持续压 30 分钟这类稳定性测试时很方便。不过要注意循环次数和调度器同时存在时的优先级问题容易配出跑满时间但没跑够次数或者反过来我的习惯是做稳定性测试时循环次数设为永远靠调度器控制结束时间。2.2 逻辑控制器解决的真实问题逻辑控制器本身不发送请求它管的是取样器的执行顺序和条件。用得最多的几个事务控制器把多个请求合并成一个事务统计总耗时。比如一个下单动作包含加购物车→选地址→提交订单三个接口你关心的是整体耗时就用它包起来。循环控制器控制子元件循环次数跟线程组循环是叠加关系容易配出天文数字的请求量要小心。仅一次控制器子元件在每个线程里只执行一次典型场景是登录。一个用户登录一次后后面所有请求复用这个会话就靠它。If 控制器根据条件判断是否执行配合函数和变量做分支逻辑。2.3 元件执行顺序一个被严重低估的知识点这是我最想强调的一点。JMeter 里元件的执行顺序不是你在树里看到的排列顺序而是有固定规则配置元件前置处理器定时器取样器后置处理器断言监听器这个顺序决定了你在哪里定义变量后面才读得到。比如你想在 HTTP 请求里用一个从数据库查出来的值就得把 JDBC 后置处理器放在前置位置让它在取样器之前把值取好写进变量。我见过有人把断言写在前置处理器里想提前拦截结果完全没用就是因为断言阶段晚于取样器。理解了这个顺序为什么变量取不到为什么断言没生效这类问题基本能自己定位。同一层级内的多个同类元件则按它们在树里的先后顺序执行。这个规则在我们后面讲参数化、Cookie 时会反复用到。3. HTTPS 脚本录制与证书那些绕不开的事手写脚本对简单接口没问题但面对一个几十个接口的复杂系统一个个手敲请求路径和参数太费劲。这时候录制脚本就派上用场了。JMeter 提供了一个测试脚本录制器本质是一个本地的代理服务器浏览器把流量发到它这里它翻译成 JMeter 的取样器。3.1 录制器的工作链路录制涉及三个角色浏览器、JMeter 录制器、目标服务器。链路是浏览器设置代理指向录制器端口录制器再转发给真实服务器。JMeter 里叫HTTP(S) Test Script Recorder在测试计划下添加它默认监听 8888 端口。配置时几个关键点Target Controller指定录制下来的取样器放到哪个线程组下一般单独建一个录制线程组。分组方式建议选Put each group in a new transaction controller这样同类请求会被归并脚本更整洁。URL 过滤把图片、css、js 这类静态资源过滤掉只录接口请求否则脚本里全是噪声。浏览器侧把 HTTP 和 HTTPS 代理都指向127.0.0.1:8888。注意 https 的流量不能直接录因为浏览器不信任录制器的证书会直接拒绝连接这就是证书问题的根源。3.2 证书导入与浏览器信任JMeter 在bin目录下自带了一个ApacheJMeterTemporaryRootCA.crt证书文件。第一次点击开始录制时它会在 bin 目录下自动生成这个根证书。你需要把它导入到浏览器或者操作系统受信任的根证书存储里。Windows 下的导入路径双击证书文件 → 安装证书 → 选择本地计算机 → 受信任的根证书颁发机构。导入完重启浏览器再录制 https 就不会报证书错误了。这里有个坑很多人踩证书是每次生成的话如果不固定换台机器或者重装 JMeter 就得重新导。而且证书默认有效期有限过期后录制就会失败报证书不受信任。解决办法是在jmeter.properties里把proxy.cert.validity调大或者干脆维护一份固定的证书文件复用。3.3 录制之后的参数关联录下来的脚本几乎不能直接用因为里面全是硬编码的、跟这次会话绑定的值会话 id、时间戳、token、随机串。这些值在下次请求时已经失效脚本一回放就失败。这就是参数关联要解决的问题。核心做法是把动态值从上一个响应里提取出来存成变量下一个请求用变量引用。提取用后置处理器最常用的是正则表达式提取器和JSON 提取器需要插件。比如响应里返回{token:abc123}用 JSON 提取器写$.token就能把abc123提到变量token里下个请求填${token}。关联的本质是识别哪些值是服务端动态下发的这需要你看响应内容判断。我一般先回放一次看哪个请求失败了再回头看它依赖什么值逐个关联。这活儿没有捷径靠的是对业务链路的理解。4. 参数化把 JDBC 查询结果喂给下一个接口参数化是让脚本活起来的关键。同一个接口不同用户要传不同账号、不同编号才能模拟真实场景。JMeter 提供了多种参数化手段选哪种取决于数据从哪来。4.1 CSV 与 JDBC 两种数据源的差异最常见的是 CSV 数据文件配置把测试数据写成一行行的 csv每个线程读一行。配置项里Recycle on EOF控制数据读完后是否循环Sharing mode决定数据在线程间怎么分配。做多用户并发时一般选所有线程共享让每个线程拿到不同的行。但有些数据不在文件里而在数据库里。比如压测下单接口需要一批真实存在且状态正常的订单编号这些编号存在业务库里。这时候就要用JDBC Request直接从数据库查。JDBC 参数化的完整链路是这样的配置JDBC Connection Configuration填数据库地址、驱动类、账号密码、连接池参数。添加JDBC Request写 SQL 查询指定结果变量名比如orderIds。用后置处理器或者直接通过变量引用把查询结果传给 HTTP 请求。查出来的结果JMeter 会按${orderIds_1}、${orderIds_2}这样的格式存成一组变量orderIds_#表示行数。你可以在 HTTP 请求里用${__V(orderIds_${__Random(1,${orderIds_#})})}这种写法随机取一行。这个嵌套函数看着绕但它是把随机行号和结果变量拼起来的标准套路写熟了很好用。4.2 从查询结果取值传给下游接口举个我实际做过的场景压测一个对账接口需要从数据库捞出 500 个待对账的流水号每个线程随机取一个作为请求参数并且要求不能重复。做法是JDBC 查询出所有流水号到变量flowNos。用 CSV 或者计数器给每个线程分配一个唯一索引。HTTP 请求参数填${__V(flowNos_${index})}。这里有个坑JDBC 连接池如果配得太小高并发时线程抢连接会阻塞导致请求超时。连接池的Max Number of Connections一般要跟并发线程数匹配或者略大。另外数据库本身的连接上限也要考虑别把生产库的连接占满影响业务。注意对生产库做查询参数化时SQL 一定要走索引别一个select * from把库拖垮。压测工具把数据库搞挂的事故比压测把服务搞挂的还常见。4.3 RESTful 接口带路径参数怎么写RESTful 风格的接口参数不在查询串里而是嵌在路径上比如/api/order/{orderId}/detail。在 JMeter 里写法很直接把路径里的占位符换成变量引用即可/api/order/${orderId}/detail。如果参数需要 URL 编码JMeter 的 HTTP 请求默认勾选编码就行。真正麻烦的是 Path 参数里含特殊字符时的编码问题以及 PUT、DELETE 这类请求的方法选择。HTTP 请求元件里的 Method 下拉支持 GET、POST、PUT、DELETE、PATCH 等选对方法才能匹配到正确的后端路由。很多人测 RESTful 接口失败的根源就是方法选错了或者 Content-Type 头没设对服务器解析不了 body。5. 断言体系从响应断言到 Beanshell 断言请求发出去不代表测对了。返回 200 也可能业务是失败的所以必须加断言来判断结果是否符合预期。这是接口测试区别于发请求的核心。5.1 基础断言的适用场景JMeter 自带的响应断言Response Assertion能覆盖大部分场景。它支持匹配响应文本、响应代码、响应头、URL 等模式可以选包含、匹配、相等、子串。判断返回码是不是 200或者响应体里是不是包含success:true用它就够了。大小断言Size Assertion判断响应字节数持续时间断言判断响应时间是否超阈值。这俩在做性能测试时有用能快速标记出慢请求和异常大小的响应。基础断言的局限在于只能做字符串级判断。如果你想判断返回的订单列表数量大于 0或者某个字段的数值在合理范围内它就不够用了得上脚本断言。5.2 Beanshell 断言的写法与注意点Beanshell 断言让你写一小段 Java 代码来判断灵活性拉满。基本结构是String response prev.getResponseDataAsString(); if (response.contains(\code\:0)) { AssertionResult.setFailure(false); } else { AssertionResult.setFailure(true); AssertionResult.setFailureMessage(业务返回异常: response); }手上有个真实案例某接口正常返回是 JSON但偶尔会返回一段 HTML 错误页网关超时状态码还是 200。这时候基础断言判断 code0 会失败但不知道为啥Beanshell 里加一段判断响应是不是{开头能快速定位是网关层出的问题。写 Beanshell 断言要注意性能。它每请求都执行一次脚本代码里别做复杂操作、别查数据库、别发网络请求否则会成为压测瓶颈。另外 Beanshell 访问变量用vars.get()、vars.put()跟前置后置处理器里的用法一致。JMeter 5.6 里还有 JSR223 断言支持 Groovy 等语言性能比 Beanshell 好不少新项目我一般直接上 Groovy。5.3 断言粒度怎么把握断言不是越多越好。一个大压测脚本里塞满复杂断言本身就是性能负担而且断言失败时你还得逐个排查是哪条挂了。我的经验是分层断言接口级只断言核心业务字段如 code、关键 id 存在。事务级用事务控制器包住一组请求在事务上做整体时长断言。全局级用聚合报告或者后端监听器看整体成功率异常时告警。压测关注的是成功率和耗时接口测试关注的是字段值对不对两者断言策略应该不同别用接口测试的严格断言标准去压测会把大量本该成功的请求判成失败。6. 那些让人抓狂的报错从 error writing to server 到文件已存在用 JMeter 最耗时间的不是写脚本是排错。下面这几个报错我在实际项目里反复遇到把排查思路整理出来遇到时能少走弯路。6.1 java.io.IOException: error writing to server 的排查链路这个报错的意思是 JMeter 把请求发给服务端时连接断了。可能原因从上到下排服务端主动断开并发太高服务端的连接队列满了直接拒绝。检查服务端的最大连接数、线程池、accept 队列。请求体太大上传大文件时服务端或中间的负载均衡器有 body 大小限制。连接被中间设备重置网络层有设备限制了长连接或者包大小。JMeter 侧的问题用了 keep-alive 但服务端不支持或者 HTTP 实现选的 Java 默认实现在某些场景有兼容问题。排查方法先单线程跑一次确认脚本本身没问题再逐步加并发找到开始报错的临界点同时看服务端的日志和监控确认是服务端拒绝还是网络中断。我遇到过一次报错原因是压测机本地端口被耗尽TIME_WAIT 状态太多调大系统端口范围和缩短 TIME_WAIT 时间后解决这属于压测机自身瓶颈很容易被忽略。6.2 文件已经存在与防伪标记缺失文件已经存在这个报错多半出现在生成测试报告时目标目录非空。JMeter 生成 HTML 报告要求输出目录是空的我习惯每次压测前用脚本清空报告目录或者干脆用带时间戳的目录名。__RequestVerificationToken 未提供必要的防伪标记这个报错来自 ASP.NET MVC 的防伪机制。它要求发 POST 请求时带上一个防伪 token这个 token 藏在页面里或者响应里。解决办法是用正则提取器从页面提取 token然后在后续请求里带上。本质还是参数关联问题只是这个值比较隐蔽要看清服务端是从 cookie 校验还是从表单字段校验。6.3 Cookie 管理器的默认行为很多人不知道JMeter 每个线程有自己的 cookie 存储且默认就是开启的HTTP Cookie Manager 会自动处理。如果你在一个线程里登录后拿到了会话 cookie后续请求会自动带上。这本来是好事但也会造成问题你做多用户并发时以为每个线程是独立用户实际上如果 cookie 管理器配置了共享就是共用一个会话。有些接口要求清空 cookie 重新登录结果旧 cookie 一直在干扰。所以要么明确在 HTTP Cookie Manager 里勾选每次迭代清除 Cookie要么在需要独立会话的场景加多个 cookie 管理器。Cookie 处理不好表现就是单跑没问题并发就失败这类问题排查起来特别隐蔽。7. 高并发压测落地从单机到分布式脚本调通、断言写好最后要落到真实压测。前面提到过一个典型场景把一套微服务环境整体迁移到云上迁移完要用 JMeter 脚本做高并发测试验证云环境的承载能力。这种场景对压测方案的要求比较高我结合这类项目经验讲几个要点。7.1 压测模型怎么设计才可靠压测模型的核心是模拟真实的用户行为。别上来就 1000 并发打某个接口那不叫压测叫攻击。合理的做法是梳理业务模型各个接口的调用比例是多少。真实用户不会只调一个接口下单和查询的比例可能差异很大按比例分配并发数。确定目标指标TPS 要达到多少、平均响应时间控制在多少、错误率不超过多少。有了指标才能判断压测是否达标。梯度加压从低并发开始逐级加压观察 TPS 和响应时间曲线。找到性能拐点也就是 TPS 不再随并发上升、响应时间开始飙升的那个点那才是系统的真实容量。稳定性测试在容量的 70%~80% 上持续压 1 到几小时看有没有内存泄漏、连接泄漏。这里有个容易被忽略的点迁移到云上后压测机和被测服务很可能在不同的网络区域。压测机到服务的网络延迟会算进响应时间导致数据失真。要么把压测机部署到同一区域要么单独测量网络延迟再扣除。7.2 插件扩展解决特殊协议MQTT、上传文件JMeter 标准包只覆盖 HTTP、JDBC、FTP 这些遇到 MQTT 这类物联网协议就得装插件。插件安装推荐用Plugins Manager装好后在界面里直接搜索 MQTT 插件安装比手动往 lib 目录拷 jar 包靠谱得多也不会因为版本不匹配报类冲突。MQTT 插件装好后添加 MQTT 连接配置、MQTT 发布和订阅取样器能模拟大量设备上报和接收消息这是物联网压测的常见需求。装插件后如果启动报ClassNotFoundException八成是 jar 包版本不匹配或者忘了重启 JMeter。文件上传测试要注意几点HTTP 请求里勾选对 POST 使用 multipart/form-data文件路径用参数化方式传入支持随机选不同大小的文件另外Files Upload区域填的 MIME 类型要对不然服务端可能拒收。上传大文件时记得调大 JMeter 堆内存否则文件本身就把内存吃光了。7.3 分布式压测与结果解读单机压测机再强也有上限端口数、CPU、内存都会成为瓶颈。当需要几千并发时得上分布式一台主控机master 多台执行机slave。主控机通过 RMI 把脚本分发下去各执行机跑完把结果回传汇总。分布式压测的坑主要集中在网络和配置上各机器的 JMeter 版本必须一致否则协议不兼容。jmeter-server配置文件里要指定主控机 IP 和监听端口。防火墙要放行 RMI 相关端口。各执行机的时间要同步否则结果时间戳对不上。脚本里用到的数据文件要分发到每台执行机上路径保持一致。结果解读上重点关注几个指标TPS、平均响应时间、90%/95% 响应时间、错误率。平均值容易被少数极慢的请求拉偏所以看分位数比看平均值更靠谱。聚合报告里那列 95% Line 表示 95% 的请求都在这个时间以下完成比平均时间更能反映大多数用户的体验。还有一点经验压测结果异常时先分清是被测服务的问题还是压测工具自身的问题。压测机的 CPU、内存、网络带宽、端口占用情况都要监控很多时候测出来 TPS 上不去是压测机先扛不住了。这一步不做很容易把压测机的瓶颈误判成服务的性能上限得出错误结论。最后分享一个我自己踩过的小经验。做环境迁移后的承载力验证时别只压迁移后的新环境最好把旧环境的同等压测数据拿出来做对比。因为很多性能问题不是迁移引入的而是旧环境本来就存在没有基线数据你根本判断不了迁移是成功还是失败。我就是因为提前在旧环境跑了一遍基准压测迁移后才迅速定位到是新环境某个服务的连接池默认配置偏小改完配置性能直接回到正常水位。
