共计 2586 个字符，预计需要花费 7 分钟才能阅读完成。
本文首发于：行者 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 自身就会耗费本机很多资源，再想增大并发，一台机器就会显得有心无力，很容易达性能瓶颈。应用分布式压测，能够无效缩小因本机性能对压测后果的影响。
