本文首发于：行者AI

在我的项目中咱们常常会有压测的需要，而玲珑轻便且收费的JMeter也趁势成为了咱们的支流压测工具。

JMeter是Apache组织开发的开源我的项目，设计之初是用于做性能测试的，同时它在实现对各种接口的调用方面做得比拟成熟，因而，常被用作接口功能测试和性能测试。它可能很好的反对各种常见接口，如HTTP(S)、WebService、JDBC、FTP等、并以多种形式展现测试后果。

然而，在应用JMeter进行压测时，单机受限于内存，CPU，网络IO。咱们发现当被测接口须要很高的并发量，或者有些接口拜访数很高的时候，很容易就导致本地端口被占满，呈现申请报错的状况。此时，本地的一些TCP配置、性能峰值就可能成为性能测试的瓶颈点。（服务器还没被压崩，本地曾经崩了== ）

因而，本文梳理了基于JMeter的分布式压测环境的搭建办法来解决这个问题，并可能满足参数化的需要。

1. Jmeter分布式执行原理

JMeter分布式执行时，抉择其中一台作为调度机（master），其余机器作为执行机（slave）；

master会在本地编辑好jmx压测脚本，执行时，master将jmx脚本发送至slave上，slaver执行时不须要启动jmeter，只须要把jmeter-sever.bat文件关上以非GUI模式执行；

slave执行结束后将后果回传给master，并由master进行后果的汇总；

简略来说能达到的成果也就是：比方我在JMeter jmx脚本中设立的线程数是100，我在本地单机运行就会产生100次申请。如果我有1台master机器，2台slave机器，那么每次会向服务器发送的申请数总共就是100*3次。

2. 环境搭建办法

2.1 环境筹备

（1）master：JMeter版本5.1.1，jdk版本1.8；

（2）slave：另外1台测试机，JMeter版本5.1.1，jdk版本1.8；

留神：JMeter和jdk版本与master统一，否则会呈现一些意外的问题。具体的装置教程就不在这里做赘述了，网上有很多参考文章，可自行查阅。

2.2 master机器配置

（1）要保障master机器进行测试脚本的无效散发，须要配置slave机器的ip地址和端口号。在master装置目录的bin文件下，关上Jmeter/bin/jmeter.properties，找到remote_hosts=127.0.0.1的值并做批改：

PS：若有多台近程机须要都加进来，用逗号隔开，后面127.0.0.1为本机，默认端口为1099（可自定义）

（2）参数化配置

参数文件必须为绝对路径，否则脚本执行时无奈找到参数配置文件，因为master调度机在散发jmx脚本时，不会散发脚本中对应的参数文件。因而，须要手动将参数文件分发给slave机器（并且放在绝对路径下对应的地位，不然slave会找不到文件）

2.3 slave机器的配置

（1）slave装置jdk和JMeter，并配置环境变量。尽量放弃与master机器版本统一。两台slave机器JMeter的装置门路也保持一致，不便后续进行参数化配置；

（2）在Slave机器上，找到Jmeter/bin/jmeter.properties设置：server_port=1099；

（3）进入slave的bin目录下，执行jmeter-server.bat，启动JMeter服务；启动胜利如下图：

2.4 验证分布式环境是否搭建胜利

启动master机器中JMeter的GUI界面，在运行-近程启动选项中能够看到配置好的slave机器，此时阐明曾经连贯上近程slave机器。

如果你的环境在抉择全副启动之后，没有报错，且发动申请数量和事后jmx设置的线程数统一，阐明JMeter分布式测试环境搭建胜利，能够开始测试了。

3. 问题及注意事项

  • master和slave必须是在同一网段；
  • 敞开防火墙；
  • 在master启动近程机器时，提醒FileNotFoundException；

起因：自JMeter 4.0以来，RMI的默认传输机制将应用ssl协定。ssl协定须要密钥和证书能力工作。

解决方案：在Jmeter/bin/jmeter.properties中，找到server.rmi.ssl.disable，并设置：server.rmi.ssl.disable=true，示意不应用ssl。master和salve都得批改。

线程数的设定；

最终的并发线程数=jmx脚本设定的并发数*salve机器数量

JMeter分布式测试，是通过网络连接将执行脚本散发至机器下来的，也就是每个执行机拿到的脚本都是独立的，都会去执行jmx中设定的并发数。

同步定时器的应用；

该定时器的作用是用来设置集合点，从而阻塞线程，直到指定的线程数量达到后，再一起开释，能够霎时产生很大的压力。那么在分布式中是怎么来利用的呢？

举个栗子：

咱们在一个线程组中设立线程数为100，因为有3台slave，因而咱们冀望刹时并发能达到300，故减少了一个固定定时器，并冀望达到300的刹时并发，如下图：

启用3台slave机器之后发现，并没有任何申请。这是因为同步定时器的设置只在以后的jvm中起作用，而3台 slave则是3个独立的jvm，而同步定时器是须要在线程数达到设置的线程数后才会开释，若没有达到就会始终死 等。显然每台独立的slave永远也不会达到300的线程数，因为每台slave设置的线程数也才100，所以不会执行。 因而， 在分布式的状况下，设立的同步定时器中的阻塞线程数不要大于每个jvm中启用的线程数。

slave机过了一段时间打印了“starting...”之后，始终没有变动，也没有finish，master机也没有执行后果；

查看JMeter-sever.log发现：connection refused to host：172.2x.xxx.x....

那该IP又是从哪里来的呢？最终发现，该IP为虚拟机网... 解决方案：如果近程负载机有虚构网络，须要敞开虚构网络。

论断：JMeter是JAVA利用，对于内存和CPU的占用较大，当应用单机进行测试时，对于高并发的压测，JMeter自身就会耗费本机很多资源，再想增大并发，一台机器就会显得有心无力，很容易达性能瓶颈。应用分布式压测，能够无效缩小因本机性能对压测后果的影响。