1 性能测试目的

  性能测试的目的:验证软件系统是否能够达到用户提出的性能指标,同时发现软件系统中存在的性能瓶颈,以优化软件。

最后起到优化系统的目的性能测试包括如下几个方面:

1.评估系统的能力:测试中得到的负荷和响应时长数据可以被用于验证所计划的模型的能力,并帮助做出决策

2.识别体系中的弱点:受控的负荷可以被增加到一个极端的水平并突破它,从而修复体系的瓶颈或薄弱的地方

3.系统调优:重复运行测试,验证调整系统的活动是否得到了预期的结果,从而改进性能

检测软件中的问题:长时间的测试执行可导致程序发生由于内存泄漏引起的失败,揭示程序中隐含的问题或冲突

4.验证稳定性(Resilience)、可靠性(Reliability):在一个生产负荷下执行测试-一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法

2 性能测试常见分类(相关术语)

  性能测试:Performance Testing,模拟用户负载来测试系统在负载情况下,系统的响应时间(RT)、吞吐量(TPS)等指标是否满足性能要求。

  性能测试包括负载测试、强度测试、容量测试等

2.1 负载测试(Load Testing)

  负载:模拟业务操作对服务器造成压力的过程,比如模拟100个用户进行发帖。

  负载测试:通过不断加大负载(不同虚拟用户数)来确定在满足性能指标情况下能够承受的最大用户数,即我们对系统进行定容定量,找出系统性能的拐点。性能指标只要包括TPS(每秒事务数)、RT(事务平均响应时间)、CPU Using(CPU 利用率)、Mem Using(内存使用情况)等。

  负载测试的目标:确定并确保系统在超出最大预期工作量的情况下仍能正常运行负载测试还要评估性能特征,如响应时长、事务处理速率。

2.2 强度测试(Stress Testing):压力测试

  压力测试:通过高负载的手段来使服务器资源处于极限状态,测试系统在极限状态下长时间运行是否稳定,确定稳定的指标主要包括TPS、RT、CPU Using、Mem Using等。

  比如测试一个web站点在大量负荷下,何时系统的响应会退化或失败。

2.3 容量测试(Volume Testing)

  容量测试确定系统可处理同时在线的最大用户数

针对上述 负载测试、压力测试、容量测试 举个例子
例:一个人背X斤
负载测试:200斤情况下,是否能坚持5分钟
压力测试:200,300,400... 斤情况下,他的表现,什么时候失败,失败之后什么表现,重新扛200是否正常
容量测试:在坚持5分钟的情况下,他一次最多能扛多少斤

2.4 配置测试:Configration Testing

  配置测试:为了合理地调配资源,提高系统运行效率,通过测试手段来获取、验证、调整配置信息的过程。通过这个过程我们可以收集到不同配置反映出来的不同性能,从而为设备选择、设备配置提供参考。

2.5 稳定性测试

  稳定性测试:长时间运行一定负载,确定系统在满足性能指标的前提下是否运行稳定。满足性能要求的情况下,系统的稳定性、比如响应时间是否稳定、TPS是否稳定。一般会在满足要求的负载情况下加大1.5-2倍的负载量进行测试。

2.6 性能测试指标

  TPS(Transaction Per Second):每秒完成的事务数,通常指每秒成功的事务数。一个事务是一个业务度量单位,有时一个事务会包括多个子操作(多个子操作统计为一个事务)。比如一笔电子支付操作,在后台操作中可能会经历会员系统、账务系统、支付系统、会计系统、银行网关等,但对于用户来说只想知道整笔支付花费了多长时间。

  QPS(Query Per Second):每秒查询率,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

  RT/ART(Response Time / Average Response Time):响应时间/平均响应时间,指一个事务花费多长时间完成(多长时间响应客户请求)。

  PV(Page View):每秒用户访问页面的次数,此参数用来分析平均每秒有多少用户访问页面。

  Vuser虚拟用户(Virtual user):模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。

  思考时间(Think Time):模拟正式用户在实际操作时的停顿间隔时间。在测试脚本中,思考时间体现为脚本中两个请求语句之间的间隔时间。

  标准差(Std. Deviation):该标准差根据整理统计的概念得来,标准差越小,说明波动越小,系统越稳定,反之,标准差越大,说明波动越大,系统越不稳定。包括响应时间标准差、TPS标准差、Running Vuser标准差、Load标准差、CPU资源利用率标准差、Web Resources标准差等。

  场景(Scenario):为了模拟真实用户的业务处理过程,构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等的一系列动作的集合,称为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。

3 性能测试的常见指标

  常见的两种架构进行软件测试:B/S、C/S

3.1 B/S架构-常见性能指标

对于B/S架构的软件,一般会关注如下Web服务器性能指标

概念

说明

Avg Rps

