具体的例子来教你怎么做LoadRunner结果分析

LoadRunner 解的地方--測试结果的分析.其余的录制和加压測试等设置对于我们来讲通过几次操作就能够轻松掌握了.针对 Results Analysis 我用图片加文字做了一个样例,希望通过样例能给大家很多其它的帮助.这个样例主要讲述的是多个用户同一时候接管任务,測试系统的响应能力,确定系统瓶颈所在.客户要求响应时间是1 个人接管的时间在5S 内.

　　2.系统资源:

　　2.1 硬件环境：

　　CPU：奔四2.8E

　　硬盘：100G

　　网络环境：100Mbps

　　2.2 软件环境：

　　操作系统：英文windowsXP

　　server：tomcat 服务

　　浏览器：IE6.0

　　系统结构：B/S 结构

　　3.加入监视资源

　　以下要讲述的样例加入了我们寻常測试中最经常使用到的一些资源參数.另外有些特殊的资源临时在这里不做解说了.我会在以后相继补充进来。

　　Mercury Loadrunner Analysis 中最经常使用的5 种资源.

　　1. Vuser

　　2. Transactions

　　3. Web Resources

　　4. Web Page Breakdown

　　5. System Resources

　　在Analysis 中选择“Add graph”或“New graph”就能够看到这几个资源了.还有其它没有数据的资源,我们没有让它显示.

　　

　　假设想查看很多其它的资源,能够将左下角的display only graphs containing data 置为不选.然后选中对应的点“open graph”就可以.

　　打开Analysis 首先能够看的是Summary Report.这里显示了測试的分析摘要.应有尽有.可是我们并不须要每一个都要细致去看.以下介绍一下部分的含义：

　　Duration(持续时间)：了解该測试过程持续时间.測试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次添加很多其它的任务条件下測试的持续时间。

　　Statistics Summary(统计摘要)：仅仅是大概了解一下測试数据,对我们详细分析没有太大的作用.

　　Transaction Summary(事务摘要)：了解平均响应时间Average单位为秒.

　　其余的看不看都能够.都不是非常重要.

【注】 51Testing授权IT168独家转载，未经明白的书面许可，不论什么人或单位不得对本文内容复制、转载或进行镜像，否则将追究法律责任。

内容导航

　　4.分析集合点

　　在录制脚本中通常我们会使用到集合点,那么既然我们用到了集合点,我们就须要知道Vuser 是在什么时候集合在这个点上,又是如何的一个被释放的过程.这个时候就须要观察Vuser-Rendezvous 图.

　　

　　图1

　　能够看到大概在3 分50 的地方30 个用户才所有集中到start 集合点,持续了3 分多,在7 分30 的位置開始释放用户,9 分30 还有18 个用户,11 分10 还有5 个用户,整个过程持续了12 分.

　　

　　图2

　　上面图2 是集合点与平均事务响应时间的比較图.

　　注:在打开analysis 之后系统LR 默认这两个曲线是不在同一张图中的.这就须要自行设置了.详细过程例如以下:

　　点击图上.右键选择merge graphs.然后在select graph to merge with 中选择即将用来进行比較的graph.如图3:

　　

　　图3

　　图2 中较深颜色的是平均响应时间,浅色的为集合点,当Vuser 在集合点持续了1分后平均响应时间呈现最大值,可见用户的并发对系统的性能是一个非常大的考验.接下来看一下与事务有关的參数分析.下看一张图.

　　

　　图4

　　这张图包含Average Transaction Response Time 和Running Vuser 两个数据图.从图中能够看到Vuser_init_Transaction(系统登录)对系统无不论什么的影响,Vuser 达到15 个的时候平均事务响应时间才有明显的升高,也就是说系统达到最优性能的时候同意14 个用户同一时候处理事务,Vuser 达到30 后1 分,系统响应时间最大,那么这个最大响应时间是要推迟1 分钟才出现的,在系统稳定之后事务响应时间開始下降说明这个时候有些用户已经运行完了操作.同一时候也能够看出要想将事务响应时间控制在10S
内.Vuser 数量最多不能超过2 个.看来是非常难满足用户的需求了.

　　做一件事有时候上级会问你这件事办得怎么样了.你会说做完一半了.那么这个一半的事情你花了多少时间呢?

