目录
1.什么是分布式?
2.Jmeter分布式执行原理
3.什么情况下采用分布式测试?
4.执行机安装启动JDK8并配置环境变量(以Linux为例)
5.执行机安装Jmeter3.3(以Linux为例)
6.Jmeter3.3分布式压测准备工作
7.非GUI执行分布式压测
8.Jmter压测接口的性能优化
9.HTML压测报告
10.遇到的问题
11.参考文章
最近在学习Jmeter分布式压测实战,看老师讲解的内容,也就是对Controller和Agent进行简单的文件配置,结果等到我实际操作时,几乎每一步都会出现错误,写下这个学习笔记,算是对这两天的一个总结!
在使用Jmeter进行性能测试时,如果并发数比较大(比如项目需要支持1000并发),单台电脑的配置(CPU和内存)可能无法支持,这时可以使用Jmeter提供的分布式测试的功能。
1.什么是分布式?
由多台电脑共同完成同一个任务(请求)部署,我们称这种部署为分布式部署。
2.Jmeter分布式执行原理
一台电脑作为控制机(Controller),其它电脑做为执行机(Agent);
执行时,控制机会把脚本发送到每台执行机上,执行机拿到脚本后就开始执行
执行机执行时不需要启动Jmeter界面,可以理解它是通过命令行模式执行的
执行完成后,执行机会把结果回传给控制机,控制机会收集所有执行机的信息并汇总
3.什么情况下采用分布式测试?
在进行压测的过程中如果出现Jmeter未响应,卡住,反应慢等现象。随即启动任务管理器进行查看,如果cup和内存都特别大。就可以说明现在的负载机出现了瓶颈,需要进行分布式测试。
随着并发数的增长,TPS不再增长,即出现瓶颈(排除服务器瓶颈及其他)。可能是现在的负载机出现了瓶颈,需要进行分布式测试。
在进行压测的过程中出现错误,如Unrecognized Windows Sockets error: 0: recv failed。可能是现在的负载机出现了瓶颈,需要进行分布式测试。
4.执行机安装启动JDK8并配置环境变量(以Linux为例)
参考文章:使用SecureCRT将本地JDK安装包远程上传到Linux并配置环境变量
5.执行机安装Jmeter3.3(以Linux为例)
安装方法与安装jdk类似,可以参考上面的文章进行安装!
6.Jmeter3.3分布式压测准备工作
6.1.执行机的配置
6.1.1.自定义执行机端口号
在执行机的Jmeter的bin目录下,找到jmeter.properties文件,修改如下两个配置项,比如修改成8899
server_port=8899,表示Controller要远程连接的端口,即remote_hosts=xxx.xxx.xxx.xxx:8899
server.rmi.localport=8899,表示执行机启动时显示的端口,即endpoint:[xxx.xxx.xxx.xxx:8899]
6.1.2.启动jmeter-server
标注1,启动bin目录下的jmeter-server
标注2,执行机的的IP地址和端口号
6.2.控制机的配置
打开bin目录下jmeter.properties文件,remote_hosts配置如下,IP和Port是执行机的IP以及端口(端口也可以自定义),多台执行机之前用","隔开,我这里配置了两台执行机,其中一台是Windows系统,另外一台是Linux系统。
看网上资料说,Jmeter4.0以上的版本,还要修改一项配置,如下所示,我用的是Jmeter3.3版本,没有配置这一项,对结果也没有影响!
server.rmi.ssl.disable=true
6.3.多网卡配置
我们要在多网卡的服务器上开启RMI服务的话必须指定IP,使他们能够在同一个网段内。
需要以下几步(假定所有机器都在192.168.0.*网段):
6.3.1.修改agent服务器,指定agent机器的IP
修改jmeter-server文件
# vim jmeter-server
修改RMI_HOST_DEF=-Djava.rmi.server.hostname=192.168.0.109(需要连接的IP)
6.3.2.修改controller服务器,指定controller机器的IP
修改jmeter.bat文件
新增set rmi_host=-Djava.rmi.server.hostname=192.168.0.108
修改set ARGS=%DUMP% %HEAP% %VERBOSE_GC% %GC_ALGO% %DDRAW% %SYSTEM_PROPS% %rmi_host%
6.4. 打开Jmeter,选择"运行",有"远程启动","远程全部启动"两个选项
6.4.1.选择"远程启动"-->192.168.0.109:1099
控制机结果,这里我只启动了192.168.0.109这一台执行机,所以只有一个结果(线程数和循环次数都是1)
执行机控制台信息
6.4.2.选择"远程全部启动"
2台Agent全部启动,所以新增两次执行结果,如下所示:
7.非GUI执行分布式压测
-n 非GUI模式
-t 指定要运行的JMeter测试脚本文件
-l 记录运行结果的文件,每次运行之前,要确保result.jtl不存在,不然会报错
-r jmter.properties文件中指定的所有远程服务器
-e 在脚本运行结束后生成html报告
-o 用于存放html报告的目录(目录要为空,不然会报错)
8.Jmter压测接口的性能优化
使用非GUI模式
少使用Listener, 如果使用-l参数,它们都可以被删除或禁用。
在加载测试期间不要使用“察看结果树”等监听器,只能在脚本阶段使用它们来调试脚本。
包含控制器在这里没有帮助,因为它将文件中的所有测试元素添加到测试计划中。
不要使用功能模式,使用CSV输出而不是XML。
只保存你需要的数据,尽可能少地使用断言。
如果测试需要大量数据,可以提前准备好测试数据放到数据文件中,以CSV Read方式读取。
用内网压测,减少其他带宽影响压测结果。
如果压测大流量,尽量用多几个节点以非GUI模式向服务器施压。
9.HTML压测报告
下面是1000并发循环10次的html压测报告!
因为是2台Agent执行压测,所以总的请求数=并发数*循环次数*2=20000
9.1.Dashboard
html压测报告里Dashboard的核心指标
9.1.1.Test and Report informations
Source file:jtl文件名
Start Time :压测开始时间
End Time :压测结束时间
Filter for display:过滤器
Lable:sampler采样器名称
9.1.2.APDEX(Application performance Index) & Requests Summary
apdex:应用程序性能指标,范围在0~1之间,1表示达到所有用户均满意
T(Toleration threshold):可接受阀值,默认500ms
F(Frustration threshold):失败阀值,默认1500ms
OK:成功率
KO:失败率
9.1.3.Statistics 统计数据
lable:sampler采样器名称
samples:请求总数,并发数*循环次数*执行机个数
KO:失败次数
Error%:失败率
Average:平均响应时间
Min:最小响应时间
Max:最大响应时间
90th pct: 90%的用户响应时间不会超过这个值(关注这个就可以了)
【例如:现在有10个用户的响应时间分别是:2ms,1ms,4,1,5,6,7,6,7,8;那现在把10%的峰值去掉,
这里就是去掉8.所以90th pct是7】
95th pct: 95%的用户响应时间不会超过这个值
99th pct: 99%的用户响应时间不会超过这个值 (存在极端值)
throughtput:Request per Second吞吐量 qps 【几千是低的,一般是上万,机器是16核32G这类的】
received:每秒从服务器接收的数据量
send:每秒发送的数据量
9.2.Charts报表
html压测报告里Charts的核心指标
9.2.1.Over Time(随着时间的变化)
Response Times Over Time:响应时间变化趋势
Response Time Percentiles Over Time (successful responses):最大,最小,平均,用户响应时间分布
Active Threads Over Time:并发用户数趋势
Bytes Throughput Over Time:每秒接收和请求字节数变化,蓝色表示发送,黄色表示接受
Latencies Over Time:平均响应延时趋势
Connect Time Over Time :连接耗时趋势
9.2.2.Throughput
Hits Per Second (excluding embedded resources):每秒点击次数
Codes Per Second (excluding embedded resources):每秒状态码数量
Transactions Per Second:即TPS,每秒事务数
Response Time Vs Request:响应时间和请求数对比
Latency Vs Request:延迟时间和请求数对比
9.2.3.Response Times
Response Time Percentiles:响应时间百分比(一般看90那里)
Response Time Overview:响应时间概述
Time Vs Threads:活跃线程数和响应时间
Response Time Distribution:响应时间分布图
10.遇到的问题
1.Agent的VM会干扰远程连接
控制机远程启动agent时,报错如下所示:
可以看到,IP地址并不与执行机的IP地址一样
查看资料,发现虚拟机的IP也会出现在远程连接待选列表中,所以连接时会报错,如下所示:
解决方法:禁用虚拟机网卡!
2.防火墙未关闭或Controller和Agent不在同一个网段会影响远程连接
CentOS6.1关闭防火墙:service iptables stop
解决方法:关闭Agent的防火墙;使Controller和Agent在同一网段。
3.控制机和执行机在同一网段,本地ping不同虚拟机,但虚拟机能ping通本地
关闭了虚拟机的防火墙,但本地还是ping不同虚拟机!
查看网上资料,说是要将虚拟机设成桥接模式,试了一下,本地可以ping通虚拟机了!
如果改成桥接模式,本地还是ping不同虚拟机,建议重启电脑!
因为我在复现这个问题后,将虚拟机改成了桥接模式,但本地还是ping不同虚拟机,把虚拟机的IP地址也改成了静态IP,各种修改,重启了网络,也重启了几遍虚拟机,本地有时能ping通虚拟机,有时ping不通,最后重启了一下电脑,结果搞定了!
CentOS重启网络:service network restart
4.控制机上的VMware网卡不可以禁用,否则会提示错误,连不上虚拟机上的Linux,所以控制机和执行机最好分开,不要在一台电脑上,否则会出现很多错误,改完一个问题,会出现另一个问题!
11.参考文章
————————————————
版权声明:本文为CSDN博主「小蝌蚪找玛玛」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_44679832/article/details/104747330
服务端性能测试5:JMeter分布式压测