jmeter监听器---jp@gc - PerfMon Metrics Collector

最新推荐文章于 2024-08-12 10:10:56 发布

paidaxing_dashu

最新推荐文章于 2024-08-12 10:10:56 发布

阅读量8.7k

点赞数 5

分类专栏： # Jmeter组件基础

本文链接：https://blog.csdn.net/paidaxing_dashu/article/details/102463818

版权

Jmeter组件基础专栏收录该内容

16 篇文章

订阅专栏

作用：

在这里插入图片描述
参考资料

安装：

在这里插入图片描述
下载地址

ServerAgent

在这里插入图片描述
jp@gc - PerfMon Metrics Collector：服务器性能监测控件
根据需要选择CPU，Memory，Network Ｉ/Ｏ等

监控的cpu的情况如下：

在这里插入图片描述

双击后面的输入框出现的按钮，点击出现调试框

在这里插入图片描述

系列指标含义：

1）CPU
　对于各指标项，数值都是代表百分比，比如默认配置(combined)下在曲线图中看到某个时间的数值是30，即代表此时总的cpu使用时间占比为30%。
　有两点比较有用的地方值得说明：一是在Scope区域，可以通过Per Process选项来获取指定进程的CPU使用情况，二是在CPU Cores区域，我们可以选择监控指定的单个Core。
2）Memory（内存）
各指标项中，usedperc(默认)和freeperc两项的数值代表与总内存的百分比，其余指标项的数值都是指内存大小，选中对应想，可以看到Metric Unit区域单位配置将变为可用，通常Mb会比较适合观察。
　　同样，也可以选择监控指定进程的数据
3）Disk I/O（磁盘输入和输出）I/O就是input和output
各指标项中，queue(默认)的数值代表等待I/O队列长度，reads、writes分别代表每秒处理的读/写次数，readbytes、writebytes顾名思义，代表每秒读/写的数据量，单位同样在Metric Unit区域配置，通常Mb会比较适合观察。
如果有挂载多个存储设备，可以在Filesystem Filter区域指定要监控的设备
在这里插入图片描述

曲线图：

1、使用策略：
　　如果测试场景的测试执行时间较长，采集的监控数据量比较大，为了在GUI模式查看曲线图时更方便、快捷，建议将各个监控指标项单独使用一个PerfMon监听器，从而配置不同的指标项数据存储到不同的文件中，测试执行完毕后，载入数据和数据查看都会更快。
　　如果预计数据量不会太大，可以以服务器为单位来划分PerfMon监听器。这样可以方便的观察到整个测试过程中，某台服务器各项资源使用情况的变化趋势
　　对于分布式服务、为了方便观察各个节点的负载分布、负载变化趋势，可以考虑将同类型的节点放置到同一个PerfMon监听器，以便对比观察
2、数值：
　　当一个PerfMon监听器中展示多种指标项的数据时，为了曲线图的可观察性，插件会自动进行优化，如图5所示，我们看到在CPU项和内存项都有个x10，代表曲线图中展示的数值是在采集到的真实数值上放大了10倍，目的是为了保证不同数据项在同一坐标系中展示时，各项都变化趋势都能够被观察到。
在这里插入图片描述

曲线图配置：

插件界面的Rows标签页可以调整要在曲线图中展示的指标项
　　Setting标签页中常用的有
　　use relative times用于配置曲线图x轴表示相对时间(测试开始时为0)还是实际系统时间。
　　Auto-zoom rows for best fit默认勾选，则会有上一节讲数值时提到的展示数据自动放大的功能，取消勾选则全部展示采集的实际数值。
　　Limit number of points in row to xx points：勾选后可以设定曲线图展示的采样点数量，我们的测试报告会有不同的角色查看，其中一些角色可能不具备也不需要对监控数据的细节理解能力，此时我们提供的监控曲线图应该是易读的，如果按照实际的所有采样点来渲染出曲线图，可能会有很多偏离趋势的噪点数据，这对于不了解的人来说可能会有很多疑惑，所以当我们有了分析结论，最后报告呈现的时候，可以考虑通过调整采样点，来让曲线图更好的展示资源使用趋势，消除其他不必要的信息。
在这里插入图片描述
Force maximum Y axis value to xx，实际上我更多会选择不勾选，不勾选的情况下，插件在描绘曲线图的时候，会根据数值大小自动调整Y轴最大值，以达到更佳可读性，如图7和图8，分别是不勾选，和勾选后设置最大值为100时的曲线图效果，显然图7可以更容易的观察到变化的细节。不过与上一项类似，可能在对外出具报告时，为了更少的解释说明，可能需要某个指定的数值。

 不自定义Y轴

在这里插入图片描述

自定义Y轴

在这里插入图片描述
　2.3 自定义指标
　　1、EXEC
　　在插件界面选择指标类型时，可以看到一个EXEC选型，该选项允许我们在后面的Metric parameter中配置一个命令语句(该语句最终应该输出单个数值)，测试执行时，ServerAgent将执行该命令，同时插件将接收ServerAgent捕获的输出数值。
　　语法规则：EXEC所配置的语句需要按照一定的规则来填写，先是给出命令的执行程序的位置，然后将具体的命令以及命令的参数作为，命令和命令参数都需要用冒号”:”来隔开。比如/bin/sh:-c:free |grep Mem |awk ‘{pring $7}’
　　/bin/sh，代表命令的执行程序
　　-c，即/bin/sh的-c选型，有-c选型的情况下，将从后面的字符串按一定规则解析为命令和命令参数
　　可以看到有用冒号分隔了执行程序/选型参数/命令语句
　　对于windows，也类似，如C:\Windows\System32\cmd.exe:/c:echo %RANDOM%
　　2、TAIL
　　如同Linux的tail命令，读取文件的最后一行，用在这里，需要文件每一行只包含一个单独的数值。借助tail，我们可以通过自定义脚本监控任意指标，只需要脚本的输出满足要求即可。
　　显而易见，TAIL后面的参数就是配置要读取的文件的地址，测试执行时，ServerAgent将根据配置读取所在服务器的指定文件。

JR组件TPS,TPT试图

1）添加 TPS 视图

线程组 -> 添加 -> 监听器 -> jp@gc Transaction per Second。某次压测实际效果图：

在这里插入图片描述

可以看出在该段时间内 TPS 大约维持在 6300 个左右。

2）添加 TRT 视图

线程组 -> 添加 -> 监听器 -> jp@gc Response Times Over Time。某次压测实际效果图：

在这里插入图片描述

可以看出在该段时间内 TRT 平均在 70ms 左右。

QPS，TPS，系统吞吐量，用户并发量的概念区别：
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，
个人理解如下：
1、Tps即每秒处理事务数，包括了
1）用户请求服务器
2）服务器自己的内部处理
3）服务器返回给用户
这三个过程，每秒能够完成N个这三个过程，Tps也就是3；
2、Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。
例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q”
Content-Type application/json