JMeter分布式压测环境搭建

前言

在使用JMeter进行压测时，当被测接口需要很高的并发量，或者有些接口访问数很高的时候，Linux网络相关的内核参数需要根据实际服务进行调整，从而导致本地端口被占满，出现请求报错的情况。此时，本机的一些TCP配置、本机性能峰值就可能是性能测试的瓶颈点。 因此，本文梳理了基于JMeter的分布式压测环境的搭建方法，并能够满足参数化的需求。

JMeter分布式原理

1、JMeter分布式执行时，选择其中一台作为调度机（master），其他机器作为执行机（slave）； 2、本地编辑好jmx压测脚本，执行时，master会将jmx脚本分发到slave上，slave拿到脚本后以非GUI的形式开始执行； 3、slave执行完毕后将结果回传给master，并由master进行结果的汇总。

环境搭建方法

1、环境准备： 1) master：MacOS 10.13.2，JMeter版本5.1.1，jdk版本1.8； 2) slave：2台linux虚拟机，JMeter版本与master一致，5.1.1，jdk版本1.8 2、slave机器配置： 1) slave安装jdk和JMeter，并配置环境变量。尽量保持与master机器版本一致。两台slave机器jmeter的安装路径也保持一致，方便后续进行参数化配置； 2) 查看JMeter安装信息：

3）进入slave的bin目录下，执行./jmeter-server，启动JMeter服务。启动成功如下图：

3、master机器配置： 1）要保证master机器进行测试脚本的有效分发，需要配置slave机器的ip地址和端口号。在master安装目录的bin文件夹下，打开jmeter.properties文件，修改remote_hosts的值：

2）启动JMeter的GUI界面，在运行-远程启动选项中可以看到配置好的slave机器。

3）参数化配置： 参数文件路径必须为绝对路径，否则脚本执行时无法找到参数配置文件，因为调度机（master）分发jmx脚本，但不分发脚本中对应的参数文件。因此，需要手动上传参数文件至服务器指定地址。

问题及注意事项

1、FileNotFoundException。 在slave机器上启动jmeter或在master启动远程机器时，提示FileNotFoundException：

原因：自JMeter 4.0以来，RMI的默认传输机制将使用SSL。SSL需要密钥和证书才能工作。 解决方案（二选一）： 1）如果要在主从服务器之间使用安全通信，则需要启动create-rmi-keystore脚本（位于JMeter安装目录的“bin”文件夹中）。它会生成所需的rmi_keystore.jks文件。 2）将jmeter.properties的这行代码改为true，表示不使用SSL。 server.rmi.ssl.disable=true 2、线程数的设定。 最终的并发线程数=jmx脚本设定的线程数×slave机器数量 JMeter分布式测试，是通过网络连接将执行脚本分发至执行机器上去的，也就是每个执行机器拿到的脚本都是独立的，所以在每台执行机上都会启动脚本中线程组指定的并发线程数。 3、定时器的使用。 1）同步定时器（Synchronizing Timer）。该定时器的作用是，阻塞期望个数的线程（用户），在同时进行释放。从而提供瞬时加压的功能。那么在分布式中应如何使用呢？举个栗子： 在线程组中设定100个线程，同时增加同步计时器，期望达到200个线程时瞬间施压。

远程启动2台slave之后发现，没有发送任何请求。这是因为同步定时器仅在一个JVM中起作用，而分布式环境下两台机器属于2个独立的JVM。对于每个slave机器，都只启动了100个线程，没有达到瞬间释放压力的200个线程的阈值，因此不会执行。 因此在分布式的情况下，设定的阻塞线程数不能超过每个执行机器的并发线程数。本例中为100。 2）吞吐量定时器（Constant Throughput Timer）。由于脚本是分别在每个执行机进行运行的，所以限定的也都是当前作用的执行机。

结束语

由于JMeter是JAVA应用，对于CPU和内存的消耗较大，当使用本机进行压测时，对于高并发的压测，JMeter运行本身就会占用较多资源，从而极易成为性能测试瓶颈。使用多台服务器进行分压测试，将有效的减少本机对性能测试结果的影响。