GUI界面中的plugins manager中的jpgc-Standard set,其中共包含以下的文件:
  jpgc-dummy
  jpgc-fifo
  jpgc-graphs-basic
  jpgc-perfmon
  jpgc-tst
  jpgc-sense
  jpgc-functions
  jpgc-casutg
  jpgc-ffw

界面

线程组

 
image.png

jp@gc - Stepping Thread Group,如下图
建立压力模型,持续加压

 
image.png

This Group will start 100 threads:这次的测试总共会起100个线程。
First , wait for 10 seconds:等待10s后开始起线程,也就是不等待直接起线程。
Then start 1 threads :最开始启动1个线程
Next add:10 threads every:10 using ramp-up:5 每10秒在5秒内启动10个线程
Then hold load for 12 seconds. :全部的线程起来后,运行12s 后开始停止(跟loadrunner类似,从jmeter聚合报告里面可以看出来,这里的hold load 的意思,其实是这些线程,一直在请求,相当于jmeter普通线程组里面的循环运行)。
Finally , stop 5 threads every 10 seconds:每隔10秒停止5个线程

jp@gc - Ultimate Thread Group,如下图

 
image.png

跟上面那个线程组有些类似,不过这个是几个设置的结合,像这里有设置两个线程组(1、不延迟,20s内起100个线程,hold 60s后,10s内停止;),执行的时候,这两个线程组是同时按照自己的规则开始执行的,每一时刻,得到的结果都是两个线程组的叠加。

监控器

jp@gc - Active Threads Over Time
不同时间活动用户数量展示(图表)

 
image.png

jp@gc - Flexible File Writer
这个插件允许你灵活记录测试结果
Filename:结果记录的地方
Overwirte existing file:是否覆盖这个文件
Write File Header:文件的头(即文件的第一行)
Record each sample:记录不同的sample(记录哪些内容,什么顺序,如何隔开不同的值)
Write File Footer:文件的结尾(即文件的最后一行)

 
image.png

jp@gc - PerfMon Metrics Collector
服务器性能监测控件,包括CPU,Memory,Network,I/O等等(此功能用到在需监听的服务器上启动startAgent)
Add Row 可以添加需要监控的服务器ip,端口号默认为4444,监控内容CPU/MEMORY/DISKS I/O等

 
image.png

jp@gc - Response Times Over Time
响应时间超时,显示每个采样以毫秒为单位的平均响应时间
展示响应时间曲线

 
image.png

jp@gc - Transactions per Second
每秒事务数,服务器每秒处理的事务数
用于展示TPS曲线

 
image.png

ServerAgent

下载解压ServerAgent-2.2.1.zip文件,将解压后的文件夹放在需要监控的服务器端,Linux和windows通用,只需启动服务即可
默认端口是4444,如果占用需要修改

 
image.png

windows平台运行ServerAgent.jar文件

linux服务器上首先将startAgent.sh设定为可执行文件:
chmod 777 startAgent.sh
./startAgent.sh执行文件
如果要将该文件设置为后台执行不关闭
Nohup ./startAgent.sh &

在服务器上开启startAgent服务后,再在jmeter上运行脚本,可以在jp@gc - PerfMon Metrics Collector上查看监控的图形结果

性能测试中服务器关键性能指标

- 业务指标:如吞吐量(QPS、TPS)、响应时间(RT)、并发数、业务成功率等
- 资源指标:如CPU、内存、Disk I/O、Network I/O等资源的消耗情况

一. CPU

关于CPU资源,有三个重要概念:使用率、运行队列和上下文切换,这里借助一张描述进程状态的图来进行简要说明:

 
image.png
  • Running:正在运行的进程
  • Waiting:已准备就绪,等待运行的进程
  • Blocked:因为等待某些事件完成而阻塞的进程,通常是在等待I/O,如Disk I/O,Network I/O等。

这里的Running和Waiting共同构成Linux进程状态中的可运行状态(task_running),而Blocked状态可以对应Linux进程状态中的不可中断睡眠状态(task_uninterruptible)

在Linux可以使用vmstat来获取这些数据:

[hbase@ecs- ~]$ vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st

