-
在使用Jmeter进行接口测试时,需要同步监控服务端的资源使用情况。
因为如果在执行机器上使用表格和图形等监听器,占用内存太多,这样会影响执行机器的性能
开始设计的方案是:
服务器的性能监控的部分使用nmon去收集资源占用(在开始测试前加一个bash shell 前置处理器去启动nmon,结束后一样加bash shell后置处理器去结束nmon,然后用scp把.nmon文件传回监控机器)
使用一个windows端的去做控制和结果收集,执行端的机器运行Jmeter,只用简单数据监听器,最后在在监控机器上去分析图像和报表数据但在google找到JMeterPlugin,一个强大的JMeter插件
插件下载
下载地址:http://jmeter-plugins.org/downloads/all/
下载的时候注意JMeter的版本兼容
对于JMeterPlugins-Extras-1.4.0.zip 和 JMeterPlugins-Standard-1.4.0.zip
解压这两个.zip包,分别取出\lib\ext目录下的
JMeterPlugins-Extras.jar 和 JMeterPlugins-Standard.jar文件
然后将这两个.jar插件放在apache-jmeter-x.xx\lib\ext目录下,重启JMeter,若没有报错,证明插件可用,若报错,检查是否由于版本导致解压ServerAgent-2.2.1.zip文件,将解压后的文件夹放在需要监控的服务器端,Linux和windows通用,只需启动服务即可
windows平台运行ServerAgent.jar文件,在Linux平台运行ServerAgent.sh文件
启动端口默认为4444插件查看
成功重新启动JMeter后,可看到许多新增的jp@gc开头的选项
如监听器:现在看看几个常用的选项的意义:
- jp@gc - Actiive Threads Over Time:不同时间活动用户数量展示(图表)
- jp@gc - AutoStop Listener :自动停止监听器
average Response Time is greater than 10000ms for 10 seconds :连续10s平均响应时间大于10000ms就停止测试
average Latency is greater than 5000ms for 10 seconds :连接10s平均等待时间大于5000ms就停止测试
Error Rate is greater than 50% for 10 seconds :10s内错误率一直高于50%就停止测试 - jp@gc - Bytes Throughput Over Time:不同时间吞吐量展示(图表)
聚合报告里,Throughput是按请求个数来展示的,比如说1.9/sec,就是每s发送1.9个请求;而这里的展示是按字节Bytes来展示的图表 - jp@gc - Composite Graph: 混合图表
在它的Graphs里面可以设置多少个图表一起展示,它可以同时展示多个图表 - jp@gc - Flexible File Writer:这个插件允许你灵活记录测试结果
Filename:结果记录的地方
Overwirte existing file:是否覆盖这个文件
Write File Header:文件的头(即文件的第一行)
Record each sample:记录不同的sample(记录哪些内容,什么顺序,如何隔开不同的值)
Write File Footer:文件的结尾(即文件的最后一行) - jp@gc - Hits per Second:每秒点击量
- jp@gc - PerfMon Metrics Collector:服务器性能监测控件,包括CPU,Memory,Network,I/O等等(此功能用到在需监听的服务器上启动startAgent)
- jp@gc - Reponse Latencies Over Time:记录客户端发送请求完成后,服务器端返回请求之前这段时间
- jp@gc - Reponse Times Distribution: 显示测试的响应时间分布,X轴显示由时间间隔分组的响应时间,Y轴包含每个区间的样本数
- jp@gc - Respose Times Over Time: 响应时间超时,显示每个采样以毫秒为单位的平均响应时间
- jp@gc - Response Times vs Threads: 线程响应时间,显示响应时间的并行线程的数量如何变化
- jp@gc - Transactions per Second: 每秒事务数,服务器每秒处理的事务数
jp@gc - PerfMon Metrics Collector
现在我们看一下服务器性能监测,jp@gc - PerfMon Metrics Collector
在Servers to Monitor中设置IP、port和Metric to collect
(已启动ServerAgent的服务端的的地址,默认端口为4444,根据需要选择CPU,Memory,Network I/O等)
注:为了Y轴的单位为百分比,故在Network I/O的Metric parameter中设置值为unit=mb:bytesrecv在所有数据写入一个文件的选项中,选择生成.jtl文件的存放路径,建议在点击configure按钮,将所有Sample Result Save Configuration选项勾选
运行该.jmx文件,可在该jp@gc - PerfMon Metrics Collector生成资源监控的曲线图表,并在/home/cloud/project/jobs/EasiCareInterface/workspace/jtl目录下,生成一份PerfMon.jtl文件,记录各个坐标点的信息
Jemter+Jenkins邮件
现在由于使用Jemter+Ant+Jenkins集成接口测试,计划将资源监控的曲线图表在邮件中显示。但是如上面所说,生成的是.jtl文件。
在初始的邮件中,JMeter中集成了/extras/jmeter-results-shanhe-me.xsl
文件,将生成的.jtl文件转为.html文件
在没有头绪的时候,计划着自己动手写一个.xsl文件,将PerfMon Metrics Collector生成的.jtl文件转为.png格式文件。后在度娘中找到,原来JMeterPlugins-Standard-1.4.0文件\lib\ext目录下的CMDRunner.jar文件可将.jtl文件转为.png文件
使用命令:- 1
在CMDRunner.jar中,不明为嘛需要写明绝对路径
将PerfMon Metrics Collector生成的.jtl文件设置在工作空间的路径,且设置生成的.png文件的路径在工作空间中即可
现在仍有另外一个问题,由于每次构建生成的.png文件的文件名都是一样的名称,故需要进行一个处理
使用python将.jtl文件名进行一个预处理,且每次生成的.png文件以构建的次数${BUILD_NUMBER}
命名需要将.png文件在邮件中显示,在配置文件的Editable Email Notification中,在body中增加一行代码
- 1
但是.png的文件需要一个绝对的资源路径,开始配置的路径为Linux服务端中该.png文件的绝对路径,发现无法读取到,原来需要的是一个url链接,即工作空间中该文件的链接url地址,又.png文件以构建次数命名,故路径为:
- 1
现在终于搞定了,构建发送的邮件中,显示的资源监控部分为:
版权声明:本文为博主原创文章,未经博主允许不得转载。