JMeter 是性能测试的利器，而分布式压测更是应对高并发场景的必备技能。然而，在实际部署中，初学者常遇到种种问题，导致压测效果不理想甚至失败。你是否也曾因配置错误而耗费时间？别急，这篇文章为你全面解析 JMeter 分布式压测的“坑”与“解法”！

JMeter 分布式压测有哪些常见问题？如何避免这些“坑”，快速完成性能测试部署？

随着互联网应用场景的复杂化，大规模并发性能测试需求不断增加。分布式压测是性能测试的核心手段之一，但部署和配置中的问题却成为很多测试人员的绊脚石。熟悉常见问题和优化方法是每位性能测试工程师的必修课。

我经常会遇到一些学生跟我聊性能测试工具Jmeter不好用，我问为什么不好用，他说压力稍微大一些就上不去报错了。一看报错信息就是地址被占用了。

这就是典型的分布式的需求了。如果做性能测试，这个基本的问题都不会解决的话，那么表示性能测试你还没有入门哦！

性能测试为什么需要分布式？

我们做性能测试的工具Jmeter是安装在电脑或者服务器机器上的，不管是windows的电脑还是Linux系统机器，能够被使用的端口都是有限的，理论上的最大值 65535个，但是实际上都还到不了这个值：

• linux机器： 默认的时候理论上可用的端口大概有3w个左右
• windows机器： 默认的时候理论上只有 大于 1w+多个端口
  • 因为windows机器作为图像界面系统，就是为 普通用户使用， 一般用不了 很多端口。

然而，我们接口发送请求所用的协议是HTTP协议，这个协议特点：

• 默认是一个长连接【connection= keep-alive】。所以，每一个请求占用一个端口，而这个请求因为是长连接还会保持一段时间，不会立马释放这个端口。这就导致机器上的端口快速被消耗完。
• http协议是一个同步协议，一个请求发送完，一定要等收到响应了才发送下一个请求，所以如果服务器的性能越好，服务器能短时间内处理大量的请求，Jmeter客户端的端口就更快被消耗完，所以服务器性能越好，Jmeter能产生的并发用户数反而越少。

而实际项目有可能接口性能比较好，能超过2000并发用户数，这就会超过1个Jmeter客户端能产生的并发用户数。这个时候，我们就需要通过增加Jmeter的机器来产生更多的并发用户数。这就是分布式。

分布式的原理

按照上面讲的分析，分布式就是为了增加客户机对服务器执行并发请求，突破单个机器的瓶颈。分布式的配置图如下：

• 1、一台主控制/调度机【Controller/Master】， 多台机器为执行机/助攻机【Slave/Agent】
• 2、执行的时候master会把脚本发送到助攻机上，每个助攻机拿到脚本后开始在还行
  • 注意每台助攻机上都需要有Jmeter安装环境；
  • Jmeter不需要启动gui界面，直接用cli命令行执行；
  • 助攻机会用Linux/windows/macOS都可以，一般推荐用同种机器。
• 3、执行完成后，slave会把结果传回给master，master会收集所有的salve信息会汇总显示。

所以，性能测试脚本只需要管理者在主控制机上维护和修改变更就可以。假设管理者把线程数变了。每个助攻机的执行者就都按照新的线程数来产生并发用户数。

分布式环境搭建

前提条件准备：

• 主机和助攻机器jmeter的版本要相同，jdk要主版本要一致。
• Jmeter的csv的脚本相对路径的启始点一致。
• Jmeter的插件要一致 。
• 所有的主控机和助攻机都必须用有线连接网络，同一局域网。

助攻机的配置：

修改Jmeter的配置文件：jmeter.properties

• 修改 server_port 端口 ：默认是1099， 可以不改，也可以修改为自己定义的；
• 修改 server.rmi.port 端口 ： 可以不改，如果改就改成和上面相同
• 去掉认证 server.rmi.ssl.disable=true 不使用加密认证传输数据

完成这些修改，并保存文件，助攻机器的配置完成。保证每台助攻机器都同样的配置。

主控机的配置：

修改配置文件：jmeter.properties

• remote_hosts=助攻机器ip:端口 ，如果有多个助攻机器信息之间用逗号分开 ；
• 去掉认证：server.rmi.ssl.disable=true

