性能测试训练营Ⅴ

虚拟用户图分析

新增图的方法为单击顶部菜单Graph→Add New Graph,出现的界面,从中可以选择想添加查看的数据表

1、正在运行的虚拟用户

正在运行的虚拟用户(Running Vusers)直接反映了在Controller中设计场景策略、虚拟用户运行情况,以及在各个时间点虚拟用户的状态

见P74中的Running Vusers以慢慢增长方式进行加压,达到70个虚拟用户后持续运行,最后逐步减压直至结束

如果想查看不同状态的虚拟用户情况,可以用鼠标右键单击,选择Set Filter/Group By进入筛选界面,根据实际需求筛选Vuser的状态,对正在运行的虚拟用户图,一般都与其他图标合并分析才有实际意义,能够分析虚拟用户数的增加或变动会对其他指标产生什么影响,从而分析当时的性能情况。是跟平均事务响应时间合并后的结果。

可以看出,随着并发用户数的增加,平均事务响应时间增加,在X个Vuser时,事务还出现了严重的波动,这时需要继续分析波动的时间段定位问题所在

2、虚拟用户概要

虚拟用户概要(Vuser Summary)可以查看虚拟用户的状态,如有多少Stopped、有多少Failed等

错误图分析

1、错误描述统计

错误描述统计(Error Statistics)图是重点查看的图表,它会详细罗列测试过程中出现的错误类型和对应的信息,同时可以看到每种错误的数量,有时还能直接反映系统的性能问题

如连接服务器失败,遭到服务器拒绝。如果对系统熟悉,就可以判断系统出现了瓶颈无法及时处理请求

对于错误出现的timeout提示,可以通过调大Run-time Settings中的HTTP-request connect timeout(sec)、HTTP-request receive timeout(sec)和Step download timeout(sec)三个参数的值来解决

2、每秒错误数

每秒错误数(Errors per Second)图是对每秒出现的错误数进行统计,数值越小越好。如果与虚拟用户图结合来看,可以判断系统在什么时候、什么压力下开始不稳定,甚至出错

事务图分析

事务图也是需要重点观察的,它的产生是基于封装的事务。事务图的种类比较多,如平均事务响应时间图、TPS、事务概要等

1、事务概要

事务概要(Transaction Summary)可以清楚地看到哪些事务失败比较多,也可以判断出系统是否运行正常

2、平均事务响应时间

平均事务响应时间(Average Transaction Response Time)统计的是在测试场景运行期间,每秒内事务执行所用的平均时间,通过它可以分析系统的性能走向,也是最直观的指标之一。平均事务响应时间图中提供了场景运行期间事务响应时间的最大、平均、最小以及标准等差信息,对于分析十分有用

3、每秒通过事务数

每秒通过事务数(TPS)表示每秒通过的事务数、是考察系统性能的一个重要指标。通过它可以确定系统在任何时刻的事务处理能力,这个数值越高,说明系统处理能力越强。分析TPS主要是看曲线的性能走向

当压力过时,TPS曲线如果变化缓慢或者有平坦的趋势,则很有可能是服务器开始出现瓶颈

4、事务性能摘要

事务性能摘要(Transaction Performance Summary)体现了所有事务的最大响应时间、最小响应时间和平均时间,通常关注最大响应时间以及平均时间。

5、事务响应时间分布

事务响应时间分布(Transaction Response Time Distribution)可以提现不同响应时间的事务数量,清晰地看到事务响应时间的分布情况,check_itinerary事务响应时间分布

Web资源图分析

web资源图里有很多细分的图表,其实不需要全部记住,因为每个指标的变化都不是独立的,是与其他指标关联的

1、每秒点击数

每秒点击数(Hits per Second)统计的是运行场景过程中,虚拟用户每秒向Web服务器提交的HTTP请求数。该指标经常与其他指标结合进行分析

2、吞吐量

吞吐量(Throughput)统计场景运行过程中服务器的每秒吞吐量,单位是字节,表示虚拟用户在任何给定的每一秒内,从服务器获得的数据量。通过该指标可以看出服务器在流量方面的处理能力以及是否存在瓶颈,正常情况下,吞吐量与TPS图的变化基本一致。若压力增大时,吞吐量的曲线增加到一定程度后变化缓慢,甚至平坦,则很可能是网络出现带宽瓶颈。不论是吞吐量,还是TPS都非常不稳定,尤其是TPS,通过率比较低

3、HTTP状态码概要

HTTP状态码概要(HTTP Status Code Summary)统计场景运行过程中,从Web服务器返回的HTTP状态代码数,返回的都是200状态码,说明在HTTP返回层面上是成功的

4、每秒HTTP响应数

每秒HTTP响应数(HTTP Responses per Second)统计运行场景过程中,每秒从Web服务器返回的不同HTTP状态码的数量。一般和每秒点击量相同,如果服务器的响应数小于点击量,那么说明服务器无法应答,超过负载的链接请求

5、连接数

连接数(Connections)统计场景运行过程中,每个时间点打开的TCP/IP连接数。例如,当连接数dadao 稳定状态而事务响应时间迅速增大时,添加连接可以使用性能得到极大提高

6、每秒连接数

