jmeter +ant +jenkins 性能资源监控集成测试

在使用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包，分别取出libext目录下的 
JMeterPlugins-Extras.jar 和 JMeterPlugins-Standard.jar文件 
然后将这两个.jar插件放在apache-jmeter-x.xxlibext目录下，重启JMeter，若没有报错，证明插件可用，若报错，检查是否由于版本导致

解压ServerAgent-2.2.1.zip文件，将解压后的文件夹放在需要监控的服务器端，Linux和windows通用，只需启动服务即可

windows平台运行ServerAgent.jar文件，在Linux平台运行ServerAgent.sh文件 
启动端口默认为4444

插件查看

成功重新启动JMeter后，可看到许多新增的jp@gc开头的选项 
如监听器：

现在看看几个常用的选项的意义：

1. jp@gc - Actiive Threads Over Time：不同时间活动用户数量展示（图表）
2. 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％就停止测试
3. jp@gc - Bytes Throughput Over Time:不同时间吞吐量展示（图表） 
   聚合报告里，Throughput是按请求个数来展示的，比如说1.9/sec，就是每s发送1.9个请求；而这里的展示是按字节Bytes来展示的图表
4. jp@gc - Composite Graph： 混合图表 
   在它的Graphs里面可以设置多少个图表一起展示，它可以同时展示多个图表
5. jp@gc - Flexible File Writer：这个插件允许你灵活记录测试结果 
   Filename：结果记录的地方 
   　 Overwirte existing file：是否覆盖这个文件 
   Ｗrite File Header：文件的头(即文件的第一行) 
   Record each sample：记录不同的sample（记录哪些内容，什么顺序，如何隔开不同的值） 
   Write File Footer：文件的结尾（即文件的最后一行）
6. jp@gc - Hits per Second：每秒点击量
7. jp@gc - PerfMon Metrics Collector：服务器性能监测控件，包括CPU，Memory，Network，Ｉ/Ｏ等等（此功能用到在需监听的服务器上启动startAgent）
8. jp@gc - Reponse Latencies Over Time：记录客户端发送请求完成后，服务器端返回请求之前这段时间
9. jp@gc - Reponse Times Distribution： 显示测试的响应时间分布，X轴显示由时间间隔分组的响应时间，Y轴包含每个区间的样本数
10. jp@gc - Respose Times Over Time： 响应时间超时，显示每个采样以毫秒为单位的平均响应时间
11. jp@gc - Response Times vs Threads： 线程响应时间，显示响应时间的并行线程的数量如何变化
12. 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文件libext目录下的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

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