平均每秒钟的响应次数=总请求次数/秒数

Avg time to last byte per terstion(mstes)

平均每秒业务脚本的迭代次数

Successful Rounds

成功的请求

Failed Rounds

失败的请求

Successful Hits

成功的点击次数

Failed Hits

失败的点击次数

Hits Per Second

每秒点击次数

Successful Hits Per Second

每秒成功的点击次数

Failed Hits Per Second

每秒失败的点击次数

Attempted Connections

尝试连接数

Throughput

吞吐率

3.2 C/S架构-常见性能指标

  对于C/S架构的程序,由于软件后台通常为数据库,所以我们更注重数据库的测试指标。

除了表格里面的概念,还有部分指标:CPU占用率、内存占用率、数据库连接池等。

概念

说明

User Connections

用户连接数,也就是数据库的连接数量

Number of Deadlocks

数据库死锁

Butter Cache Hit

数据库Cache的命中情况

4 性能测试结果分析

4.1如何分析性能测试结果

  1. 分析在整个性能测试执行期间,测试环境是否稳定正常。

例如,测试期间运行Jmeter的及其CPU占用率经常达到100%(或内存占用很高)、测试网络出现拥塞导致响应延迟、待测系统参数配置错误(JDBC连接池等).....

   2. 检查jmeter测试脚本参数设置是否合理、检查jmeter运行模式是否合理。

例如,线程组的参数Ramp-Up Period(in seconds)设置为0或1,jmeter就会瞬间启动该线程组下的所有虚拟用户,会为待测服务器造成巨大的压力,轻则导致服务器响应时长超长,重则导致部分虚拟用户等待响应超时而报错。

   3. 检查测试结果是否暴露出了系统瓶颈。

性能测试分析的原则:由表及里、由内而外、抽丝剥茧

响应时长,主要包括2部分:服务器响应时长(应用服务器、数据库服务器的响应时长)、网络响应时长。

4.2 如何借助监听器发现性能缺陷

4.2.1 图形结果(Graph Results)

概念

说明

样本数目

总共发送到服务器的请求数

最新样本(黑色)

代表时间的数字,是服务器响应最后一个请求的时间(当前采样响应时长)

吞吐量(绿色)

服务器每分钟处理的实际请求数

平均值(蓝色)

总运行时间除以发送到服务器的请求数(平均采样响应时长)

中间值(紫色)

代表时间的数字,有一半的服务器响应时间低于该值而另一半高于该值

偏离(红色)

服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布

测试人员可以通过增加并发线程数或减少脚本中的延迟,来找到系统支持的最大吞吐率。

图形结果中比较有参考价值的字段是:平均值、偏离、吞吐量。

4.2.1.1平均值

随着并发压力的加大,以及时间延长,系统性能所发生的变化。正常情况下,平均采样响应时长曲线应该是平滑的,并大致平行于图形下边界。

可能存在性能问题的平均值:

平均值在初始阶段跳升,而后逐渐平稳起来。

一是系统在初始阶段存在性能缺陷,需要进一步优化,如数据库查询缓慢

二是系统有缓存机制,而性能测试数据在测试期间没有变化,如此一来同样的数据在初始阶段的响应时长肯定较慢;这属于性能测试数据准备的问题,不是性能缺陷,需调整后在测试

三是系统架构设计导致的固有现象,例如在系统接收到第一个请求后,才去建立应用服务器到数据库的链接,后续一段时间内不会释放连接。

平均值持续增大,图片变得越来越陡峭

一是可能存在内存泄漏,此时可以通过监控系统日志、监控应用服务器状态等常见方法,来定位问题。

平均值在性能测试期间,突然发生跳变,然后又恢复正常

一是可能存在系统性能缺陷

二是可能由于测试环境不稳定所造成的(检查应用服务器状态【CPU占用、内存占用】或者检查测试环境网络是否存在拥塞)

4.2.1.2 偏离

观察采样响应时长标准差,可以判断数据的分布是否均匀。理想状态是平滑的。

4.2.1.3 吞吐量

  服务器每分钟处理的实际采样数。首先通过增加并发线程数或减少脚本中的延迟,来找到系统支持的最大吞吐率。然后将系统实际支持的最大吞吐率和预期吞吐率进行比较,以便确认系统表现是否满足用户需求。

4.2.2 断言结果(Assertion Results)

断言结果试图会展示每个采样携带的标签,如果断言有问题,会进行显示。

4.2.3 查看结果树(View Results Tree)

查看结果树会以树的方式来展示所有采样响应结果,测试人员可以通过它来查看任何采样的响应。

查看结果数一般用于调试性能测试脚本。还可以通过查询结果,利用正则表达式,从响应结果中提取数据。

4.2.4用表格查看结果

为每一个采样结果创建一行,但是会占用较多内存。