CPU使用率(CPU Utilization Percentages):有进程处于Running状态的时间/总时间。在vmstat主要通过ussyid三列数据来体现:

  • us:用户占用CPU的百分比
  • sy:系统(内核和中断)占用CPU的百分比
  • id:CPU空闲的百分比

性能测试指标中,CPU使用率通常用us + sy来计算,其可接受上限通常在70%~80%。另外需要注意的是,在测试过程中,如果sy的值长期大于25%,应该关注in(系统中断)和cs(上下文切换)的数值,并根据被测应用的实现逻辑来分析是否合理。

运行队列进程数(Processes on run queue):Running状态 + Waiting状态的进程数,展示了正在运行和等待CPU资源的任务数,可以看作CPU的工作清单,是判断CPU资源是否成为瓶颈的重要依据。vmstat通过r的值来体现:

  • r: 可运行进程数,包括正在运行(Running)和已就绪等待运行(Waiting)的。

如果r的值等于系统CPU总核数,则说明CPU已经满负荷。在负载测试中,其可接受上限通常不超过CPU核数的2倍。

上下文切换(Context Switches):简单来说,context指CPU寄存器和程序计数器在某时间点的内容,(进程)上下文切换即kernel挂起一个进程并将该进程此时的状态存储到内存,然后从内存中恢复下一个要执行的进程原来的状态到寄存器,从其上次暂停的执行代码开始继续执行至频繁的上下文切换将导致sy值增长。vmstat通过cs的值来体现:

  • cs:每秒上下文切换次数。

另外还有一个指标用来作为系统在一段时间内的负载情况的参考:

平均负载Load Average:在UNIX系统中,Load是对系统工作量的度量。Load取值有两种情况,多数UNIX系统取运行队列的值(vmstat输出的r),而Linux系统取运行队列的值 + 处于task_uninterruptible状态的进程数(vmstat输出的b),所以会出现CPU使用率不高但Load值很高的情况。Load Average就是在一段时间内的平均负载,系统工具top、uptime等提供1分钟、5分钟和15分钟的平均负载值。

[hbase@ecs- ~]$ top
top - :: up :, users, load average: 0.80, 0.60, 0.53

上面示例中的0.80即是1分钟内的Load average,以此类推。
当我们需要了解当前系统负载情况时,可以先查看Load average的值,如果系统持续处于高负载(如15分钟平均负载大于CPU总核数的两倍),则查看vmstat的r值和b值来确认是CPU负荷重还是等待I/O的进程太多。

二. Memory

Memory资源也有三方面需要关注:可用内存,swap占用,页面交换(Paging),仍然借助一张图来说明:

 
image.png

这里讲到的内存,包括物理内存和虚拟内存,如上图所示,物理内存和硬盘上的一块空间(SWAP)组合起来作为虚拟内存(Virtual Memory)为进程的运行提供一个连续的内存空间,这样的好处是进程可用的内存变大了,但需要注意的是,SWAP的读写速度远低于物理内存,并且物理内存和swap之间的数据交换会增加系统负担。虚拟内存被分成页(x86系统默认页大小为4k),内核读写虚拟内存以页为单位,当物理内存空间不足时,内存调度会将物理内存上不常使用的内存页数据存储到磁盘的SWAP空间,物理内存与swap空间之间的数据交换过程称为页面交换(Paging)。

可用内存(free memory):内存占用的直观数据,vmstat输出free的值,可用内存过小将影响整个系统的运行效率,对于稳定运行的系统,free可接受的范围通常应该大于物理内存的20%,即内存占用应该小于物理内存的80%。在压力测试时,系统内存资源的情况应该用可用内存结合页面交换情况来判断,如果可以内存很少,但页面交换也很少,此时可以认为内存资源还对系统性能构成严重影响。

页面交换(Paging):页面交换包括从SWAP交换到内存和从内存交换到SWAP,如果系统出现频繁的页面交换,需要引起注意。可以从vmstat的si和so获取:

  • si:每秒从SWAP读取到内存的数据大小
  • so:每秒从内存写入到SWAP的数据大小

SWAP空间占用:可以从vmstat的swpd来获取当前SWAP空间的使用情况,应该和页面交换结合来分析,比如当swpd不为0,但si,so持续保持为0时,内存资源并没有成为系统的瓶颈。