每秒连接数(Connections Per Second)统计新建的连接数和关闭的连接数,方便了解每秒对服务器产生连接的数量。同时连接数越多,说明服务器的连接池越大,当连接数随着负载上升而停止时,说明系统的连接池已满,通常这个时候服务器会返回504错误

7、每秒重试次数

每秒重试次数图显示在场景运行的每一秒内,服务器尝试的连接次数。在下列情况下将重试服务器连接

初始连接未经授权

要求代理服务器身份验证

服务器关闭了初始连接

初始连接无法连接到服务器

服务器最初无法解析负载生成器的IP地址

8、每秒SSL连接数

每秒SSL连接数图显示在场景运行的每一秒内,重新使用的SSL连接数。当对安全服务器打开TCP/IP连接后,浏览器打开SSL连接。因为新建SSL连接需要消耗大量的资源,所以应该尽量减少打开新的SSL连接。建立新SSL连接后,应该重复使用该连接。每个虚拟用户的新SSL连接数不应该超过一个。理想情况下,每秒都应该只有很少量的新TCP/IP和SSL连接

网页细分图分析

网页细分图是站在页面级别,帮助我们分析网站上有问题的元素。可以查看每个页面和组件的下载时间、大小等

1、页面组件细分

页面组件细分(Page Component Breakdown)统计每个网页及其组件的平均下载时间,单位为秒。可以直观地看到哪个组件耗时过长,通过它有助于隔离有问题的组件

2、页面下载时间细分

页面下载时间细分(Page Download Time Breakdown)统计在场景运行期间,每一秒内,每个页面组件下载时间的细分。页面组件细分图和页面下载时间细分图通常结合起来分析,首先确定有问题的组件,然后分析它们的下载过程,从而定位原因

3、第一次缓冲时间细分

第一次缓冲时间细分(Time to First Buffer Breakdown)统计成功收到从Web服务器返回的第一个缓冲之前的这段时间内,场景运行的每一秒中每个网页组件的服务器时间和网络时间。可以使用此图确定在场景运行期间,是服务器出现问题,还是网络出现问题

4、已下载组件大小

已下载组件大小(Download Component Size(KB))统计每个已经下载的网页组件的大小。通过它可以直接看出哪些组件比较大并需要进一步进行优化,以提高性能

5、网页细分总图

页面细分总图(Web Page Diagnostics)针对某一具体事务在测试过程的情况进行分析。可以理解成是几种图表的合集,可以在一个图表里完成分析。网页细分总图可按照下载时间、组件、第一次缓冲时间等几种方式进行细分

图标的合并与关联

1、图表的合并

合并图标的操作步骤:在选中的一张图表上右击,然后选择Merge Graphs选项,再选择要合并的图标即可

2、图标的关联

如果想查看某一段时间内系统的表现,可以使用图表的自动关联。以平均事务响应时间为例,在该图上右击,选择Auto Correlate,出现自动关联图标对话框,可拖动两条竖线来选择查看的范围,在Measurement to Correlate 下拉列表中可以选择要分析的事务

确定后,可看到某个时间段内的详细数据,如果时间段内Priveate Bytes呈现上升趋势,内存资源比较紧张

性能测试分析思路

1、分析原则

由外到内,有表到里,层层深入。一个应用系统性能开始出现下降的最直接表现就是系统的响应时间变长。于是,系统响应时间成为分析性能的起点

2、分析流程

虽然性能分析是一个非常复杂的过程,但一样有规则可循

一般分析的流程如下:

1)从summary的事务概要图入手。判断用户是否全部运行,事务响应时间是否合理,事务通过率如何等

2)查看错误统计图和每秒错误数图。错误统计图可以很直观地看出在运行中出现的错误。如果经验足够,有时候可以直接定位

3)查看系统资源情况。例如,CPU、内存、IO、队列等重要的指标变化

4)虚拟用户与事务的详细执行情况,如果有较多的用户无法通过,则需要检查是脚本原因,还是场景原因。如果只有一个或者少部分虚拟用户运行正常,则有可能是脚本存在问题。正常情况下,随着虚拟用户的稳定,事务响应时间也不会有太大的变化

5)查看WEB资源图。可以站在服务器端来进行分析推断

6)查看网页细分图。可以先从First Buffer Time 入手,判断是网络问题,还是服务器问题,然后再具体细分下去进行分析

性能测试报告编写

1、测试目的

测试从事务响应时间、并发用户数、系统资源使用等多个方面,以专业的性能测试技术,分析出当前系统的性能并给出解决方案

2、测试范围

对关键业务组合进行性能测试,包括登录、查询、添加、退出等业务

3、测试环境

一般测试环境的描述需要包括服务器环境、客户端环境以及网络环境。详细列出各自环境中的配置等即可

4、业务场景建模

业务场景为:登录→查询→添加→查看→退出

测试场景的设置策略为:慢增加方式,逐步加压,达到X个Vusers后保持运行,最终场景耗时

5、测试结果分析

这里就是把分析的关键数据图表以及描述进行整合,不需要的数据图标可不体现在报告中,只分析关键数据图表即可。只描述现象是不可行的,也需要写出初步的推理猜想,这样后续才能一步步验证,从而最终确定结论

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,560评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,104评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,297评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,869评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,275评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,563评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,833评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,543评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,245评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,359评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,006评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2 273
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2 268

推荐阅读更多精彩内容