你是不是也有这种经历用 JMeter 在自己电脑上发压跑着跑着曲线开始锯齿状抖动系统没挂反而是你的压测机 CPU 先满了再往上加线程JMeter 自己先超时报错日志里滚出一堆java.io.IOException: Error writing to server。说白了单机压测有它自己都绕不过去的物理上限这时候就该考虑多服务器远程测试了——也就是 JMeter 的分布式压测模式。这篇文章就来拆解这件事为什么单机压不动、分布式压测是怎么设计出来的、主从节点怎么配、脚本怎么写、结果怎么收、最常见的Error writing to server这类报错又该怎么查。不管你是刚接触 JMeter 的性能测试新手还是已经压过几轮但一直被分布式配置折磨的老手按这一套往下走基本都能跑通。我还会顺手把我们在实际项目里踩过的坑、验证过有效的排查顺序一起放进来看完你就能少走不少弯路。1. 为什么单机压不动分布式压测的核心思路1.1 单机瓶颈到底卡在哪很多人以为压不动是 JMeter 本身的问题其实绝大多数情况下是负载机顶不住了。一台机器想产生高并发至少会在三个环节碰到瓶颈。第一个是端口限制。一条 TCP 连接就需要一个本地端口而 Linux 下默认的临时端口范围通常只有两三万个Windows 更是少得可怜。你用一台机器去压高并发接口连接数很容易就把端口池耗干新连接直接失败。第二个是协议栈和 CPU 中断。每发起一个 HTTP 请求都要经过系统调用、TCP 三次握手、TLS 握手、协议解析这些都要消耗 CPU 和内存。并发越高光处理网络包就能把一个核跑满。第三个是 JMeter 自身。它默认是 Java 写的线程模型、GC 停顿、结果落盘都会消耗资源。我实测过在配置一般的机器上纯线程数跑到 800 到 1000 左右JMeter 本身就开始出现采样延迟这时候压出来的响应时间已经失真了。还有一个很多人忽略的问题如果压测机和被测服务部署在同一台机器上或者共用网络出口压测结果会互相干扰。你没把系统压挂反而先把网络带宽打满了最后测出来的数据没有任何参考价值。1.2 分布式压测的工作模式JMeter 分布式压测的思路很直接用一个主控节点Master来统一调度多个执行节点Agent也叫 Slave来真正发请求。Master 只负责任务分发和结果收集不参与实际的请求发送Agent 各自独立运行压测脚本把采样结果回传给 Master。这里要强调一个关键点脚本在执行前会从 Master 分发到每个 Agent所以不要以为只有 Master 知道脚本内容就可以每个 Agent 上都必须具备运行脚本所需的所有依赖包括参数化文件、上传文件、CSV 数据源等。如果 Agent 上缺少这些文件压测执行时就会报错。Agent 之间是互相独立的所以理论上有多少台 Agent就能近似叠加多少倍的负载能力。比如一台 Agent 单机只能稳定产出 500 并发你上 5 台 Agent在理想情况下就能覆盖 2500 并发的规模。1.3 哪些场景必须上分布式我总结下来三类场景必须用分布式不是选项而是必选项。第一类是目标 QPS 超过单机负载能力。比如你的接口压测目标是一万 QPS单机发压能到三千就不行了分布式几乎是唯一解。第二类是压测对象在远端机房或云上。压测机离被测目标太远网络时延本身就会污染响应时间数据。比较稳妥的做法是在目标环境的同一网络区域部署多台 Agent让压力流量从内网发出去Master 放在你自己的电脑上就能远程控制整个压测。第三类是压测任务还需要同时覆盖多种混合场景。比如登录、查询、下单三个业务要按指定比例混合发压单机搞不定需要用多台 Agent 分摊不同业务流。2. 环境准备与架构配置要点2.1 版本与网络要求先明确一点Master 和所有 Agent 的 JMeter 版本必须一致这是最容易被忽略、也是最容易踩的坑。版本不一致经常引发两类问题一是 Agent 进程能启动但 Master 连上去就报协议错误二是结果能回传但部分采样数据丢失或解析异常。所以我的建议是所有节点统一用官网下载的最新稳定版不要用随便搜到的网盘版或修改版。JMeter 本身就是免安装的解压后检查一下JAVA_HOME即可JDK 版本按 JMeter 的要求配好通常 JDK 8 以上就能跑。网络方面Master 和 Agent 之间要走 RMI 协议默认端口是 1099。实际压测时建议把 Agent 放在和被压服务同一个内网里这样网络时延最小。Master 放在办公网络没关系它只负责调度命令和收结果流量不大。还有一个看似不起眼的问题所有节点的系统时间尽量保持同步。虽然 JMeter 统计响应时间用的是相对时间不受绝对时间影响但如果你在脚本里用了__time()函数做签名或者生成时间戳参数时间不一致会导致参数校验失败。2.2 主从节点配置参数说明配置主要在jmeter.properties里改先看 Master 端的核心参数# 指定所有 Agent 的地址和端口英文逗号分隔 remote_hosts192.168.1.10:1099,192.168.1.11:1099 # 推荐改为 BATCH 模式降低结果回传频率减少 Master 压力 modeBATCH两个 Agent 就用上面的写法如果只有一个 Agent写一个地址就行。注意这里写的是 Agent 的机器 IP不是 Master 自己的 IP。Agent 端需要改的关键参数如下# 关闭 RMI SSL简化配置测试环境建议生产环境请按安全规范评估 server.rmi.ssl.disabletrue # 固定 RMI 端口避免动态端口导致防火墙拦截 server.rmi.port1099 server.rmi.localport1099这里我把server.rmi.port和server.rmi.localport都设为 1099目的是让 RMI 的 registry 和本地导出对象使用同一个固定端口。如果你不设置localportJMeter 启动后可能会随机挑一个端口做 RMI 对象导出防火墙只放行 1099 的话Master 连上 registry 后回调时就会被拦住表现就是连接超时或者Error writing to server。关闭 SSL 这步很多人会纠结其实测试环境完全可以直接关简单省事。如果公司安全要求不能关那就得在主从节点都配好同一套 RMI 证书操作量会明显增加这里不展开建议先关 SSL 把链路跑通再考虑加固。2.3 启动 Agent 与验证连通性配置完成后逐个登录 Agent 机器进入 JMeter 的 bin 目录启动 Agent 进程cd /opt/jmeter/bin ./jmeter-server启动日志里如果出现类似Creating remote object和Starting RMIRegistry字样说明 Agent 已经就绪。需要注意的是在多网卡机器上JMeter 可能绑定到错误的网卡 IP导致 Master 连不上。这时候需要显式指定 IP./jmeter-server -Djava.rmi.server.hostname192.168.1.10或者先设置环境变量再启动export RMI_HOSTNAME192.168.1.10 ./jmeter-server验证连通性有两个办法。第一个办法是在 Master 上用 GUI 模式打开 JMeter点击运行菜单远程启动如果下拉菜单里能看到 Agent 列表说明基本通了。第二个办法是直接跑一条非 GUI 命令用-R参数指定远程节点跑完一个小脚本能生成结果文件就说明链路是通的。这里建议从第二条路开始因为 GUI 模式本身会占用 Master 资源不适合作为正式压测的入口。3. 实操过程与核心环节实现3.1 最小化分布式环境搭建我以最简单的两台机器为例演示完整搭建过程一台 Master、一台 Agent。假设 Master 的 IP 是192.168.1.100Agent 的 IP 是192.168.1.101两边的 JMeter 版本都是5.6.3。Agent 机器上解压 JMeter 后编辑bin/jmeter.properties把remote_hosts留空Agent 不需要作为 Master把以下两项加进去server.rmi.ssl.disabletrue server.rmi.port1099 server.rmi.localport1099然后启动 Agentcd /opt/jmeter/bin ./jmeter-server看到日志里出现端口监听信息Agent 端就绪。回到 Master 机器编辑bin/jmeter.propertiesremote_hosts192.168.1.101:1099 modeBATCH server.rmi.ssl.disabletrue确认本机能 ping 通 Agent防火墙放行了 1099 端口就可以准备执行脚本了。3.2 非 GUI 模式远程压测与结果收集正式压测一定不要开 GUI 窗口GUI 模式会消耗额外的内存和 CPU还会影响 Master 本身的表现。正确的姿势是直接用命令行执行。先准备一个测试脚本test.jmx然后运行jmeter -n -t /path/to/test.jmx -R 192.168.1.101:1099 -l /path/to/result.jtl -e -o /path/to/report这里几个参数逐个说清楚-n表示非 GUI 模式。-t指定测试脚本。-R指定远程 Agent 列表这是分布式执行的关键参数它会临时覆盖remote_hosts里的配置。如果你在jmeter.properties里已经写好了 Agent 列表这里可以改用-r小写效果是使用配置文件里的地址列表。-l指定结果文件路径。-e表示生成 HTML 报表。-o指定 HTML 报表输出目录这个目录不能已存在否则会报错建议每次执行前先删掉旧目录。执行过程中Master 终端会打出实时日志显示每个 Agent 执行到哪一步、错误数是否有增长。这里我特别提醒一下在分布式模式下所有 Agent 的采样结果都会回传到 Master再由 Master 统一写进 result.jtl 和报表。所以 Master 的磁盘写压力和内存占用也会随着 Agent 数量上升不要让 Master 磁盘被日志塞满。3.3 参数化文件与依赖资源的同步策略分布式压测的隐藏坑很大一部分在参数化文件上。比如你脚本里用了 CSV Data Set Config 来做用户参数化文件里有 10 万条用户名和密码。如果是单机压测只要本地路径正确就行但分布式模式下每个 Agent 都要能读到自己的那份数据文件。我见过的最常见的错误是只在 Master 上放了 CSV 文件Agent 一执行就报文件不存在或者所有 Agent 都取到了第一行数据。所以这里有三条经验可以直接抄一、CSV 文件最好使用相对路径并放在每个 Agent 的 JMeter bin 目录下。JMeter 对相对路径的解析以 bin 目录为基准所以统一把参数文件放在各节点的 bin 目录脚本里写users.csv而不是/opt/data/users.csv是最省心的分发方式。二、如果 CSV 文件很大比如几 GB直接把文件复制到每台 Agent 成本太高可以用共享存储NFS、云盘等挂载到相同路径所有 Agent 读取同一份数据。三、上传文件也是一样的道理。比如你的接口里有文件上传的采样器Files Upload里填了文件路径那么这个文件必须在每个 Agent 的对应路径存在否则 Agent 执行到该采样器时会报错。数据库参数化的情况也类似。如果你用 JDBC Request 查询数据库并把查询结果作为下一个接口的参数那需要在每个 Agent 上或者共享数据源上保持数据库连接可用。JDBC 请求里设置好连接池从查询结果集里取列值时注意在 JDBC Request 的 Variable Names 里定义好列名之后在后续请求里用${列名_1}、${列名_2}来引用。3.4 动态调整 QPS 与脚本编排很多压测场景不是一上来就打满而是需要阶梯加压比如先 100 QPS 跑 5 分钟再 500 QPS 跑 5 分钟最后 1000 QPS 跑 10 分钟。这个需求在分布式环境下会更复杂因为你要同时控制多台 Agent 的线程数。我的建议是优先用插件预置加压计划。JMeter 插件管理器里可以安装Ultimate Thread Group和Stepping Thread Group这两个线程组可以直接配置启动线程数、增压步长、持续时间和停止策略。脚本设计好之后所有 Agent 会按照相同的线程组配置同步增压效果跟动态调整 QPS 是一样的而且实现成本低很多也稳定。有的人会想用 BeanShell 或 BSF 脚本在运行过程中动态调整线程数比如通过bshclient远程调 JMeter 引擎的接口。我只能说这条路你能搜到不少案例但实际操作中很容易出问题因为在线程组启动后修改线程数并不是 JMeter 官方支持的标准操作脚本稍微写错就会导致整个测试中断。除非你对 JMeter 内部源码很熟否则不推荐在正式压测里这么干。如果确实有“压测过程中临时需要改变 QPS”的需求更稳妥的做法是把压测拆成多个阶段每个阶段用不同的-J参数传入属性来控制线程数。比如脚本里把线程数写成${__P(threads, 100)}执行时用jmeter -n -t test.jmx -R agent_ip:1099 -Jthreads500 -l stage1.jtl跑完第一阶段再改-Jthreads1000跑第二阶段。这种方式的缺点是要手动干预但胜在可控、不容易翻车。另外Beanshell 断言这个东西在分布式下也能用我一般用它来做一些复杂响应校验比如从响应里提取字段做多条件判断。注意 Beanshell 的兼容性一直一般JSR223 配上 Groovy 做脚本断言会更稳但这又是另一个话题了先不展开。4. 常见问题与排查技巧实录4.1java.io.IOException: Error writing to server完整排查这个报错在分布式压测里出现频率极高几乎每个用 JMeter 做多服务器远程测试的人都会遇到。它表面意思是写数据到服务端时发生了 IO 错误但背后原因可能五花八门我把实际排查顺序分享出来。第一步看 Agent 进程是否还活着。登录 Agent 机器执行ps -ef | grep jmeter-server如果进程没了看jmeter-server.log或者控制台输出多半是 Agent 崩溃了。压测过程中 Agent 崩溃最常见的原因是内存溢出需要调大 JVM 参数在jmeter脚本或者setenv.sh里改JVM_ARGS-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m第二步确认 1099 端口真的能被 Master 访问。在 Master 上用telnet agent_ip 1099试一下如果连不上去 Agent 防火墙里放行端口。我遇到过云主机安全组只放行了 SSH 端口压测时 RMI 被拦得死死的从 Master 看就是一直超时。第三步检查两端 SSL 配置是否一致。如果 Master 端server.rmi.ssl.disabletrueAgent 端没改两边握手不成功表现也是通信异常。所有节点统一把 SSL 关闭再启动一遍。第四步确认 Agent 的java.rmi.server.hostname是否指向了正确的 IP。多网卡机器上这个错误很隐蔽Agent 日志显示监听正常但 Master 就是连不上大概率是 Agent 注册到 registry 的地址不对。强制指定一次就能解决。我把这些原因整理成一张排查表方便你直接对照。现象可能原因解决方法连接超时、报错前一直卡住防火墙拦截 1099 端口放行 Agent 的 1099 端口保活一段时间后报错Agent 内存溢出或线程耗尽调大 JVM 堆内存降低单个 Agent 线程数日志显示监听正常但连不上多网卡绑定了错误 IP启动时指定-Djava.rmi.server.hostnameAgent实际IPSSL 握手异常主从 SSL 配置不一致统一设置server.rmi.ssl.disabletrue压测脚本执行到一半报错脚本中引用的文件在 Agent 上不存在参数文件、上传文件同步到所有 Agent4.2 CSV 文件找不到与数据不一致CSV 文件找不到这个问题本质上是脚本路径和实际环境不匹配。如果你在脚本里写的是/home/user/testdata.csv那么每台 Agent 上都必须存在这个绝对路径并且文件内容一致。如果写的是相对路径testdata.csv那么每台 Agent 都会去自己的 bin 目录下找你只需要把文件放到每个 Agent 的 bin 目录。还有一种数据不一致的情况Agent 从 CSV 里读数据时因为文件是各自独立读取的所以同一时刻不同 Agent 可能取到不同行这在多数场景下没问题。但如果你希望所有 Agent 对某个参数用同一份序列比如压测登录接口希望每次请求都用不同手机号就要仔细设计 CSV 的行数确保行数大于总请求数不然循环到文件末尾后JMeter 会回到第一行开始复读数据可能引发业务校验冲突。4.3 HTTPS 录制与防伪标记问题分布式压测没有单独的录制功能录制脚本还是得在本机用 JMeter 的 HTTP(S) Test Script Recorder 或第三方抓包工具完成。录制 HTTPS 请求时有几个细节要注意JMeter 会启动一个本地代理浏览器要配置信任 JMeter 的 CA 证书否则 HTTPS 流量抓不到。一般情况下JMeter 启动代理后会生成一个证书你可以用它的选项菜单导出并安装到系统证书库。录制过程中经常遇到一类问题目标系统是 ASP.NET MVC 之类的框架页面上有防伪标记__RequestVerificationToken录制完成后重放脚本会一直提示防伪标记无效。这个问题不管是不是分布式都会遇到处理办法是在脚本里加一个正则表达式提取器从上一个响应中提取新的 token填入后续请求的请求体或请求头里同时启用 HTTP Cookie Manager 保持会话 Cookie。这样脚本重放时每次拿到的是当前会话的有效 token而不是录制时的过期值。4.4 结果数据量过大导致 Master 内存暴涨分布式压测回传数据默认是按采样点单位传输的。如果并发高、压测时间长Master 需要处理成千上万条回传数据内存很容易吃紧。解决办法是把结果回传模式改成 BATCH 或 GROUP。在jmeter.properties里modeBATCHBATCH 模式下Agent 会攒够一定数量的样本再批量回传默认阈值是 100 条。这样网络传输次数从原来的每请求一次变成每 100 次请求一次Master 端的内存压力会小很多。如果对实时监控要求高就维持 STANDARD如果压测时间长优先用 BATCH。另外结果文件本身也会越来越大。建议在命令行里加一个策略每跑完一个阶段就单独生成一份 JTL不要所有阶段往一个文件里塞。JTL 生成之后用下面这条命令重新生成 HTML 报告避免再次执行压测jmeter -g /path/to/result.jtl -o /path/to/report如果觉得 JMeter 默认的 HTML 报告英文看着不顺眼可以修改 JMeter 安装目录下的bin/report-template里的 HTML 模板把标题、表头、按钮文案改成中文。注意升级 JMeter 版本后模板会被覆盖改过的话要做备份。5. 从单机到多机我的压测工程化经验5.1 一套可复用的分布式压测执行流程在多台服务器上跑 JMeter 远程测试只学会命令是不够的还得有一套能落地的流程。我自己的习惯是分成四步。第一步脚本先在单机跑通。不管是接口测试、业务链路还是文件上传、数据库参数化先在本地用单机模式把脚本跑一遍确认断言正确、参数取值正确、没有明显的业务报错。脚本都没调通就开分布式等于把错误放大 N 倍去查非常浪费时间。第二步小规模联调。先启动一台 Agent用-R指定这一台跑 1 分钟的小流量确认分布式链路通、结果文件正常生成。这一步一定要做尤其是第一次配置分布式环境的项目。我经常提醒团队别一上来就 10 台 Agent 一起压万一配置有问题日志和结果文件会是一片混乱根本分不清是哪个环节出了问题。第三步正式压测前做一次全链路预检。确认每台 Agent 的 JMeter 版本一致、SSL 配置一致、端口放行、JVM 参数合理、参数文件和上传文件已同步。预检这一步能用脚本固化下来比如写一个 Shell 脚本循环 ssh 到每台 Agent 检查 JMeter 版本和进程状态省得手动一台台登录。第四步执行压测并实时监控。执行过程中重点看三部分Master 日志有没有报错、Agent 机器 CPU 和内存有没有跑满、被压服务的监控指标是否正常。压测结果不是只看最后的 HTML 报告过程中的实时数据更能反映问题比如响应时间在哪个阶段开始劣化、错误率在哪个时间点突然上升。5.2 把分布式压测玩得更进阶的一些经验当你把基本的多服务器远程测试跑顺之后可以考虑把 Agent 容器化。我把 JMeter Agent 打成 Docker 镜像需要扩容时直接拉起新容器用完再销毁不用去维护实体机器。这种方式的收益在于压测规模可以动态调整今天压 1000 并发跑 2 台 Agent下周要压 5000 并发直接扩展到 10 台。Agent 容器化之后Master 不需要做太多改动只需要把remote_hosts换成容器所在宿主机的 IP 和映射端口。注意在容器里启动jmeter-server时同样要设置java.rmi.server.hostname为容器宿主机的可访问地址否则 Master 找不到它。另外容器里的 JMeter 需要和 Master 版本保持一致镜像构建时直接固定版本号。还有一点跟压测本身无关但很重要压测脚本要和代码一起放进版本管理。我刚接触 JMeter 的时候经常把 jmx 文件随手丢在桌面换台电脑就找不到了。后来在项目里定了规矩所有 jmx 脚本、CSV 数据源、测试计划文档全部进 Git版本变更留痕执行时从仓库拉取指定版本的脚本。这样不管谁接手都能快速知道当前环境跑的是哪版脚本。我个人在实际操作中的体会是分布式压测真正难的不是配置参数而是你有没有一套从脚本开发、小规模验证、全链路预检到正式执行的流程。配置报错多踩几次坑就会了但流程不规范的话每次压测都会像第一次一样慌乱。先把小规模跑通再逐步往大了加这是我在这个项目上最想分享的一条经验。
JMeter分布式压测实战：从单机瓶颈到多机远程测试
你是不是也有这种经历用 JMeter 在自己电脑上发压跑着跑着曲线开始锯齿状抖动系统没挂反而是你的压测机 CPU 先满了再往上加线程JMeter 自己先超时报错日志里滚出一堆java.io.IOException: Error writing to server。说白了单机压测有它自己都绕不过去的物理上限这时候就该考虑多服务器远程测试了——也就是 JMeter 的分布式压测模式。这篇文章就来拆解这件事为什么单机压不动、分布式压测是怎么设计出来的、主从节点怎么配、脚本怎么写、结果怎么收、最常见的Error writing to server这类报错又该怎么查。不管你是刚接触 JMeter 的性能测试新手还是已经压过几轮但一直被分布式配置折磨的老手按这一套往下走基本都能跑通。我还会顺手把我们在实际项目里踩过的坑、验证过有效的排查顺序一起放进来看完你就能少走不少弯路。1. 为什么单机压不动分布式压测的核心思路1.1 单机瓶颈到底卡在哪很多人以为压不动是 JMeter 本身的问题其实绝大多数情况下是负载机顶不住了。一台机器想产生高并发至少会在三个环节碰到瓶颈。第一个是端口限制。一条 TCP 连接就需要一个本地端口而 Linux 下默认的临时端口范围通常只有两三万个Windows 更是少得可怜。你用一台机器去压高并发接口连接数很容易就把端口池耗干新连接直接失败。第二个是协议栈和 CPU 中断。每发起一个 HTTP 请求都要经过系统调用、TCP 三次握手、TLS 握手、协议解析这些都要消耗 CPU 和内存。并发越高光处理网络包就能把一个核跑满。第三个是 JMeter 自身。它默认是 Java 写的线程模型、GC 停顿、结果落盘都会消耗资源。我实测过在配置一般的机器上纯线程数跑到 800 到 1000 左右JMeter 本身就开始出现采样延迟这时候压出来的响应时间已经失真了。还有一个很多人忽略的问题如果压测机和被测服务部署在同一台机器上或者共用网络出口压测结果会互相干扰。你没把系统压挂反而先把网络带宽打满了最后测出来的数据没有任何参考价值。1.2 分布式压测的工作模式JMeter 分布式压测的思路很直接用一个主控节点Master来统一调度多个执行节点Agent也叫 Slave来真正发请求。Master 只负责任务分发和结果收集不参与实际的请求发送Agent 各自独立运行压测脚本把采样结果回传给 Master。这里要强调一个关键点脚本在执行前会从 Master 分发到每个 Agent所以不要以为只有 Master 知道脚本内容就可以每个 Agent 上都必须具备运行脚本所需的所有依赖包括参数化文件、上传文件、CSV 数据源等。如果 Agent 上缺少这些文件压测执行时就会报错。Agent 之间是互相独立的所以理论上有多少台 Agent就能近似叠加多少倍的负载能力。比如一台 Agent 单机只能稳定产出 500 并发你上 5 台 Agent在理想情况下就能覆盖 2500 并发的规模。1.3 哪些场景必须上分布式我总结下来三类场景必须用分布式不是选项而是必选项。第一类是目标 QPS 超过单机负载能力。比如你的接口压测目标是一万 QPS单机发压能到三千就不行了分布式几乎是唯一解。第二类是压测对象在远端机房或云上。压测机离被测目标太远网络时延本身就会污染响应时间数据。比较稳妥的做法是在目标环境的同一网络区域部署多台 Agent让压力流量从内网发出去Master 放在你自己的电脑上就能远程控制整个压测。第三类是压测任务还需要同时覆盖多种混合场景。比如登录、查询、下单三个业务要按指定比例混合发压单机搞不定需要用多台 Agent 分摊不同业务流。2. 环境准备与架构配置要点2.1 版本与网络要求先明确一点Master 和所有 Agent 的 JMeter 版本必须一致这是最容易被忽略、也是最容易踩的坑。版本不一致经常引发两类问题一是 Agent 进程能启动但 Master 连上去就报协议错误二是结果能回传但部分采样数据丢失或解析异常。所以我的建议是所有节点统一用官网下载的最新稳定版不要用随便搜到的网盘版或修改版。JMeter 本身就是免安装的解压后检查一下JAVA_HOME即可JDK 版本按 JMeter 的要求配好通常 JDK 8 以上就能跑。网络方面Master 和 Agent 之间要走 RMI 协议默认端口是 1099。实际压测时建议把 Agent 放在和被压服务同一个内网里这样网络时延最小。Master 放在办公网络没关系它只负责调度命令和收结果流量不大。还有一个看似不起眼的问题所有节点的系统时间尽量保持同步。虽然 JMeter 统计响应时间用的是相对时间不受绝对时间影响但如果你在脚本里用了__time()函数做签名或者生成时间戳参数时间不一致会导致参数校验失败。2.2 主从节点配置参数说明配置主要在jmeter.properties里改先看 Master 端的核心参数# 指定所有 Agent 的地址和端口英文逗号分隔 remote_hosts192.168.1.10:1099,192.168.1.11:1099 # 推荐改为 BATCH 模式降低结果回传频率减少 Master 压力 modeBATCH两个 Agent 就用上面的写法如果只有一个 Agent写一个地址就行。注意这里写的是 Agent 的机器 IP不是 Master 自己的 IP。Agent 端需要改的关键参数如下# 关闭 RMI SSL简化配置测试环境建议生产环境请按安全规范评估 server.rmi.ssl.disabletrue # 固定 RMI 端口避免动态端口导致防火墙拦截 server.rmi.port1099 server.rmi.localport1099这里我把server.rmi.port和server.rmi.localport都设为 1099目的是让 RMI 的 registry 和本地导出对象使用同一个固定端口。如果你不设置localportJMeter 启动后可能会随机挑一个端口做 RMI 对象导出防火墙只放行 1099 的话Master 连上 registry 后回调时就会被拦住表现就是连接超时或者Error writing to server。关闭 SSL 这步很多人会纠结其实测试环境完全可以直接关简单省事。如果公司安全要求不能关那就得在主从节点都配好同一套 RMI 证书操作量会明显增加这里不展开建议先关 SSL 把链路跑通再考虑加固。2.3 启动 Agent 与验证连通性配置完成后逐个登录 Agent 机器进入 JMeter 的 bin 目录启动 Agent 进程cd /opt/jmeter/bin ./jmeter-server启动日志里如果出现类似Creating remote object和Starting RMIRegistry字样说明 Agent 已经就绪。需要注意的是在多网卡机器上JMeter 可能绑定到错误的网卡 IP导致 Master 连不上。这时候需要显式指定 IP./jmeter-server -Djava.rmi.server.hostname192.168.1.10或者先设置环境变量再启动export RMI_HOSTNAME192.168.1.10 ./jmeter-server验证连通性有两个办法。第一个办法是在 Master 上用 GUI 模式打开 JMeter点击运行菜单远程启动如果下拉菜单里能看到 Agent 列表说明基本通了。第二个办法是直接跑一条非 GUI 命令用-R参数指定远程节点跑完一个小脚本能生成结果文件就说明链路是通的。这里建议从第二条路开始因为 GUI 模式本身会占用 Master 资源不适合作为正式压测的入口。3. 实操过程与核心环节实现3.1 最小化分布式环境搭建我以最简单的两台机器为例演示完整搭建过程一台 Master、一台 Agent。假设 Master 的 IP 是192.168.1.100Agent 的 IP 是192.168.1.101两边的 JMeter 版本都是5.6.3。Agent 机器上解压 JMeter 后编辑bin/jmeter.properties把remote_hosts留空Agent 不需要作为 Master把以下两项加进去server.rmi.ssl.disabletrue server.rmi.port1099 server.rmi.localport1099然后启动 Agentcd /opt/jmeter/bin ./jmeter-server看到日志里出现端口监听信息Agent 端就绪。回到 Master 机器编辑bin/jmeter.propertiesremote_hosts192.168.1.101:1099 modeBATCH server.rmi.ssl.disabletrue确认本机能 ping 通 Agent防火墙放行了 1099 端口就可以准备执行脚本了。3.2 非 GUI 模式远程压测与结果收集正式压测一定不要开 GUI 窗口GUI 模式会消耗额外的内存和 CPU还会影响 Master 本身的表现。正确的姿势是直接用命令行执行。先准备一个测试脚本test.jmx然后运行jmeter -n -t /path/to/test.jmx -R 192.168.1.101:1099 -l /path/to/result.jtl -e -o /path/to/report这里几个参数逐个说清楚-n表示非 GUI 模式。-t指定测试脚本。-R指定远程 Agent 列表这是分布式执行的关键参数它会临时覆盖remote_hosts里的配置。如果你在jmeter.properties里已经写好了 Agent 列表这里可以改用-r小写效果是使用配置文件里的地址列表。-l指定结果文件路径。-e表示生成 HTML 报表。-o指定 HTML 报表输出目录这个目录不能已存在否则会报错建议每次执行前先删掉旧目录。执行过程中Master 终端会打出实时日志显示每个 Agent 执行到哪一步、错误数是否有增长。这里我特别提醒一下在分布式模式下所有 Agent 的采样结果都会回传到 Master再由 Master 统一写进 result.jtl 和报表。所以 Master 的磁盘写压力和内存占用也会随着 Agent 数量上升不要让 Master 磁盘被日志塞满。3.3 参数化文件与依赖资源的同步策略分布式压测的隐藏坑很大一部分在参数化文件上。比如你脚本里用了 CSV Data Set Config 来做用户参数化文件里有 10 万条用户名和密码。如果是单机压测只要本地路径正确就行但分布式模式下每个 Agent 都要能读到自己的那份数据文件。我见过的最常见的错误是只在 Master 上放了 CSV 文件Agent 一执行就报文件不存在或者所有 Agent 都取到了第一行数据。所以这里有三条经验可以直接抄一、CSV 文件最好使用相对路径并放在每个 Agent 的 JMeter bin 目录下。JMeter 对相对路径的解析以 bin 目录为基准所以统一把参数文件放在各节点的 bin 目录脚本里写users.csv而不是/opt/data/users.csv是最省心的分发方式。二、如果 CSV 文件很大比如几 GB直接把文件复制到每台 Agent 成本太高可以用共享存储NFS、云盘等挂载到相同路径所有 Agent 读取同一份数据。三、上传文件也是一样的道理。比如你的接口里有文件上传的采样器Files Upload里填了文件路径那么这个文件必须在每个 Agent 的对应路径存在否则 Agent 执行到该采样器时会报错。数据库参数化的情况也类似。如果你用 JDBC Request 查询数据库并把查询结果作为下一个接口的参数那需要在每个 Agent 上或者共享数据源上保持数据库连接可用。JDBC 请求里设置好连接池从查询结果集里取列值时注意在 JDBC Request 的 Variable Names 里定义好列名之后在后续请求里用${列名_1}、${列名_2}来引用。3.4 动态调整 QPS 与脚本编排很多压测场景不是一上来就打满而是需要阶梯加压比如先 100 QPS 跑 5 分钟再 500 QPS 跑 5 分钟最后 1000 QPS 跑 10 分钟。这个需求在分布式环境下会更复杂因为你要同时控制多台 Agent 的线程数。我的建议是优先用插件预置加压计划。JMeter 插件管理器里可以安装Ultimate Thread Group和Stepping Thread Group这两个线程组可以直接配置启动线程数、增压步长、持续时间和停止策略。脚本设计好之后所有 Agent 会按照相同的线程组配置同步增压效果跟动态调整 QPS 是一样的而且实现成本低很多也稳定。有的人会想用 BeanShell 或 BSF 脚本在运行过程中动态调整线程数比如通过bshclient远程调 JMeter 引擎的接口。我只能说这条路你能搜到不少案例但实际操作中很容易出问题因为在线程组启动后修改线程数并不是 JMeter 官方支持的标准操作脚本稍微写错就会导致整个测试中断。除非你对 JMeter 内部源码很熟否则不推荐在正式压测里这么干。如果确实有“压测过程中临时需要改变 QPS”的需求更稳妥的做法是把压测拆成多个阶段每个阶段用不同的-J参数传入属性来控制线程数。比如脚本里把线程数写成${__P(threads, 100)}执行时用jmeter -n -t test.jmx -R agent_ip:1099 -Jthreads500 -l stage1.jtl跑完第一阶段再改-Jthreads1000跑第二阶段。这种方式的缺点是要手动干预但胜在可控、不容易翻车。另外Beanshell 断言这个东西在分布式下也能用我一般用它来做一些复杂响应校验比如从响应里提取字段做多条件判断。注意 Beanshell 的兼容性一直一般JSR223 配上 Groovy 做脚本断言会更稳但这又是另一个话题了先不展开。4. 常见问题与排查技巧实录4.1java.io.IOException: Error writing to server完整排查这个报错在分布式压测里出现频率极高几乎每个用 JMeter 做多服务器远程测试的人都会遇到。它表面意思是写数据到服务端时发生了 IO 错误但背后原因可能五花八门我把实际排查顺序分享出来。第一步看 Agent 进程是否还活着。登录 Agent 机器执行ps -ef | grep jmeter-server如果进程没了看jmeter-server.log或者控制台输出多半是 Agent 崩溃了。压测过程中 Agent 崩溃最常见的原因是内存溢出需要调大 JVM 参数在jmeter脚本或者setenv.sh里改JVM_ARGS-Xms4g -Xmx4g -XX:MaxMetaspaceSize512m第二步确认 1099 端口真的能被 Master 访问。在 Master 上用telnet agent_ip 1099试一下如果连不上去 Agent 防火墙里放行端口。我遇到过云主机安全组只放行了 SSH 端口压测时 RMI 被拦得死死的从 Master 看就是一直超时。第三步检查两端 SSL 配置是否一致。如果 Master 端server.rmi.ssl.disabletrueAgent 端没改两边握手不成功表现也是通信异常。所有节点统一把 SSL 关闭再启动一遍。第四步确认 Agent 的java.rmi.server.hostname是否指向了正确的 IP。多网卡机器上这个错误很隐蔽Agent 日志显示监听正常但 Master 就是连不上大概率是 Agent 注册到 registry 的地址不对。强制指定一次就能解决。我把这些原因整理成一张排查表方便你直接对照。现象可能原因解决方法连接超时、报错前一直卡住防火墙拦截 1099 端口放行 Agent 的 1099 端口保活一段时间后报错Agent 内存溢出或线程耗尽调大 JVM 堆内存降低单个 Agent 线程数日志显示监听正常但连不上多网卡绑定了错误 IP启动时指定-Djava.rmi.server.hostnameAgent实际IPSSL 握手异常主从 SSL 配置不一致统一设置server.rmi.ssl.disabletrue压测脚本执行到一半报错脚本中引用的文件在 Agent 上不存在参数文件、上传文件同步到所有 Agent4.2 CSV 文件找不到与数据不一致CSV 文件找不到这个问题本质上是脚本路径和实际环境不匹配。如果你在脚本里写的是/home/user/testdata.csv那么每台 Agent 上都必须存在这个绝对路径并且文件内容一致。如果写的是相对路径testdata.csv那么每台 Agent 都会去自己的 bin 目录下找你只需要把文件放到每个 Agent 的 bin 目录。还有一种数据不一致的情况Agent 从 CSV 里读数据时因为文件是各自独立读取的所以同一时刻不同 Agent 可能取到不同行这在多数场景下没问题。但如果你希望所有 Agent 对某个参数用同一份序列比如压测登录接口希望每次请求都用不同手机号就要仔细设计 CSV 的行数确保行数大于总请求数不然循环到文件末尾后JMeter 会回到第一行开始复读数据可能引发业务校验冲突。4.3 HTTPS 录制与防伪标记问题分布式压测没有单独的录制功能录制脚本还是得在本机用 JMeter 的 HTTP(S) Test Script Recorder 或第三方抓包工具完成。录制 HTTPS 请求时有几个细节要注意JMeter 会启动一个本地代理浏览器要配置信任 JMeter 的 CA 证书否则 HTTPS 流量抓不到。一般情况下JMeter 启动代理后会生成一个证书你可以用它的选项菜单导出并安装到系统证书库。录制过程中经常遇到一类问题目标系统是 ASP.NET MVC 之类的框架页面上有防伪标记__RequestVerificationToken录制完成后重放脚本会一直提示防伪标记无效。这个问题不管是不是分布式都会遇到处理办法是在脚本里加一个正则表达式提取器从上一个响应中提取新的 token填入后续请求的请求体或请求头里同时启用 HTTP Cookie Manager 保持会话 Cookie。这样脚本重放时每次拿到的是当前会话的有效 token而不是录制时的过期值。4.4 结果数据量过大导致 Master 内存暴涨分布式压测回传数据默认是按采样点单位传输的。如果并发高、压测时间长Master 需要处理成千上万条回传数据内存很容易吃紧。解决办法是把结果回传模式改成 BATCH 或 GROUP。在jmeter.properties里modeBATCHBATCH 模式下Agent 会攒够一定数量的样本再批量回传默认阈值是 100 条。这样网络传输次数从原来的每请求一次变成每 100 次请求一次Master 端的内存压力会小很多。如果对实时监控要求高就维持 STANDARD如果压测时间长优先用 BATCH。另外结果文件本身也会越来越大。建议在命令行里加一个策略每跑完一个阶段就单独生成一份 JTL不要所有阶段往一个文件里塞。JTL 生成之后用下面这条命令重新生成 HTML 报告避免再次执行压测jmeter -g /path/to/result.jtl -o /path/to/report如果觉得 JMeter 默认的 HTML 报告英文看着不顺眼可以修改 JMeter 安装目录下的bin/report-template里的 HTML 模板把标题、表头、按钮文案改成中文。注意升级 JMeter 版本后模板会被覆盖改过的话要做备份。5. 从单机到多机我的压测工程化经验5.1 一套可复用的分布式压测执行流程在多台服务器上跑 JMeter 远程测试只学会命令是不够的还得有一套能落地的流程。我自己的习惯是分成四步。第一步脚本先在单机跑通。不管是接口测试、业务链路还是文件上传、数据库参数化先在本地用单机模式把脚本跑一遍确认断言正确、参数取值正确、没有明显的业务报错。脚本都没调通就开分布式等于把错误放大 N 倍去查非常浪费时间。第二步小规模联调。先启动一台 Agent用-R指定这一台跑 1 分钟的小流量确认分布式链路通、结果文件正常生成。这一步一定要做尤其是第一次配置分布式环境的项目。我经常提醒团队别一上来就 10 台 Agent 一起压万一配置有问题日志和结果文件会是一片混乱根本分不清是哪个环节出了问题。第三步正式压测前做一次全链路预检。确认每台 Agent 的 JMeter 版本一致、SSL 配置一致、端口放行、JVM 参数合理、参数文件和上传文件已同步。预检这一步能用脚本固化下来比如写一个 Shell 脚本循环 ssh 到每台 Agent 检查 JMeter 版本和进程状态省得手动一台台登录。第四步执行压测并实时监控。执行过程中重点看三部分Master 日志有没有报错、Agent 机器 CPU 和内存有没有跑满、被压服务的监控指标是否正常。压测结果不是只看最后的 HTML 报告过程中的实时数据更能反映问题比如响应时间在哪个阶段开始劣化、错误率在哪个时间点突然上升。5.2 把分布式压测玩得更进阶的一些经验当你把基本的多服务器远程测试跑顺之后可以考虑把 Agent 容器化。我把 JMeter Agent 打成 Docker 镜像需要扩容时直接拉起新容器用完再销毁不用去维护实体机器。这种方式的收益在于压测规模可以动态调整今天压 1000 并发跑 2 台 Agent下周要压 5000 并发直接扩展到 10 台。Agent 容器化之后Master 不需要做太多改动只需要把remote_hosts换成容器所在宿主机的 IP 和映射端口。注意在容器里启动jmeter-server时同样要设置java.rmi.server.hostname为容器宿主机的可访问地址否则 Master 找不到它。另外容器里的 JMeter 需要和 Master 版本保持一致镜像构建时直接固定版本号。还有一点跟压测本身无关但很重要压测脚本要和代码一起放进版本管理。我刚接触 JMeter 的时候经常把 jmx 文件随手丢在桌面换台电脑就找不到了。后来在项目里定了规矩所有 jmx 脚本、CSV 数据源、测试计划文档全部进 Git版本变更留痕执行时从仓库拉取指定版本的脚本。这样不管谁接手都能快速知道当前环境跑的是哪版脚本。我个人在实际操作中的体会是分布式压测真正难的不是配置参数而是你有没有一套从脚本开发、小规模验证、全链路预检到正式执行的流程。配置报错多踩几次坑就会了但流程不规范的话每次压测都会像第一次一样慌乱。先把小规模跑通再逐步往大了加这是我在这个项目上最想分享的一条经验。