三. Disk

磁盘通常是系统中最慢的一环,一是其自身速度慢,即使是SSD,其读写速度与内存都还存在数量级的差距,二是其离CPU最远。另外需要说明的是磁盘IO分为随机IO顺序IO两种类型,在性能测试中应该先了解被测系统是偏向哪种类型。

  • 随机IO:随机读写数据,读写请求多,每次读写的数据量较小,其IO速度更依赖于磁盘每秒能IO次数(IOPS)。

  • 顺序IO:顺序请求大量数据,读写请求个数相对较少,每次读写的数据量较大,顺序IO更重视每次IO的数据吞吐量。

对于磁盘,首要关注使用率,IOPS和数据吞吐量,在Linux服务区,可以使用iostat来获取这些数据。

[hbase@ecs- ~]$ iostat -dxk
Linux 2.6.-504.3..el6.x86_64 (ecs-) // _x86_64_ ( CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.52 0.00 0.13 0.06 0.00 99.28
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
xvda 0.10 6.63 0.40 2.57 6.22 36.80 29.00 0.04 14.63 1.19 0.35

(设备)使用率:统计过程中处理I/O请求的时间与统计时间的百分比,即iostat输出中的%util,如果该值大于60%,很可能降低系统的性能表现。

IOPS:每秒处理读/写请求的数量,即iostat输出中的r/s和w/s,个人PC的机械硬盘IOPS一般在100左右,而各种公有云/私有云的普通服务器,也只在百这个数量级。预先获取到所用服务区的IOPS能力,然后在性能测试中监控试试的IOPS数据,来衡量当前的磁盘是否能满足系统的IO需求。

数据吞吐量:每秒读/写的数据大小,即iostat输出中的rkB/s和wkB/s,通常磁盘的数据吞吐量与IO类型有直接关系,顺序IO的吞吐能力明显优与随机读写,可以预先测得磁盘在随机IO和顺序IO下的吞吐量,以便于测试时监控到的数据进行比较衡量。

四. Network

网络本身是系统中一个非常复杂的部分,但常规的服务端性能测试通常放在一个局域网进行,因为我们首先关注被测系统自身的性能表现,并且需要保证能在较少的成本下发起足够大的压力。因此对于多数系统的性能测试,我们主要关注网络吞吐量即可,对于稳定运行的系统,需要为被测场景外的业务流出足够的带宽;在压力测试过程中,需要注意瓶颈可能来自于带宽。
在Linuxf服务器,可以使用iptraf来查看本机网络吞吐量,如:

[root@ecs- ~]# iptraf -d eth0
x Total rates: 67.8 kbits/sec Broadcast packets: 0x
x 54.2 packets/sec Broadcast bytes: x
x x
x Incoming rates: 19.2 kbits/sec x
x 25.4 packets/sec x
x IP checksum errors: x
x Outgoing rates: 48.7 kbits/sec x
x 28.8 packets/sec

五. 总结

性能测试中,数据收集很重要,但是更重要的是快速抓住关键数据,读懂数据的含义。
本文主要介绍服务端性能测试中,对于CPU、内存等各种系统资源,通常首要关注的数据,以及这些数据在Linux服务器上的获取方式。
在实际测试中,通常会持续收集这些数据,如使用nmon,JMeter的PerfMon插件,以及zabbix等专门的系统监控工具

参考资料
Load (computing)
Process state
Linux Performance Analysis in 60,000 Milliseconds

