【Jmeter+Jenkins】JMeterPlugin性能监控

blueice

　　http://blog.csdn.net/lluozh2015/article/details/51192058
　　在使用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：是否覆盖这个文件
  　　Ｗrite File Header：文件的头(即文件的第一行)
  　　Record each sample：记录不同的sample（记录哪些内容，什么顺序，如何隔开不同的值）
  　　Write File Footer：文件的结尾（即文件的最后一行）
  
  
• jp@gc - Hits per Second：每秒点击量
  
• jp@gc - PerfMon Metrics Collector：服务器性能监测控件，包括CPU，Memory，Network，Ｉ/Ｏ等等（此功能用到在需监听的服务器上启动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 Ｉ/Ｏ等）
　　注：为了Y轴的单位为百分比，故在Network Ｉ/Ｏ的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文件
　　使用命令：
　　

java -jar CMDRunner.jar --tool Reporter --input-jtl PerfMon.jtl --plugin-type PerfMon --generate-png report.png　　

• 1
  

　　在CMDRunner.jar中，不明为嘛需要写明绝对路径
　　将PerfMon Metrics Collector生成的.jtl文件设置在工作空间的路径，且设置生成的.png文件的路径在工作空间中即可
　　现在仍有另外一个问题，由于每次构建生成的.png文件的文件名都是一样的名称，故需要进行一个处理
　　使用python将.jtl文件名进行一个预处理，且每次生成的.png文件以构建的次数${BUILD_NUMBER} 命名
　　需要将.png文件在邮件中显示，在配置文件的Editable Email Notification中，在body中增加一行代码
　　

<img src="report.png"/>　　

• 1
  

　　但是.png的文件需要一个绝对的资源路径，开始配置的路径为Linux服务端中该.png文件的绝对路径，发现无法读取到，原来需要的是一个url链接，即工作空间中该文件的链接url地址，又.png文件以构建次数命名，故路径为：
　　

${PROJECT_URL}ws/png/Monitor${BUILD_NUMBER}.png　　

• 1
  

　　现在终于搞定了，构建发送的邮件中，显示的资源监控部分为：