jmeter进行分布式压测过程与 注意事项

jmeter命令行运行但是是单节点下的， 
jmeter底层用java开发，耗内存、cpu，
如果项目要求大并发去压测服务端的话，
jmeter单节点难以完成大并发的请求，
这时就需要对jmeter进行分布式测试：

1：先说说分布式测试原理

处理过程：

一：调度机master启动以后，会拷贝本地的jmx文件分发到远程的slave机器上；

二：slave机器拿到脚本以后启动命令行模式去执行脚本，对于每台slave机器拿到的脚本都是一样的，所以如果jmx脚本为50个线程跑3分钟，那么实际并发就是50*3=150个线程并发跑3分钟；

三：执行时，slave会把执行获得的数据结果传给master机器，master机器会收集所有slave机器的信息并汇总，这样master机器上就存在一份所有slave机器汇总的数据结果。

一些术语的解释：

• master，以GUI模式运行，同时控制测试的运行，在这里就是client，启动脚本所在的那台机器。
• slave，运行jmeter-server并从master接收指令、向目标服务器发送请求

注意事项：

一：我们注意到master机器启动后会拷贝jmx文件到slave机器，所以我们不需要在每台slave机器上也上传一份jmx，只需要在master机器上上传一份jmx脚本即可。

二：参数化文件：如果使用csv进行参数化，那么需要把参数文件在每台slave上拷一份并且路径必须需要设置成一样的。

三：调度机(master)和执行机(slave)最好分开，由于master需要发送信息给slave并且会接收slave回传回来的测试数据，所以mater自身会有消耗，所以建议单独用一台机器作为master。

即master机不建议也作为压测机。

四：保证每台机器的jmeter版本和插件版本相同，避免造成一些意外问题。

　　jdk版本保证大版本一致，小版本可不一致。

　　jmeter版本必须保证大小版本都一致。

五，注意监控压测机器的CPU,内存，网络。

六：分布式测试总样本数 = 线程数 * 循环次数 * 执行机总数， 
样本计数逻辑为：执行机slave执行的测试脚本是由调度机master分发的，
故每台执行机执行的测试脚本都是相同的，
故而性能测试总样本数 = 测试脚本样本数 * 执行机总数，
而测试脚本样本数为线程数 * 循环次数

一、压测机

1、数量&成本

无论是从成本角度还是维护的难易方面，压测机的数量，适量就好。

举个例子，8C16G的一台服务器，部署jmeter后，根据我个人的测试比对数据，配置≤1500个线程数，最好。太多了性能损耗较大，延时高；太少了又浪费。

2、controller&agent

模拟的并发线程数超过5K，我个人建议留出一台做专门的controller机器，主要是避免agent机器数据上报带来的影响（如果有其他的数据存储+可视化服务，可以忽略）。

3、服务授权

如果压测启动和服务配置都是root权限，那么在linux环境下，需要给jmeter和jmeter-server授权，命令为 chmod 777 jmeter ,授权后，显示如下：

二、服务通信

1、网络

所有的压测机和被测服务，最好在同一个网段内，尽可能减少时延问题（如果不在同一个网段，就需要找运维建立专门的网络通道，这个很浪费）。

2、端口

在分布式压测配置时，需要在controller机器的jmeter.properties文件中配置agent机器的IP+端口，默认端口1099，如果该端口没有被占用，则无需配置端口信息，比如：

3、内网和公网

如果压测机在内网，而访问的请求地址（现在都是统一的网关域名）在外网，就要注意一点：内网到公网一般是有带宽限制的，最好在压测开始前和运维确认。

三、数据切割

压测时候需要用到参数化数据，有些业务场景是需要先登录再进行操作的，或者某些数据具有唯一属性。

在分布式压测时候，需要注意，进行均匀的数据切割，确保每个请求的入参请求都是唯一的（可共用的参数不用切割）。

其实，在参数化数据准备阶段，就应该考虑到这个问题，数据的可用性、唯一性以及数量级。

四、服务启动

压测机到位，服务授权配置好了，脚本也写好了，网络也没问题，那么如何在NGUI模式（即linux环境）下启动呢？

1、以服务形式启动agent机

网上很多其他博客都写着利用命令 ./jmeter-server 启动压测服务，但这样有个缺点，只要服务连接中断，这个压测服务就不可用了。

但是以后台服务的形式启动agent机器的jemter-server，就不用担心服务不可用的问题，命令为 nohup sh jmeter-server & ，示意如下：

PS：注意，输入如上命令后，需要回车两次，然后通过命令，即可查看服务是否启动成功。

2、压测启动的2种方式

①、指定压测机启动，命令： ./jmeter -n -t /path/test.jmx -R 127.0.0.1,127.0.0.2

②、启动所有压测机，命令： ./jmeter -n -t /path/test.jmx -r ，示意如下：

3、更多命令

Apache-Jmeter-用户手册：命令行选项列表

分布式压测判定环境：

在性能测试过程中，如果要求并发数较大时（例如1000+），单机配置cpu与内存等无法支持，则需要使用Jmeter的分布式测试方法。

一、一般什么情况下需要分布式

1.前辈经验：比如机器i5双核的cpu，8g的内存。压测一个简单的接口，可以支持500+的并发。（但是如果压测方案逻辑复杂，比如在jmeter里面加了很多控制器，监听器，这些都是很耗机器性能，这时候可能连100并发都压不上去）

2. 压测过程中如果Jmeter未响应，卡住，反应慢，随即启动任务管理器，如果cup和内存特别大时，则说明单机扛不住了，则要使用分布式了

3. 随着并发的增大，tps不会增长，即出现瓶颈（排除服务器瓶颈及其他），可能是本测试机扛不住了。则要分布式。

二、Jmeter分布式测试原理（原理摘抄前辈，感谢）

　　1、Jmeter分布式测试时，选择其中一台作为调度机(master)，其它机器做为执行机(slave)。

　　2、执行时，master会把脚本发送到每台slave上，slave 拿到脚本后就开始执行，slave执行时不需要启动GUI，我理解它应该是通过命令行模式执行的。（如果引用到csv等外部的文件，则每台slaver所在的机器都需要相应位置放置该文件。）

　　3、执行完成后，slave会把结果回传给master，master会收集所有slave的信息并汇总。