JMeterPlugin性能监控的更多相关文章

  1. 《深入理解Java虚拟机》虚拟机性能监控与故障处理工具

    上节学习回顾 从课本章节划分,<垃圾收集器>和<内存分配策略>这两篇随笔同属一章节,主要是从理论+实验的手段来讲解JVM的内存处理机制.好让我们对JVM运行机制有一个良好的概念 ...

  2. jvm系列(五):tomcat性能调优和性能监控(visualvm)

    tomcat服务器优化 1.JDK内存优化 根据服务器物理内容情况配置相关参数优化tomcat性能.当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出,并且导致应用服务崩溃.因此一般建议堆的最 ...

  3. spring拦截器 实现应用之性能监控

    package cn.ximi.erp.web.common.interceptors; import cn.ximi.core.common.utils.string.StringUtil; imp ...

  4. Performance Monitor1:开始性能监控

    Performance Monitor是Windows内置的一个可视化监控工具,能够在OS级别上实时记录系统资源的使用情况,通过收集和存储日志数据,在SQL Server发生异常时,能够还原系统当时的 ...

  5. 前端性能监控方案window.performance 调研(转)

    1. 业界案例 目前前端性能监控系统大致为分两类:以GA为代表的代码监控和以webpagetest为代表的工具监控. 代码监控依托于js代码并部署到需监控的页面,手动计算时间差或者使用浏览器的的API ...

  6. Apache服务器性能监控

    Apache服务器性能监控 1.使用自带mod_status模块监控 1)加载mod_status.so 模块 在httpd.conf中打开LoadModule status_module modul ...

  7. jvm性能监控与故障处理工具

    jdk为我们提供了一系列的jvm性能监控和故障处理工具,在这里根据学习进度进行整理记录.便于之后查阅 1.jps 虚拟机进程工具  类似于Linux系统中的ps命令,用于查看虚拟机进程,常用的有以下功 ...

  8. [整]磁盘 I/O 性能监控指标和调优方法

    在介绍磁盘 I/O 监控命令前,我们需要了解磁盘 I/O 性能监控的指标,以及每个指标的所揭示的磁盘某方面的性能. 磁盘 I/O 性能监控的指标主要包括: 指标 1:每秒 I/O 数(IOPS 或 t ...

  9. cAdvisor0.24.1+InfluxDB0.13+Grafana4.0.2搭建Docker1.12.3 Swarm集群性能监控平台

    目录 [TOC] 1.基本概念 ​ 既然是对Docker的容器进行监控,我们就不自己单独搭建cAdvisor.InfluxDB.Grarana了,本文中这三个实例,主要以Docker容器方式运行. 本 ...

随机推荐

  1. 并发之CAS无锁技术

        CAS算法即是:Compare And Swap,比较并且替换:     CAS算法存在着三个参数,内存值V,旧的预期值A,以及要更新的值B.当且仅当内存值V和预期值B相等的时候,才会将内存值 ...

  2. iOS load和initialize的区别

    可能有些还不清楚load和initialize的区别,下面简单说一下: 首先说一下 + initialize 方法:苹果官方对这个方法有这样的一段描述:这个方法会在 第一次初始化这个类之前 被调用,我 ...

  3. [leetcode]121. Best Time to Buy and Sell Stock 最佳炒股时机

    Say you have an array for which the ith element is the price of a given stock on day i. If you were ...

  4. boost之内存管理

    内存管理一直是令C++程序员最头疼的工作,C++继承了C那高效而又灵活的指针,使用起来稍微不小心就会导致内存泄露.野指针.越界访问等访问.虽然C++标准提供了只能指针std::auto_ptr,但是并 ...

  5. COGS 2189 帕秋莉的超级多项式

    放模板啦! 以后打比赛的时候直接复制过来. 说句实话vector的效率真的不怎么样,但是似乎也还行,最主要是……写得比较爽. #include <cstdio> #include < ...

  6. icp算法

    https://github.com/tttamaki/ICP-test https://github.com/tttamaki/SICP-test

  7. cin和gitchar的区别

    cin是iostream(输入输出类) 类下的istream(输入类)类的对象,作用是顺序输入字符串.cin.get()是cin的方法.cin.get()是C++面向对象的操作,getchar()是C ...

  8. Debug_with_docker_in_pycharm

    Debug with docker in pycharm Why As I really really appreciate it that we can have a isolated develo ...

  9. linux下svn服务器的搭建

    网上的教程实在是太恶心了,不是太老,就是有问题,刚参考的一篇文章也有问题.自己记录下来,以后用就方便了,现在一边重新安装一遍,一边记录.笔者亲测,今天是5月29号深夜. linux用的是centos6 ...

  10. svn数据的备份

    svnadmin dump -r 0:HEAD [项目名称]>[存储的文件名].dump