LoadRunner实例教你如何进行结果分析.docx
- 文档编号:2911210
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:13
- 大小:1.13MB
LoadRunner实例教你如何进行结果分析.docx
《LoadRunner实例教你如何进行结果分析.docx》由会员分享,可在线阅读,更多相关《LoadRunner实例教你如何进行结果分析.docx(13页珍藏版)》请在冰豆网上搜索。
LoadRunner实例教你如何进行结果分析
1.前言:
LoadRunner最重要也是最难理解的地方--测试结果的分析.其余的录制和加压测试等设置对于我们来讲通过几次操作就可以轻松掌握了.
针对ResultsAnalysis我用图片加文字做了一个例子,希望通过例子能给大家更多的帮助.
这个例子主要讲述的是多个用户同时接管任务,测试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1个人接管的时间在5S内.
2.机器配置:
2.1硬件环境:
CPU:
奔四2.8E
硬盘:
100G
网络环境:
100Mbps
2.2软件环境:
操作系统:
英文windowsXP
服务器:
tomcat服务
浏览器:
IE6.0
系统结构:
B/S结构
3.添加监视资源
下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有些特殊的资源暂时在这里不做讲解了.我会在以后相继补充进来。
MercuryLoadrunnerAnalysis中最常用的5种资源.
1.Vuser
2.Transactions
3.WebResources
4.WebPageBreakdown
5.SystemResources
在Analysis中选择“Addgraph”或“Newgraph”就可以看到这几个资源了.还有其他没有数据的资源,我们没有让它显示.
如果想查看更多的资源,可以将左下角的displayonlygraphscontainingdata置为不选.然后选中相应的点“opengraph”即可.
打开Analysis首先可以看的是SummaryReport.这里显示了测试的分析摘要.应有尽有.但是我们并不需要每个都要仔细去看.下面介绍一下部分的含义:
Duration(持续时间):
了解该测试过程持续时间.测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。
StatisticsSummary(统计摘要):
只是大概了解一下测试数据,对我们具体分析没有太大的作用.
TransactionSummary(事务摘要):
了解平均响应时间Average单位为秒.
其余的看不看都可以.都不是很重要.
4.分析集合点
在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser是在什么时候集合在这个点上,又是怎样的一个被释放的过程.这个时候就需要观察Vuser-Rendezvous图.
图1
可以看到大概在3分50的地方30个用户才全部集中到start集合点,持续了3分多,在7分30的位置开始释放用户,9分30还有18个用户,11分10还有5个用户,整个过程持续了12分.
图2
上面图2是集合点与平均事务响应时间的比较图.
注:
在打开analysis之后系统LR默认这两个曲线是不在同一张图中的.这就需要自行设置了.具体步骤如下:
点击图上.右键选择mergegraphs.然后在selectgraphtomergewith中选择即将用来进行比较的graph.如图3:
图3
图2中较深颜色的是平均响应时间,浅色的为集合点,当Vuser在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个很大的考验.
接下来看一下与事务有关的参数分析.下看一张图.
图4
这张图包括AverageTransactionResponseTime和RunningVuser两个数据图.从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser达到15个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候允许14个用户同时处理事务,Vuser达到30后1分,系统响应时间最大,那么这个最大响应时间是要推迟1分钟才出现的,在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作.同时也可以看出要想将事务响应时间控制在10S内.Vuser数量最多不能超过2个.看来是很难满足用户的需求了.
做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?
所以我们要想知道在给定时间的范围内完成事务的百分比就要靠下面这个图(TransactionResponseTime(Percentile)
图中画圈的地方表示10%的事务的响应时间是在80S左右.80S对于用户来说不是一个很小的数字,而且只有10%的事务,汗.你觉得这个系统性能会好么!
实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些需要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?
以确定这个系统我们还要付出多少的代价来提高它.
TransactionResponseTime(Distribution)-事务响应时间(分布)
显示在方案中执行事务所用时间的分布.如果定义了可以接受的最小和最大事务性能时间,可以通过此图确定服务器性能是否在可接受范围内.
很明显大多数事务的响应时间在60-140S.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右.140S的时间!
很少有人会去花这么多的时间去等待页面的出现吧!
通过观察以上的数据表.我们不难看到此系统在这种环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?
让我们一步一步的分析.
系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图.
一个应用程序是由很多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个测试过程中涉及到的所有web页.webpagebreakdown中显示的是每个页面的下载时间.点选左下角webpagebreakdown展开,可以看到每个页中包括的css样式表,js脚本,jsp页面等所有的属性.
在selectpagetobreakdown中选择页面.
见图.
在SelectPageToBreakdown中选择http:
//192.168.0.135:
8888/usertasks后,在下方看到属于它的两个组件,第一行中Connection和FirstBuffer占据了整个的时间,那么它的消耗时间点就在这里,我们解决问题就要从这里下手.
名称
描述
显示使用最近的DNS服务器将DNS名称解析为IP地
址所需的时间。
“DNS查找”度量是指示DNS解析问
题或DNS服务器问题的一个很好的指示器。
显示与包含指定URL的Web服务器建立初始连接所需
的时间。
连接度量是一个很好的网络问题指示器。
此
外,它还可表明服务器是否对请求作出响应。
显示从初始HTTP请求(通常为GET)到成功收回来
自Web服务器的第一次缓冲时为止所经过的时间。
第
一次缓冲度量是很好的Web服务器延迟和网络滞后指
示器。
注意:
由于缓冲区大小最大为8K,因此第一次缓冲时
间可能也就是完成元素下载所需的时间。
显示建立SSL连接(包括客户端hello、服务器
hello、客户端公用密钥传输、服务器证书传输和其他
部分可选阶段)所用的时间。
自此点之后,客户端与服
务器之间的所有通信都将被加密。
SSL握手度量仅适用于HTTPS通信。
显示从服务器收到最后一个字节并完成下载之前经过的
时间。
“接收”度量是很好的网络质量指示器(查看用来计算
接收速率的时间/大小比率)。
显示验证客户端所用的时间。
如果使用FTP,则服务器
在开始处理客户端命令之前,必须验证该客户端。
“FTP验证”度量仅适用于FTP协议通信。
显示因浏览器思考时间或其他与客户端有关的延迟而使
客户机上的请求发生延迟时,所经过的平均时间。
显示从发出HTTP请求到返回错误消息(仅限于
HTTP错误)这期间经过的平均时间。
也有可能你的程序中client的时间最长.或者其他的,这些就要根据你自己的测试结果来分析了.下面我们来看一下CPU,内存.硬盘的瓶颈分析方法:
首先我们要监视CPU,内存.硬盘的资源情况.得到以下的参数提供分析的依据.
%processortime(processor_total):
器消耗的处理器时间数量.如果服务器专用于sqlserver可接受的最大上限是80%-85%.也就是常见的CPU使用率.
%Usertime(processor_total):
:
表示耗费CPU的数据库操作,如排序,执行aggregatefunctions等。
如果该值很高,可考虑增加索引,尽量使用简单的表联接,水平分割大表格等方法来降低该值。
%DPCtime(processor_total):
:
越低越好。
在多处理器系统中,如果这个值大于50%并且Processor:
%ProcessorTime非常高,加入一个网卡可能会提高性能,提供的网络已经不饱和。
%Disktime(physicaldisk_total):
指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
如果三个计数器都比较大,那么硬盘不是瓶颈。
如果只有%DiskTime比较大,另外两个都比较适中,硬盘可能会是瓶颈。
在记录该计数器之前,请在Windows2000的命令行窗口中运行diskperf-yD。
若数值持续超过80%,则可能是内存泄漏。
Availiablebytes(memory):
用物理内存数.如果AvailableMbytes的值很小(4MB或更小),则说明计算机上总的内存可能不足,或某程序没有释放内存。
Contextswitch/sec(system):
(实例化inetinfo和dllhost进程)如果你决定要增加线程字节池的大小,你应该监视这三个计数器(包括上面的一个)。
增加线程数可能会增加上下文切换次数,这样性能不会上升反而会下降。
如果十个实例的上下文切换值非常高,就应该减小线程字节池的大小。
%Diskreads/sec(physicaldisk_total):
每秒读硬盘字节数.
%Diskwrite/sec(physicaldisk_total):
每秒写硬盘字节数.
Pagefaults/sec:
进程产生的页故障与系统产生的相比较,以判断这个进程对系统页故障产生的影响。
Pagespersecond:
每秒钟检索的页数。
该数字应少于每秒一页
Workingset:
理线程最近使用的内存页,反映了每一个进程使用的内存页的数量。
如果服务器有足够的空闲内存,页就会被留在工作集中,当自由内存少于一个特定的阈值时,页就会被清除出工作集。
Avg.diskqueuelength:
读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
该值应不超过磁盘数的1.5~2倍。
要提高性能,可增加磁盘。
注意:
一个RaidDisk实际有多个磁盘。
Averagediskread/writequeuelength:
指读取(写入)请求(列队)的平均数
Diskreads/(writes)/s:
理磁盘上每秒钟磁盘读、写的次数。
两者相加,应小于磁盘设备最大容量。
Averagedisksec/read:
以秒计算的在此盘上读取数据的所需平均时间。
Averagedisksec/transfer:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- LoadRunner 实例教你如何进行结果分析 实例 如何 进行 结果 分析
![提示](https://static.bdocx.com/images/bang_tan.gif)