在“用表格查看结果”中,测试人员可以看到采样时间、系统响应时长、字节数等,且可以确定问题采样发生的准确时刻。

4.2.5聚合报告(Aggreate Report)

部分概念如下:

概念

说明

Label

说明是请求类型,如Http,FTP等请求

#Samples

也就是图形报表中的样本数目,总共发送到服务器的样本数目

Average

也就是图形报表中的平均值,是总运行时间除以发送到服务器的请求数(平均响应时间)

Median

也就是图形报表中的中间值,是代表时间的数字,有一半的服务器响应时间低于该值而另一半高于该值

90%line

是指90%请求的响应时间比所得数值还要小

Min

是代表时间的数字,是服务器响应的最短时间

Max

是代表时间的数字,是服务器响应的最长时间

Error%

请求的错误百分比

Throughput

也就是图形报表中的吞吐量,这里是服务器每单位时间处理的请求数,注意查看是秒或是分钟

KB/sec

是每秒钟请求的字节数(数据传输量)

Throughput

也就是图形报表中的吞吐量,这里是服务器每单位时间处理的请求数,注意查看是秒或是分钟

聚合报告综合判断系统性能是否满足要求。比较关心的几个统计值,包括平均响应时长、90%阈值、吞吐率(每秒完成请求数)、错误率。

PS:90%line的定义:

一组数由小到大进行排列,找到他的第90%个数(假如是12),那么这个数组中有90%的数将小于等于12 。

用在性能测试的响应时间也将非常有意义,也就是90%请求响应时间不会超过12 秒。

4.2.6 聚合图形(Aggregate graph)

聚合图形与聚合报告一致,区别在于聚合图形有生成的图表。

4.2.7概要报告(summary report)

概念

说明

Label

采样标签

#Samples

标签名相同的总采样数

Average

请求(事务)的平均响应时间

Min

标签名相同的采样中,最小的响应时长

Max

标签名相同的采样中,最大的响应时长

Std.Dev.

采样响应时长的标准差

Error%

事务发生错误的比率

Throughput

该吞吐率以每秒/分钟/小时发生的采样数来衡量(TPS)

KB/sec

吞吐量以每秒KB来衡量(即每秒数据包流量)

Avg.Bytes

以字节为单位的采样响应平均大小(平均数据流量)

4.2.8服务器性能监控设置

JMeter使用plugins插件进行服务器性能监控,对服务器的 CPU、内存、Swap、磁盘 I/O、网络 I/O 进行监控。客户端添加CPU监控Permon Metrics Collector,服务器端开启代理,在HTTP请求的时候,就能进行服务器资源的监控情况。

4.2.8.1服务器插件下载

访问网址https://jmeter-plugins.org/downloads/old/,下载三个文件。其中客户端插件JMeterPlugins-Standard和JMeterPlugins-Extras(目前我使用的版本是1.4.0),

访问网址https://jmeter-plugins.org/wiki/Start/,下载服务器端插件ServerAgent的。

4.2.8.2插件客户端配置

  解压客户端的两个文件,进入其路径JMeterPlugins-Extras(Standard)-1.3.1\lib\ext,复制JmeterPlugins-Extras.jar(JmeterPlugins-Standard.jar)两个文件,放到JMeter客户端的lib/ext文件夹中,打开JMeter,可在监听器中看到Permon Metrics Collector,客户端配置成功。

4.2.8.3插件服务器端配置

  将ServerAgent-2.2.1.jar上传到被测服务器,解压,进入目录,Windows环境,双击ServerAgent.bat启动;linux环境执ServerAgent.sh启动,默认使用4444端口,出现如下情况

即服务端配置成功。

11-4.Permon Metrics Collector监控的执行