所以我们要想知道在给定时间的范围内完毕事务的百分比就要靠以下这个图(Transaction Response Time(Percentile)

　　

　　图中画圈的地方表示10%的事务的响应时间是在80S 左右.80S 对于用户来说不是一个非常小的数字,并且仅仅有10%的事务,汗.你认为这个系统性能会好么!

　　实际工作中遇到的事情不是每一件事都可以在非常短的时间内完毕的,对于那些须要时间的事情我们就要分配适当的时间处理,时间分配的不均匀就会出现有些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR
相同也为我们提供了这种功能,使我们能够了解大部分的事务响应时间是多少?以确定这个系统我们还要付出多少的代价来提高它.

　　Transaction Response Time(Distribution)-事务响应时间(分布)

　　显示在方案中运行事务所用时间的分布.假设定义了能够接受的最小和最大事务性能时间,能够通过此图确定server性能是否在可接受范围内.

　　

　　非常明显大多数事务的响应时间在60-140S.在我測试过的项目中多数客户所能接受的最大响应时间也要在20S 左右.140S 的时间!非常少有人会去花这么多的时间去等待页面的出现吧!

　　通过观察以上的数据表.我们不难看到此系统在这样的环境下并不理想.世间事有果就有因,那么是什么原因导致得系统性能这样差呢?

让我们一步一步的分析.

　　系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR 的功能真的非常强大,这也是我喜欢它的原因.先看一张页面细分图.

　　

　　一个应用程序是由非常多个组件组成的,整个系统性能不好那我们就把它彻底的剖析一下.图片中显示了整个測试过程中涉及到的全部web 页.web page breakdown中显示的是每一个页面的下载时间.点选左下角web page breakdown 展开,能够看到每一个页中包含的css 样式表,js 脚本,jsp 页面等全部的属性.

　　在select page to breakdown 中选择页面.

　　

　　见图.

　　在 Select Page To Breakdown 中选择http://192.168.0.135:8888/usertasks 后,在下方看到属于它的两个组件,第一行中Connection 和First Buffer 占领了整个的时间,那么它的消耗时间点就在这里,我们解决这个问题就要从这里下手.

　　

　　

　　也有可能你的程序中client 的时间最长.或者其它的,这些就要依据你自己的測试结果来分析了.以下我们来看一下CPU,内存.硬盘的瓶颈分析方法:

　　首先我们要监视CPU,内存.硬盘的资源情况.得到下面的參数提供分析的根据.

       %processor time(processor_total):器消耗的处理器时间数量.假设服务器专用于sql server 可接受的最大上限是80%
-85 %.也就是常见的CPU 使用率.

　　%User time(processor_total)::表示耗费CPU的数据库操作，如排序，运行aggregate
functions等。假设该值非常高，可考虑添加索引。尽量使用简单的表联接。水平切割大表格等方法来减少该值。

　　%DPC time(processor_total)::越低越好。在多处理器系统中。假设这个值大于50%而且Processor:% Processor Time很高。增加一个网卡可能会提高性能。提供的网络已经不饱和。

　　%Disk time(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。假设三个计数器都比較大，那么硬盘不是瓶颈。假设仅仅有%Disk Time比較大。另外两个都比較适中，硬盘可能会是瓶颈。

在记录该计数器之前，请在Windows 2000
的命令行窗体中执行diskperf -yD。若数值持续超过80%，则可能是内存泄漏。

　　Availiable bytes(memory):用物理内存数. 假设Available Mbytes的值非常小(4 MB 或更小)，则说明计算机上总的内存可能不足。或某程序没有释放内存。

　　Context switch/sec(system): (实例化inetinfo 和dllhost 进程) 假设你决定要添加线程字节池的大小，你应该监视这三个计数器(包含上面的一个)。

添加线程数可能会添加上下文切换次数，这样性能不会上升反而会下降。假设十个实例的上下文切换值很高。就应该减小线程字节池的大小。

　　%Disk reads/sec(physicaldisk_total):每秒读硬盘字节数.

　　%Disk write/sec(physicaldisk_total):每秒写硬盘字节数.

　　Page faults/sec:进程产生的页故障与系统产生的相比較，以推断这个进程对系统页故障产生的影响。

　　Pages per second:每秒钟检索的页数。

该数字应少于每秒一页Working set:理线程近期使用的内存页。反映了每个进程使用的内存页的数量。假设server有足够的空暇内存。页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

　　Avg.disk queue length:读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可添加磁盘。注意：一个Raid Disk实际有多个磁盘。

　　Average disk read/write queue length: 指读取(写入)请求(列队)的平均数Disk reads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。

　　Average disk sec/read:以秒计算的在此盘上读取数据的所需平均时间。

Average disk sec/transfer:指以秒计算的在此盘上写入数据的所需平均时间。

　　Bytes total/sec:为发送和接收字节的速率。包含帧字符在内。

推断网络连接速度是否是瓶颈，能够用该计数器的值和眼下网络的带宽比較Page read/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在全部数据库间的物理页读取总数。因为物理 I/O 的开销大。能够通过使用更大的数据快速缓存、智能索引、更高效的查询或者改变数据库设计等方法。使开销减到最小。

　　Page write/sec:(写的页/秒)每秒运行的物理数据库写的页数。

内容导航

　　1. 推断应用程序的问题

　　假设系统因为应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(context switches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,假设系统的吞吐量减少而且CPU的使用率非常高,而且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.

　　

　　从图的总体看.context switches/sec变化不大,throughout曲线的斜率较高,而且此时的contextswitches/sec已经超过了15000.程序还是须要进一步优化.

　　2. 推断CPU瓶颈

　　假设processor queue length显示的队列长度保持不变(>=2)个而且处理器的利用率%Processortime超过90%,那么非常可能存在处理器瓶颈.假设发现processor queue length显示的队列长度超过2,而处理器的利用率却一直非常低,也许更应该去解决处理器堵塞问题,这里处理器一般不是瓶颈.

　　

　　%processor time平均值大于95,processor queue length大于2.能够确定CPU瓶颈.此时的CPU已经不能满足程序须要.急需扩展.

　　3. 推断内存泄露问题

　　内存问题主要检查应用程序是否存在内存泄漏,假设发生了内存泄漏,process\private bytes计数器和process\working set 计数器的值往往会升高,同一时候avaiable bytes的值会减少.内存泄漏应该通过一个长时间的,用来研究分析全部内存都耗尽时,应用程序反应情况的測试来检验.

　　

　　图中能够看到该程序并不存在内存泄露的问题.内存泄露问题常常出如今服务长时间运转的时候,因为部分程序对内存没有释放,而将内存慢慢耗尽.也是提醒大家对系统稳定性測试的关注.

　　附件:

　　CPU信息：

　　Processor\ % Processor Time 获得处理器使用情况。

　　也能够选择监视 Processor\ % User Time 和 % Privileged Time 以获得具体信息。

　　Server Work Queues\ Queue Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。

　　System\ Processor Queue Length 用于瓶颈检測通过使用 Process\ % Processor Time 和 Process\ Working Set

　　Process\ % Processor Time过程的全部线程在每一个处理器上的处理器时间总和。

　　硬盘信息：

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　比如，包含 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。假设页面读取操作速率非常低，同一时候 % Disk Time 和 Avg.Disk Queue Length的值非常高，则可能有磁盘瓶径。可是，假设队列长度添加的同一时候页面读取速率并未减少，则内存不足。

　　Physical Disk\ % Disk Time

　　Physical Disk\ Avg.Disk Queue Length

　　比如，包含 Page Reads/sec 和 % Disk Time 及 Avg.Disk Queue Length。假设页面读取操作速率非常低，同一时候 % Disk Time 和 Avg.Disk Queue Length的值非常高。则可能有磁盘瓶径。可是。假设队列长度添加的同一时候页面读取速率并未减少，则内存不足。

　　请观察 Processor\ Interrupts/sec 计数器的值。该计数器測量来自输入/输出 (I/O) 设备的服务请求的速度。假设此计数器的值明显添加，而系统活动没有对应添加，则表明存在硬件问题。

　　Physical Disk\ Disk Reads/sec and Disk Writes/sec

　　Physical Disk\ Current Disk Queue Length

　　Physical Disk\ % Disk Time

　　LogicalDisk\ % Free Space

　　測试磁盘性能时，将性能数据记录到还有一个磁盘或计算机，以便这些数据不会干扰您正在測试的磁盘。

　　可能须要观察的附加计数器包含 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。

　　Avg.Disk sec/Transfer 计数器反映磁盘完毕请求所用的时间。较高的值表明磁盘控制器因为失败而不断重试该磁盘。这些故障会添加平均磁盘传送时间。

对于大多数磁盘。较高的磁盘平均传送时间是大于 0.3 秒。

　　也能够查看 Avg.Disk Bytes/Transfer 的值。值大于 20 KB 表示该磁盘驱动器通常执行良好;假设应用程序正在訪问磁盘。则会产生较低的值。

比如，随机訪问磁盘的应用程序会添加平均 Disk sec/Transfer 时间。由于随机传送须要添加搜索时间。

　　Disk Bytes/sec 提供磁盘系统的吞吐率。

　　决定工作负载的平衡要平衡网络server上的负载，须要了解server磁盘驱动器的繁忙程度。使用 Physical Disk\ %Disk Time 计数器，该计数器显示驱动器活动时间的百分比。假设 % Disk Time 较高(超过90%)。请检查 Physical Disk\ Current Disk Queue Length 计数器以查看正在等待磁盘訪问的系统请求数量。

等待 I/O 请求的数量应当保持在不大于组成物理磁盘的主轴数的 1.5 到2倍。

　　虽然便宜磁盘冗余阵列 (RAID) 设备通常有多个主轴。大多数磁盘有一个主轴。硬件 RAID设备在“系统监视器”中显示为一个物理磁盘;通过软件创建的 RAID 设备显示为多个驱动器(实例)。能够监视每一个物理驱动器(而不是 RAID)的 Physical Disk 计数器，也能够使用 _Total 实例来监视全部计算机驱动器的数据。

　　使用 Current Disk Queue Length 和 % Disk Time 计数器来检測磁盘子系统的瓶颈。假设Current Disk Queue Length 和 % Disk Time 的值始终较高，能够考虑升级磁盘驱动器或将某些文件举到另一个磁盘或server。