jmeter分布式压测面试题（基于Jmeter的分布式压测实践）

jmeter分布式压测面试题（基于Jmeter的分布式压测实践）2.当模拟用户组的数量 < 线程组的线程数量例如数量都是5，那么运行测试，Jmeter会等到5个用户同时准备好后，并发发起请求；集合点通俗地理解就是，例如要模拟100个并发用户，集合点会将这100个线程集结完毕后，统一释放，同时对系统进行施压。Jmeter中可以通过同步定时器 Synchronizing Timer 来完成：同步定时器中”模拟用户组的数量“与线程组的线程数量的关系：1.当模拟用户组的数量 = 线程组的线程数量

写在前面

平时在使用JMeter做压力测试的过程中，由于单机的并发能力有限，所以常常无法满足压力测试的需求。因此，Jmeter还提供了分布式的解决方案。本文是一次利用Jmeter分布式对业务系统登录接口做的压力测试的实践记录。按照惯例，在正式开始前，先简单介绍一下本文大纲：

• Jmeter集合点用法
• Jmeter命令行参数详解
• Jmeter分布式部署方案
• Jmeter分布式调度原理
• Jmeter分布式部署过程
• Jmeter分布式压测业务系统登录接口实践

一、Jmeter集合点用法

集合点是使用Jmeter进行压力测试中一个绕不开的话题。

集合点通俗地理解就是，例如要模拟100个并发用户，集合点会将这100个线程集结完毕后，统一释放，同时对系统进行施压。Jmeter中可以通过同步定时器 Synchronizing Timer 来完成：

同步定时器中”模拟用户组的数量“与线程组的线程数量的关系：

1.当模拟用户组的数量 = 线程组的线程数量

例如数量都是5，那么运行测试，Jmeter会等到5个用户同时准备好后，并发发起请求；

2.当模拟用户组的数量 < 线程组的线程数量

① 未设置超时时间

例如：模拟用户为5，线程数量为8，那么在运行Jmeter后，Jmeter会先同时发起5个请求，剩下3个用户不足集合点的数量5，由于又没有设置超时时间，因此达不到集合点的数量要求，Jmeter就会一直处于等待状态；

② 已设置超时时间

例如：模拟用户为5，线程数量为8，超时时间设置为3000（以毫秒为单位，即3秒）

那么在运行Jmeter后，Jmeter会先同时发起5个请求，由于剩下3个用户不足集合点要求的数量5，因此会超时等待3秒钟，在3秒钟后再同时发起剩下的3个用户的请求，共8个用户；

3.当模拟用户组的数量 > 线程组的线程数量

① 未设置超时时间

例如：模拟用户为8，线程数量为5，超时时间为0

由于设置的模拟用户数量为8，即集合点数量为8，而线程组的总用户数只有5，因此达不到集合点数量要求，且又没有设置超时时间，所以Jmeter会一直处于等待状态，不会发起任何请求，如下图所示：

② 已设置超时时间

例如：模拟用户为5，线程数量为8，超时时间设置为3000（以毫秒为单位，即3秒）

由于设置的模拟用户数量为8，即集合点数量为8，而线程组的总用户数只有5，因此达不到集合点数量要求，但是设置了超时时间为3秒，所以Jmeter会在3秒后，同时发起5个(用户)请求，如下图所示：

二、Jmeter命令行参数详解

参数	作用
-n	表示在命令行模式下运行 JMeter
-t	指定脚本文件
-R	指定从节点(agent)执行测试，多个ip用逗号隔开
-r	表示启动全部agent
-f	表示每次都会清空前一次的执行结果，写入新的结果
-l	生成测试结果文件，默认以 jtl 结尾
-e	生成测试报告
-o	指定生成测告的位置，必须为空
-g	指定已存在的jtl结尾的测试文件生成报告

常见用法：

./jmeter.bat -n -t test.jmx # 以命令行方式运行test.jmx脚本 ./jmeter.bar -n -t test.jmx -l test.jtl # 以命令行方式运行test.jmx脚本，并生成测试结果文件test.jtl ./jmeter.bar -n -t test.jmx -f -l test.jtl -e -o report # 以命令行方式运行test.jmx脚本，每次生成结果前先清空test.jtl，同时在report目录下生成测试报告 ./jmeter.bar -n -t test.jmx -l test.jtl -R 192.168.1.122 # 指定远程主机192.168.1.122执行测试

三、Jmeter分布式部署方案

主机	IP地址
Master主节点（Windows）	192.168.1.131
Slave从节点-1（Linux）	192.168.1.121
Slave从节点-2（Linux）	192.168.1.122
Slave从节点-3（Linux）	192.168.1.123

注意事项：

