jmeter学习笔记(二十二)——监听器插件之jp@gc系列

一、jp@gc - Actiive Threads Over Time 不同时间活动用户数量展示

下面是一个阶梯加压测试的图标

jmeter学习笔记(二十二)——监听器插件之jp@gc系列_第1张图片

 

 

二、jp@gc - Transactions per Second ,即TPS:每秒事务数

性能测试中,最重要的2个指标之一。该插件的作用是在测试脚本执行过程中,监控查看服务器的TPS表现————比如整体趋势、实时平均值走向、稳定性等。

jmeter学习笔记(二十二)——监听器插件之jp@gc系列_第2张图片

 

 

三、jp@gc - Response Times Over Time,即TRT:事务响应时间

性能测试中,最重要的两个指标的另外一个。该插件的主要作用是在测试脚本执行过程中,监控查看响应时间的实时平均值、整体响应时间走向等。

jmeter学习笔记(二十二)——监听器插件之jp@gc系列_第3张图片

 

四、jp@gc - PerfMon Metrics Collector,即服务器性能监控数据采集器

在性能测试过程中,除了监控TPS和TRT,还需要监控服务器的资源使用情况,比如CPU、memory、I/O等。该插件可以在性能测试中实时监控服务器的各项资源使用。

下面内容转自:https://www.jianshu.com/p/0e632bd2caf7

1、服务器端

(1)下载ServerAgent,把下载的ServerAgent-2.2.*.zip复制到服务器端,解压即可
(2)windows的服务器,运行文件夹中的startAgent.bat即可,linux的服务器是运行startAgent.sh(需要jar环境支持,没有安装的自行安装)

(3)服务器端使用方法

运行startAgent.sh/bat启动ServerAgent,默认是使用4444的TCP/UDP端口,若需要指定端口,如1234则添加如下参数:
./startAgent.sh --udp-port 0 --tcp-port 1234 0代表不开启该端口
出现如下提示则表示已经正常开启

 
jmeter学习笔记(二十二)——监听器插件之jp@gc系列_第4张图片
ServerAgent正常启动

 

2、客户端(Jmeter端)

(1)随便添加一个HTTP请求的sampler,把线程组设为无限循环
(2)添加“jp@gc - PerfMon Metrics Collector”监听器
(3)添加要监控的项目,如CPU、内存等,一行选择一种

 
jmeter学习笔记(二十二)——监听器插件之jp@gc系列_第5张图片
添加监听项

(4)最后运行jmx测试计划就行啦

碰到的几个坑

网上相关的教程其实很多了,写这篇主要还是记录一下自己碰到的坑吧,前几天一直连接不上,搜了几天都没找到解决办法。。。这里就给需要的人参考一下

我的测试环境——客户端:win10(64位),服务端:Ubuntu Server 16.04(64位)

1、网上包括官方教程都有说开启服务端后,要在客户端telnet一下确定是否连上,但我这里用telnet一直都是连接中,不知道是不是个例。虽然telnet一直是连接中,不过Jmeter插件还是可以正常连上并返回监控数据的,所以如果测试时看到telnet卡在连接中,先直接在Jmeter插件中测试吧。

2、telnet跟Jmeter中都提示连接超时(Jmeter报错ERROR: java.net.ConnectException: Connection timed out: connect serveragent),如果服务端已经正常启动ServerAgent,而且端口也在正常监听,一般就是client-server的通讯问题,检查两个地方:一是服务端的防火墙,二如果是不在同一个网段,还需要检查一下路由器中的端口有没有被占用。

最开始我在本机和虚拟机中的服务器中测试,发现死都telnet超时,检查服务器端口没有被占用,服务器自身telnet也是正常,网上搜的基本都是说改端口,试了没用。后来又查了下防火墙设置,最开始以为是iptables,结果根本就没装,后面才发现Ubuntu自带的是ufw...关掉后就正常了,也是坑

虚拟机连接测试OK后,就试着连阿里云的测试服务器了,一样设置ufw防火墙后,发现又连不上= =,这次是真的找不到原因了,请教运维同事,查了一天才查到原来是路由器上的4444端口被占用了。。。真是坑大了,服务端重新开启ServerAgent指定另一个端口后,连接终于正常了。。。

你可能感兴趣的:(jmeter学习笔记(二十二)——监听器插件之jp@gc系列)