loadrunner-analysis实例结果图表分析

这个例子主要讲述的是多个用户同时接管任务，测试系统的响应能力，确定系统瓶颈所在。客户要求响应时间是1个人接管的时间在5S内。打开Analysis首先可以看到的是SummaryReport。这里显示了测试的分析摘要，但是我们并不需要每个都仔细去看。下面介绍一下部分的含义：Duration(持续时间)：了解该测试过程持续时间。测试人员本身要对这个时期内系统一共做了多少的事有大致的熟悉了解.以确定下次增加更多的任务条件下测试的持续时间。StatisticsSummary(统计摘要)：只是大概了解一下测试数据，对我们具体分析没有太大的作用.TransactionSummary(事务摘要)：了解平均响应时间Average单位为秒。其余的看不看都可以，都不是很重要。1、分析集合点在录制脚本中通常我们会使用到集合点，那么既然我们用到了集合点，我们就需要知道Vuser是在什么时候集合在这个点上，又是怎样的一个被释放的过程。这个时候就需要观察Rendezvous图。(添加新图-vuser-rendezvous打开图)图1可以看到大概在3分50的地方30个用户才全部集中到start集合点，持续了3分多，在7分30的位置开始释放用户，9分30还有18个用户，11分10还有5个用户，整个过程持续了12分。2、集合点与平均事务响应时间的比较图。图2注：打开图的具体步骤:点击图上，右键选择mergegraphs，然后在selectgraphtomergewith中选择即将用来进行比较的graph。图2中较深颜色的是平均响应时间，浅色的为集合点，当Vuser在集合点持续了1分后平均响应时间呈现最大值，可见用户的并发对系统的性能是一个很大的考验。3、接下来看一下与事务有关的参数分析。AverageTransactionResponseTime和RunningVuser两个数据图图4从图中可以看到Vuser_init_Transaction(系统登录)对系统无任何的影响，Vuser达到15个的时候平均事务响应时间才有明显的升高，也就是说系统达到最优性能的时候允许14个用户同时处理事务，Vuser达到30后1分，系统响应时间最大，那么这个最大响应时间是要推迟1分钟才出现的，在系统稳定之后事务响应时间开始下降说明这个时候有些用户已经执行完了操作。同时也可以看出要想将事务响应时间控制在10S内，Vuser数量最多不能超过2个，看来是很难满足用户的需求了。4、TransactionResponseTime(Percentile)查看百分比图中画圈的地方表示10%的事务响应时间是在80S左右。80S对于用户来说不是一个很小的数字，而且只有10%的事务，汗！你觉得这个系统性能会好么！实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的，对于那些需要时间的事情我们就要分配适当的时间处理，时间分配的不均匀就会出现有些事情消耗的时间长一些，有些事情消耗的短一些，但我们自己清楚LR同样也为我们提供了这样的功能，使我们可以了解大部分的事务响应时间是多少，以确定这个系统我们还要付出多少的代价来提高它。5、TransactionResponseTime(Distribution)-事务响应时间(分布)显示在方案中执行事务所用时间的分布。如果定义了可以接受的最小和最大事务性能时间，可以通过此图确定服务器性能是否在可接受范围内。很明显大多数事务的响应时间在60-140S。一般多数客户所能接受的最大响应时间也要在20S左右。140S的时间很少有人会去花这么多的时间去等待页面的出现吧！通过观察以上的数据表，我们不难看到此系统在这种环境下并不理想。世间事有果就有因，那么是什么原因导致得系统性能这样差呢？让我们一步一步的分析。系统性能不好的原因多方面，我们先从应用程序看，有的时候我不得不承认LR的功能真的很强大，这也是我喜欢它的原因。6、页面细分图。（如果analysis中找不到该图，运行之前在run-time-setting中preference勾选pagespersecond(HTMLModeonlyanalysis中就会有)一个应用程序是由很多个组件组成的，整个系统性能不好那我们就把它彻底的剖析一下。图片中显示了整个测试过程中涉及到的所有web页。webpagebreakdown中显示的是每个页面的下载时间。点选左下角webpagebreakdown展开，可以看到每个页中包括的css样式表，js脚本，jsp页面等所有的属性。在selectpagetobreakdown中选择页面。见图。在SelectPageToBreakdown中选择后，在下方看到属于它的两个组件，第一行中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:指以秒计算的在此盘上写入数据的所需平均时间。Bytestotal/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。Pageread/sec:每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理I/O的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。Pagewrite/sec:(写的页/秒)每秒执行的物理数据库写的页数。1、判断应用程序的问题如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(contextswitches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源，如果系统的吞吐量降低并且CPU的使用率很高，并且此现象发生时切换水平在15000以上，那么意味着上下文切换次数过高。从图的整体看contextswitches/sec变化不大，throughout曲线的斜率较高，并且此时的contextswitches/sec已经超过了15000。程序还是需要进一步优化。2、判断CPU瓶颈如果processorqueuelength显示的队列长度保持不变(=2)个并且处理器的利用率%Processortime超过90%，那么很可能存在处理器瓶颈。如果发现processorqueuelength显示的队列长度超过2，而处理器的利用率却一直很低，或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。%processortime平均值大于95，processorqueuelength大于2，可以确定CPU瓶颈，此时的CPU已经不能满足程序需要，急需扩展。3、判断内存泄露问题内存问题主要检查应用程序是否存在内存泄漏，如果发生了内存泄漏，process\privatebytes计数器和process\workingset计数器的值往往会升高，同时avaiablebytes的值会降低。内存泄漏应该通过一个长时间的用来研究分析所有内存都耗尽时，应用程序反应情况的测试来检验。图中可以看到该程序并不存在内存泄露的问题，内存泄露问题经常出现在服务长时间运转的时候，由于部分程序对内存没有释放，而将内存慢慢耗尽。也是提醒大家对系统稳定性测试的关注。附件:CPU信息：Processor\%ProcessorT