性能测试学习之路 (三)jmeter常见性能指标(相关术语、聚合报告 && 服务器性能监控配置 && 图形结果 && 概要报告)的更多相关文章

  1. Jmeter plugins 之 Perfmon Metrics Collector(服务器性能监控)

    客户端(Jmeter端) 1.安装plugins manager,然后安装  2.添加listener-(第1步成功后才可看到此功能)  服务端:(要监控的服务器) 1.下载ServerAgent,并 ...

  2. 学习之路三十九:新手学习 - Windows API

    来到了新公司,一开始就要做个程序去获取另外一个程序里的数据,哇,挑战性很大. 经过两周的学习,终于搞定,主要还是对Windows API有了更多的了解. 文中所有的消息常量,API,结构体都整理出来了 ...

  3. JMeter使用plugins插件进行服务器性能监控

    JMeter使用plugins插件进行服务器性能监控 性能测试时,我们的关注点有两部分 1 服务本身:并发响应时间 QPS 2 服务器的资源使用情况:cpu memory I/O disk等 JMet ...

  4. jmeter使用笔记——脚本录制,JMeter使用plugins插件进行服务器性能监控

    脚本录制: 1.badboy录制 2.代理服务器录制 ①工作台添加HTTP代理服务器 ②设置目标控制器,分组,排除模式,包含模式(使用正则表达式筛选) ③设置浏览器,手动设置代理服务器,localho ...

  5. 性能测试学习之路 (一)认识jmeter(性能测试流程 && 性能测试通过标准 &&jmeter体系结构)

    性能测试是通过自动化的测试工具模拟多种正常.峰值以及异常负载条件来对系统的各项性能指标进行测试. 1 性能测试技能树 性能测试是一项综合性的工作,致力于暴露性能问题,评估系统性能趋势.性能测试工作实质 ...

  6. 性能测试学习之路 (二)jmeter详解(jmeter执行顺序 && 作用域 && 断言 && 事务 &&集合点 )

    1 Jmeter 工作区介绍 jmeter工作区分为3个部分:目录树.测试计划编辑区域.菜单栏. 2 Jmeter 执行顺序规则 Jmeter执行顺序规则如下: 配置元件 前置处理器 定时器 采样器s ...

  7. Redis——学习之路三(初识redis config配置)

    我们先看看config 默认情况下系统是怎么配置的.在命令行中输入 config get *(如图) 默认情况下有61配置信息,每一个命令占两行,第一行为配置名称信息,第二行为配置的具体信息.     ...

  8. 【JMeter】【性能测试】服务器性能监控

    下载插件 1.访问网址http://jmeter-plugins.org/downloads/all/,下载三个文件.其中JMeterPlugins-Standard和JMeterPlugins-Ex ...

  9. 微软企业库5.0 学习之路——第四步、使用缓存提高网站的性能(EntLib Caching)

    首先先补习下企业库的Caching Application Block的相关知识: 1.四大缓存方式,在Caching Application Block中,主要提供以下四种保存缓存数据的途径,分别是 ...

随机推荐

  1. javascript-闭包【面试必备】

    闭包 定义:内层函数可以访问外层函数作用域的变量 意义/用途: 1.封装细节 2.实现模块化 3.常用实战li列表 // querySelectorAll es5支持的一个类似于jq的复杂选择器选取d ...

  2. 使用LSV进行通视分析教程

    在LSV"分析"菜单栏中点击"通视分析" 在地面或者建筑物表面选择一点,然后鼠标移动到另一个位置点击结束,即可判断出两点间是否有障碍物,是否可见.通视分析结果显 ...

  3. Boltzmann Machine 玻尔兹曼机入门

    Generative Models 生成模型帮助我们生成新的item,而不只是存储和提取之前的item.Boltzmann Machine就是Generative Models的一种. Boltzma ...

  4. S5830 android 2.3.4和2.3.7

    12年元旦买的手机S5830,原机自带2.3.4的系统. 看到人家的机子2.3.6的效果稍微绚一点,动了想刷机的念头. 前两天刷了2.3.7,效果还满意,用的还舒服,感觉就是有些费电, 本来就对智能手 ...

  5. [MIT6.006] 11. Integer Arithmetic, Karatsuba Multiplication 整型算术,Karatsuba乘法

    很多人不喜欢√2的表达,他们认为它不是一个数. 一.卡塔兰数 Catalan numbers 在数方面上,有个著名的数叫卡塔兰数 Catalan numbers,它是组合数学中一个常在各种计数问题中出 ...

  6. 机器学习-对数logistics回归

    今天 学习了对数几率回归,学的不是很明白x1*theat1+x2*theat2...=y 对于最终的求解参数编程还是不太会,但是也大致搞明白了,对数几率回归是由于线性回归函数的结果并不是我们想要的,我 ...

  7. mysql之用户

    1.通过Navicat For Mysql可以查看目前的用户情况 2.创建用户 create user 'Fqq'@'127.0.0.1' IDENTIFIED by '123'; -- 创建一个用户 ...

  8. [LeetCode题解]876. 链表的中间结点 | 快慢指针

    解题思路 使用快慢指针.这里要注意的是,while 的条件会影响当中间节点有两个时,slow 指向的是第一个,还是第二个节点. // 返回的是第一个 while(fast.next != null & ...

  9. xctf攻防世界——crackme writeup

    感谢xctf提供学习平台 https://adworld.xctf.org.cn crackme有壳,脱壳部分见文章: https://www.cnblogs.com/hongren/p/126332 ...

  10. C# 9 record 并非简单属性 POCO 的语法糖

    C# 9 record 并非简单属性 POCO 的语法糖 最近升级专案到大统一 .NET 5 并使用 C#9 语法尝试改写套件,发现之前以为 record 只是简单属性 POCO 的简化语法糖的认知是 ...