• 主节点及各个从节点机器必须提前安装好Java环境；
• 主节点及各个从节点的Jmeter版本保持统一；
• master会在发送测试计划时将jmx的脚本文件发送到各个从节点，因此，脚本文件不用手动上传到各个从节点；
• master不会将外部文件一起发送，所以在测试中用到的csv等参数化文件，需要把CSV等文件手动上传到各个从节点，最好都放置在bin目录下，Jmeter会直接从bin目录下开始查找；

四、Jmeter分布式调度原理

1.各节点作用

• 主节点：主要负责管理从节点(负载机)、分配调度任务(脚本分发)、收集测试结果
• 从节点：执行测试任务，模拟并发请求

2.工作流程

① 主节点负责将测试任务、测试脚本下发给各个从节点；

② 从节点接收到测试任务后，开始驱动各自环境上的Jmeter执行测试任务、模拟并发请求；

③ 从节点执行完成后会将测试结果回传给主节点；

④ 最后主节点将各个从节点的收集回来的测试结果进行展示；

五、Jmeter分布式部署过程

1.主节点部署

① 编辑主节点jmeter.properties配置文件

• 第268行，remote_hosts添加从节点主机地址，多个从节点用逗号隔开（注意：不同版本可能存在差异）
• 第272行，为主节点端口号，如有端口占用，可手动修改
• 第345行，server.rmi.ssl.disable由false改为true（关闭ssl）

② 主节点启动jmeter-server服务

Windows环境下直接点击运行Jmeter的bin目录下的jmeter-server.bat即可，启动成功会出现如下提示：

2.从节点部署

① 将Jmeter压缩包上传到各个从节点并解压

从节点均为Linux环境，解压命令为：

unzip apache-jmeter.zip

② 修改jmeter.properties配置文件

• 第345行，server.rmi.ssl.disable由false改为true（关闭ssl）

③ 启动jmeter-server服务

chmod -R x bin # jmeter-server、jmeter文件都需要执行权限，可以简单粗暴使用chmod -R参数赋予整个bin目录执行权限 ./jmeter-server # 启动jmeter-server服务

启动成功会出现如下提示：

3.测试主节点与从节点的连通性

可以通过Jmeter工具-运行-远程启动，选择一个从节点；也可以使用命令行-R参数指定一个从节点运行：

如下图所示，Starting...表示主节点已将任务下发到指定的从节点，从节点开始执行测试任务

4.Jmeter分布式部署常见问题及报错解决

1）启动远程主机，提示“Engine is busy - please try later”

原因：本地或者远程负载机，未正常关闭

解决：杀掉进程重新启动（可以观察主节点及从节点的jmeter-server日志，如果只有Starting，没有Finished，那么大概率是这台机器出现了问题）

2）主节点发起测试后未接收到结果数据

如：执行成功后，察看结果树无数据，主节点及从节点也没有任何报错

原因：测试脚本中有参数化，远程节点上参数化csv文件跟本地测试中设置的目录不一致，或从节点上缺少csv文件

解决：将csv文件分别上传一份到各个从节点，csv文件最好设置相对路径，不要设置绝对路径，将csv文件存放在bin目录下

3）Jmeter启动从节点运行测试报错“connection refused”

原因：从节点未启动jmeter-server服务

解决：各个从节点均启动jmeter-server服务

六、Jmeter压测业务系统登录接口实践

• 最大并发量：和我们业务系统负责人交流后，得知系统理论上支持6000~7000个左右的用户同时并发登录是没有问题的；
• 测试的目标：测试出业务系统是否如他提供的数据、支持那么大的用户并发登录；
• 实测数据：3台负载机，每台启动500个线程，共1500个用户并发，测试结果如下，各个负载机模拟的用户均登录正常、无报错，被测业务系统所在服务器内存、CPU均无大的波动；

• 升压：并发用户数量1500、2100左右，系统响应都比较稳定，当并发用户量达到每台1000，一共3000个用户同时请求时，部分用户登录会返回500，总体失败率在3%左右（预测当并发用户数达到更大规模4000、5000、6000，失败的比例还会增大，由于周五赶车，暂时还没来得及完成）

小结

---

• 以上就是利用Jmeter实现分布式压测的一次实践，确切的说应该是初探；
• 在压力测试过程中，CPU和内存的动态变化我并没有做详细的监控，后续准备借助JMeter InfluxDB Grafana的监控组合实现可视化监控；
• 性能测试是一个庞大而复杂的工程和命题，性能测试工具仅仅是实现性能测试的技术手段，会使用性能测试工具不代表就掌握了性能测试；
• 所有使用性能测试工具的目的都只是为了模拟压力的发起，在性能测试过程中，工具仅仅起到脚本开发、场景实现、测试执行等作用，而性能测试还包括需求获取、场景设计、结果分析和调优等诸多环节，最终还是要靠人来实现；
• 尤其是性能瓶颈分析和调优，除了依赖性能测试结果外，还需要依赖于人的强大的性能测试功底，以及对业务、对系统架构的了解；