确认模式：mode=Standard 这个属性，主控和助攻机器之间，使用通用的标准的数据交换方式。

注意： 修改属性配置文件，一定要保存文件，然后重启jmeter才生效

启动助攻机，启动命令：

windows：

jmeter-server.bat -Djava.rmi.server.hostname=机器ip

linux: 

./jmeter-server -Djava.rmi.server.hostname=192.168.3.134

配置完成后，可以在jmeter图形界面中，看到助攻机器传回来的数据。

点击上图的启动远程可以启动主动机开始跑脚本。可以启动部分，也可以同时启动所有助攻机跑脚本。如此就完美解决了一台客户机运行报错压力上不去的问题。

---

做性能测试的时候分布式是经常会使用的一种压测方案，但是很多同学在部署分布式压测环境的时候会出现各种问题，今天我们这篇文章就给大家把一些分布式搭建过程中的常见问题以及对应的解决方案进行汇总。

常见错误和解决方案

错误1： 在主控机器下面远程启动助攻机的时候报错：

解决方案： 这个链接超时，原因可能有2个：

1）你的主控机和助攻机的网络不通，检查一下网络的连通性：master端和slave端要ping通

2）ping通后，telnet ip port （Linux端），看一下1099端口是否被占用 【如果你修改了端口，就测试你修改后的端口】

3）你的助攻机服务没有启动： 使用./jmeter-server -D java.rmi.server.hostname=助攻机IP地址 启动你的助攻机

错误2：启动助攻机的时候报错Engine is busy-please try later.

解决方案：这是因为助攻机上之前执行过脚本，可能处于繁忙状态。解决方案：

1）在停止jmeter测试的同时，使用master中的' Remote Stop all '选项，这会杀死远程机进程上正在运行的线程。或者直接在助攻机上 使用kill -9 进程号杀掉进程；

2）助攻机上的服务重启一下，也就是重新启动助攻机的服务器： ./jmeter-server -D java.rmi.server.hostname=助攻机IP地址
3）远程机的jmeter重新启动“jmeter-server.bat”，并重新开始测试。

错误3：脚本运行的过程中不报错，但是就是卡住无法收集到结果。

启动remote测试后，Agent机器收到任务，且控制台显示：”Starting the test on host 192.168.1.130:1099@***“，说明控制机分派上agent机上的测试成功，但是 一直卡在这里不动了，控制机一直没有显示任务执行状况以及收到测试结果（任务一直不结束，卡住了）。

解决方案： 这个问题的原因我们可以通过助攻机上的 查apache-jmeter-5.2.1\bin 中 jmeter-server.log日志文件，发现有错误：

推断原因是 agent 连不了控制机，被拒绝，连接超时。

这个原因可能是因为本地主控机有多个网卡，启动Jmeter的时候没有用跟助攻机连通的网卡，所以会链接超时：

1）修改一下Jmeter启动时使用IP地址就可以：在主控机的Jmeter.bat文件中查找set ARGS这一句，然后在其上面一行添加：

set rmi_host=-Djava.rmi.server.hostname=你跟主动即连通的IP地址【比如192.168.61.2】

2）然后在set ARGS这行最后加上空格 %rmi_host%

3)在打开主控机的jmeter-server文件时，检查一下启动IP地址：

如果修改完后还是不行，那么就是你的主控机的电脑的防火墙没有关闭。一定要关闭主控机所有的防火墙：

错误4： 阶梯压测助攻机执行失败

解决方案：这是因为助攻机下的Jmeter里没有阶梯压测的插件：把windows电脑安装了插件的Jmeter工具压缩一下上传到助攻机上解压使用，就可以了。

错误5：分布式执行的图显示不正确，不是随着时间的线形图：

解决方案：助攻机的时间跟主控机的时间保持一致。date看下时间，如果不一致，ntp同步一下时间。

总结

把常见的错误以及对应解决方案都列出来，大家如果遇到对应的问题，按照这个去解决就可以了。

JMeter 分布式压测部署并不复杂，但每个细节都关乎最终效果。只有深入理解原理，排查常见问题，才能在项目中真正发挥其性能测试的强大能力。

“压测的意义，不止于发现问题，更在于为未来的高并发保驾护航！”