具体实例教你如何使用lr进行结果分析

前言LoadRunner最重要也是最难理解的地方--的分析.其余的录制和加针对Resultsysis我用加文字做了一个例子,希望通过例子能给大家统瓶颈所在.15S内.系统资源CPU：奔四2.8E服务器：tomcat服务系统结/S结添加监视资下面要讲述的例子添加了我们平常测试中最常用到的一些资源参数.另外有MercuryLoadrunnerysis中最常用的5种资源System在ysis中选择“Addgraph”或“Newgraph”就可以看到这几个资源了还有其他没有数据的资源,我们没有让它显示如果想查看的资源,可以将左下角的displayonlygraphscontainingdata置为不选.然后选中相应的点“opengraph”即可.打开ysis首先可以看的是SummaryReport.这里显示了测试的分析统一共做了多少的事有大致的熟悉了解.以确定下次增加的任务条件下测试StatisticsSummary(统计)：只是大概了解一下测试数据,对我们具体分析没TransactionSummary(事务)：了解平均响应时间Average单位为秒.分析集合在录制中通常我们会使用到集合点,那么既然我们用到了集合点,我们就需要知道Vuser是在什么时候集合在这个点上,又是怎样的一个被的过程.这Vuser-Rendezvous图.35030start集合点,3多,在7分30的位置开始用户,9分30还有18个用户,11分10还有5个用户12分2是集合点与平均事务响应时间的比较图注:在打开ysis之后系统LR默认这两个曲线是不在同一中的.这就需点击图上.mergegraphs.selectgraphtomergewith2中较深颜色的是平均响应时间,浅色的为集合点,Vuser1接下来看一下与事务有关的参数分析.下看一.这包括AverageTransactionResponseTime和RunningVuser两个数据图.Vuser_init_Transaction(系统登录)对系统无任何的影响,Vuser达15个的时候平均事务响应时间才有明显的升高,14个用户同时处理事务,Vuser301分,系统响应时间最大,1分钟才出现的,时间控制在10S内.Vuser数量最多过2个.看来是很难满足用户的需求了.做一件事有时候会问你这件事办得怎么样了.你会说做完一半了.那么这务的百分比就要靠下面这个图(TransactionResponseTime(Percentile)10%80S左右.80S对于用户来说不是一个很小的数字,10%的事务,汗.你觉得这个系统性能会好么!实际工作中遇到的事情不是每一件事都能够在很短的时间内完成的,对于那些事情消耗的时间长一些,有些事情消耗的短一些,但我们自己清楚.LR同样也为我们提供了这样的功能,使我们可以了解大部分的事务响应时间是多少?以确定显示在方案中执行用时间的分布.如果定义了可以接受的最小和最大事务很明显大多数事务的响应时间在60-140.在我测试过的项目中多数客户所能接受的最大响应时间也要在20S左右140S的时间!等待页面的出现吧!系统性能不好的原因多方面,我们先从应用程序看.有的时候我不得不承认LR的功能真的很强大,这也是我喜欢它的原因.先看一张页面细分图析一下.中显示了整个测试过程中涉及到的所有web页.webpagebreakdown中显示的是每个页面的时间.点选左下角wgebreakdown展开,可以看到每个页中包括的css样式表,js,jsp页面等所有的属性.selectpagetobreakdown中选择页面.在SelectPageToBreakdown中选择后,下方看到属于它的两个组件,第一行中Connection和Buffer占据了整个的名描DNSDNSIP地址所需的时间。“DNS查找”度量是指示DNS解析问DNSURLWeb服务器建立初始连接所需HTTP请求（GET）到成功收回来Web服务器的第一次缓冲时为止所经过的时间。第Web服务器延迟和网络滞后指注意：8K间可能也就是完成元素所需的时间显示建立SSL连接（包括客户 SSLHTTPS显示从服务器收到最后一个字节并完成之前经过的接收速率的时间/大小比率）FTP，则服务器“FTPFTPHTTP请求到返回错误消息（HTTP错误）也有可能你的程序中client的时间最长.或者其他的,这些就要根据你自己的来分析了.CPU,内存.硬盘的瓶颈分析方法:首先我们要监视%processortime(processor_total):器消耗的处理器时间数量.如果服务器于sqlserver可接80%-85%.CPU使用率.%Usertime(processor_total)::表示耗费CPU的数据库操作，如排序，执行aggregatefunctions%DPCtime(processor_total)::越低越好。在多处理器系统中，如果这个值大于50%并且%Disktime(physicaldisk_total):指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows2000令行窗口中运行diskperf-yD。若数值持续超过80%，则可能是内存泄漏。Availiablebytes(memory):可用物理内存数.如果AvailableMbytes的值很小（4MB或更小Contextswitch/sec(system):(实例化inetinfo和dllhost进程)如果你决定要增加线程字节池%Diskreads/sec(physicaldisk_total):每秒读硬盘字节数%Diskwrite/sec(physicaldisk_total):每秒写硬盘字节数Pagefaults/sec:进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生Pagespersecond:orking:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存页就会被留在工作集中当内存少于一个特定的阈值时页就会被清除出工作集。Avg.diskqueuelength:和写入请求(为所选磁盘在实例间隔中列队的)的平均数该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个RaidDisk实际有多个磁盘。Averagediskread/writequeuelength:指(写入)请求(列队)的平均数Diskreads/(writes)/s:理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容Averagedisksec/read:以秒计算的在此盘上数据的所需平均时间Averagedisksec/transfer:理页总数。由于物理I/O的开销大，可以通过使用更大的数据高速缓存、智能索引、Pagewrite/sec:(写的页/如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(contextches/ec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高.从图的整体看.contextswitches/sec变化不大,throughout曲线的斜率较高,并且此时的context如果processorqueuelength显示的队列长度保持不变(>=2)个并且处理器的利用率%Processortime超过90%,那么很可能存在处理器瓶颈.如果发现processorqueuelength显示的队列长度超%processortime平均值大于95,processorqueuelength大于2.可以确定CPU瓶颈.此时的CPU已判断内存问内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏,process\privatebytes计数器和process\workingset计数器的值往往会升高,同时avaiablebytes的值会降低.应该通过一个长时间的,用来研究分析所有内存都耗尽时,应用程序反应情况的测试来检验图中可以看到该程序并不存在内存的问题.内存问题经常出现在服务长时间运转的时候,由于部分程序对内存没有,而将内存慢慢耗尽.也是提醒大家对系统稳定性测试的如果内存接近于0而且库快存或数据字典快存中率小于0.90，那么需要增加快存（共享SQL区）和数据字典快存中率：select(sum(pins-reloads))/sum(pins)fromv$librarycache;select(sum(gets-getmisses))/sum(gets)fromv$rowcache; select*fromv$sgastatwherename=’freeselectname,valuefromv$sysstatwherenamein('dbblock'consistentgets','physicalreads')HitRatio=1-(physicalreads/(dbblockgets+consistent日志缓冲区的申请情况：selectname,valuefromv$sysstatwherename='redologspacerequests'如果内存排序小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。内存排序：selectround((100*b.value)/decode((a.value+b.value),0,1,(a.value+b.value)),2)fromv$sysstata,v$='sorts(disk)'and='sorts(memory)'参考信息ProcessorProcessorTimeProcessor\UserTimePrivilegedTimeServerWorkQueuesQueueLength4则表System\ProcessorQueueLengthProcess\ProcessorTimeProcess\WorkingProcess\ProcessorTime过程的所有线程在每个处理器上的处理器时间总和。PhysicalDisk\%DiskPhysicalDisk\Avg.DiskQueue例如，包括PageReads/sec和%DiskTime及Avg.DiskQueueLength。如果页面操作DiskTimeAvg.DiskQueueLength的值很高，则可能有磁盘瓶径。但请观察Processor\Interrupts/sec计数器的值，该计数器测量来自输入/输出(I/O)设备的服PhysicalDisk\DiskReads/secandDiskWrites/secPhysicalDisk\CurrentDiskQueueLengthPhysicalDisk\%DiskTimeLogicalDisk\%Free可能需要观察的附加计数器包括PhysicalDisk\Avg.Disksec/TransferAvg.DiskBytes/Transfer，和DiskBytes/sec。Avg.Disksec/Transfer计数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于平均传送时间是大于0.3秒。也可以查看Avg.DiskBytes/Transfer的值。值大于20KB表示该磁盘驱动器通常运行良加平均Disksec/Transfer时间，因为随机传送需要增加搜索时间。DiskBytes/sec提供磁盘系统的吞吐率。PhysicalDisk\DiskTimeDiskTime较高（超过90%，请检查PhysicalDisk\CurrentDiskQueueLength计数器以查看正在等待磁盘的I/O1.52(RAID)RAID设备在“系统监视器”中显示为一个物理磁盘；通过创建的RAID设备显示为多个驱动器（实例。可以监视每个物理驱动器（RAID）PhysicalDisk计数器，也可以使用_Total实例来监视所有计算机驱动器的数据。CurrentDiskQueueLength%DiskTimeCurrentDiskQueueLengthDiskTime流,共同提高.由于本人也是初学者,有说明的不对的地方还希望指点.家分析有所帮助。分析原则：具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低（312根据收集到的指标数1Error:Failedtoconnecttoserver“0:8080″:[10060]Error:timedoutError:Server“0″hasshutdowntheconnectionA（小用户时：程序上的问题。程序上处理数据库的问题B（应用服务参数设置问题例：在许多客户端连接Weblogic应用服务器被，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklogconnectionrefusedC、数据库的连(1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数（跟硬件的内存有关2Error:Pagedownloadtimeout(120seconds)hasB、页面中太多C、在程序处理表的时候检查字段太大二二 指标数据分户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。Windows资源中，如果Process/PrivateBytes计数器和Process/WorkingSet计数器的值长时间内持续升高，同时Memory/Availablebytes计数器的值持续降低，则很可能存在内存泄漏。很高的换页率(highpageout进程进入不活动状态可高的全局系统CPU利用率;内存不够出错(outofmemory过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器于SQLCPU资源成为系统性能的瓶颈的征兆很慢的响应时间(slowresponseCPU空闲时间为零(zeropercentidle过高的用户占用CPU时间(highpercentuser过高的系统占用CPU时间(highpercentsystem长时间的有很长的运行进程队列(largerunqueuesizesustainedoverI/O有问题。可考虑更换更快的硬盘系统。Windows资源中，如果DiskTime和Avg.DiskQueueLength的值很高，而Page页面操作速率很低，则可能存在磁盘瓶径I/O过高的磁盘利用率(highdisk太长的磁盘等待队列(largediskqueueI/O的时间所占的百分率太高(largepercentageoftimewaitingfordisk太高的物理I/O速率:largephysicalI/Orate(notsufficientinitself)过低的缓存(lowbuffercachehitratio(notsufficientinitself))太长的运行进程队列，但CPU却空闲(largerunqueuewithidleCPU)SQLServer数据库：如果FullScans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。NumberofDeadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣LockRequests/sec(锁请求/秒)，通过优化查询来减少次数，可以减少该计数器的值Oracle数据库SHARED_POOL_SIZE的大小快存（共享SQL区）和数据字典快存中率：select(sum(pins-reloads))/sum(pins)fromv$librarycache;select(sum(gets-getmisses))/sum(gets)fromselect*fromv$sgastatwherename=’freeselectname,valuefromv$sysstatwherenamein(’dbblock‘consistentgets’,'physicalreads’)HitRatio=1-(physicalreads/(dbblockgets+consistent日志缓冲区的申请情况：selectname,valuefromv$sysstatwherename=‘redologspacerequests’如果内存排序小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。内存排序：selectround((100*b.value)/decode((a.value+b.value),0,1,(a.value+b.value)),2)fromv$sysstata,v$sysstatbwhere=’sorts(disk)’and=’sorts(memory)’注：上述SQLServer和OracleOracle数据库的分析测试过程中感觉比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特作了以下笔记，这里只是书中第4章WEB应用程序性能分析的一部分，贴出来希望和大家共同当增大系统的压力（或增加并发用户数）S的变化曲线呈大体一致，则系统网络出现带宽瓶颈，同理若点击率/PS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。二：以WEB应用程序为例来看下具体的分析方法事务综述图(TransactionSummary事务平均响应时间分析图（AverageTransactionResponseTime）秒中，每个事务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务事务响应时间与负载分析图（TransactionResponseTimeUnderload）:事务响应时间（百分比）图（TransactionResponseTime(percentile)）:LR性能样例分 分数据库服务器资源等几个方面分析，如图1-1所示。性能分析的一个重要的原则是以性能测试的需求指标。我们回顾一下本次性能测试的目的，正如所列的指标，本在业务操作过程中页面的响应时间不超过3CPU使用率、内存使用率分图1-1性能分析流程结果LoadRunner进行场景收集后，首先显示的该结果的一个信息，如图1-的信息列出本次。图1-2性能场景执行情图13StatisticsSummary（统计信息求数的统计值，如图5-4所示。从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均图1-4统计信息Action的平均响应时间、通过率等情况，如图15所示。Action的平均响应时间与业务成功率。因为在场景的“Run-timeSettings”的“Miscellaneous”Action当成了一个事务执行，故这里的事务其实就是中的Action。图1-5事务HTTPResponsesSummary（HTTP响应该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5-6所示。从图中可以看到，在本次测试过程中LoadRunner共模拟发出了而“HTTP404”则有2163，说明在本次过程中，经过发出的请求大部分都能正确响应了，但还是有部分失败了，但未影响，“HTTP200”表示请求被正确响应，而“HTTP404” 过了。出现这样问题的原因是有些页面的请求内容并非关键点，比如可能请求先前的信息，如果没有就重新获取，所以不会影响最终的。图16HTTP响应HTTP400401.1：由于凭据无效被401.2:由于服务器配置倾向使用替代验证方法而被401.3：由于ACL对所请求资源的设置被401.4：Web服务器上安装的筛选器失败401.5：ISAPI/CGI应用程序失败401.7：由于Web服务器上的URL策略而403：被403.1：执行被403.2：被403.3：写入被403.4：需要使用SSL查看该资源403.5：需要使用SSL128查看该资源403.6：客户端的IP地址被403.7：需要SSL客户端403.8：客户端的DNS名称被403.9：太多客户端试图连接到Web服务器403.10：Web服务器配置为执行403.11：已更改403.12：服务器器了客户端403.13：客户端已在Web服务器上吊销403.14：在Web服务器上已列表403.15：Web服务器已超过客户端证限制403.16：客户端格式错误或未被Web服务器信任403.17：客户端已经到期或者尚未生效403.18：无法在当前应用程序池中执行请求的URL403.19：无法在该应用程序池中为客户端执行CGI403.20：Passport登录失败找不到文件 文件 未找到：无法在所请求的端口IPIIS返回HTTPIPIP地址配置为在端口80IP地址从端口80IIS返回404.1错误。IP地址时才会将它返回给客文件 无法找到：锁定策略该请求文件 无法找到：MIME策略该请求用于该页的HTTP动作未被MIME类型Web服务器需要初始的验证410412Web414URLWebURL500服务器错误服务器错误：Web服务器错误：Web服务器错误：WebGLOBAL.ASA服务器错误：UNC凭据不正确服务器错误：URL无法找到服务器错误：URL无法打开服务器错误：URL域无法找到500100服务器错误：ASP错误501502Web服务器作为网关或服务器时收到无效的响应“RunningVusers（运行的并发数）”显示了在场景执行过程中并发数的执行情况。它们显示Vuser的状态、完成的Vuser的数量以及集合统计信息，将这些图与事务图结Vuser的数量对事务响应时间产生的影响。图17OA系统考勤业Vusers运行情况，从图中我们可以看到，Vusers的运行趋势与我们场景if(atoi(lr_eval_string("{num}"))>lr_output_message("登录成功，继续执行}}

return-1;Vuser分配不到正确的登录账号，就可能导致图17击左边的“NewGraph”，出现图58，展开“Vusers”前的加号，双击“Rendezvous”，出现图18Running的Vusers有10个，集合点策略设置是“所有运行用户到达后”，而集合点图形显示的最大Vusers是7个那么就表示有些Vuser超时了引起超时的原因可能是Vuser图19RunningVusers与集合点是一致，说明整个场景执行过程中，并发数用户的执行正确，OA系统测试服务器能够应付7个并发用户的业务操作。3秒，那么本次测试是否达到了这个要求呢？我们先来看“AverageTransactionResponseTime（平均事务响应时间图）”（图1-10，这是平均事务响应时间与结果中的“TransactionSummary”合成的。图110登录业务的时候，我们没有去除思考时间，所以，登录功能的实际事务时间应该是4.425户环境，统计结果中除去思考时间是为了更真实的反映服务器的处理能力，两者并不。看完了“AverageTime”，我们再看“90PercentTime”，这个时间从某种程度来说，更准确Time”与“90PercentTime”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“AverageTime”而使用“90PercentTime”可能更真实些。<=32.298Y<=31.469Y30分钟完成30分钟完成CPUTime”与“90PercentTime”“90<=32.298Y<=31.469Y30分钟完成30分钟完成CPU表1对照表受客户端的请求，并能够返回结果。如果“HitsperSecond”正常，而“AverageThroughput-对于本次测试来说，“HitsperSecond”与“AverageThroughput(bytes/second)”都是正常等等。举个例子，我们楼下的建行，假如每天的业务类别是这样的：20个，5个销户，个Aciton当做一笔业务，在LoadRunner场景执行中一笔交易称为一个以，说业务成功率其实就是事务成功率、通过率的意思。在“TransactionSummary”中我们可以很明确的看到每个事务的执行状态，如图1-12所示。图112实际值是否通过登录业务响应时间<=3秒Y考勤业务响应时间<=3秒YY实际值是否通过登录业务响应时间<=3秒Y考勤业务响应时间<=3秒YYY30Y30YCPU表2对照表系统资源图显示了在场景执行过程中被的机器系统资源使用情况一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度，具体的数据如图1-13所示。图1-13测试服务器系统资源结果从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用率70%Windwos资源性能指标的解释，一般情况下，如果“ProcessorQueueLength（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器的CPU也获得上述数据后，的记录表如表3所示是否通过登录业务响应时间<=3秒Y考勤业务响应时间<=3秒YYY30Y30YCPU%Y%N表3对照表源。左边的“NewGraph”，出现图1-14，展开“WgeDiagnostics”前的加号，双击“PageDownloadTimeBreakdown”，待出现“PageDownloadTimeBreakdown”图图114在图列表中，我们看到图1-15，从图中我们看到，在所有的页面中，登录后的用个人面页面“”的时间最长。图1-15网页时间细分图1-16详细列出了每个页面所消耗的时间分布，图中每一个指标含义见表4所示。该表由图1-16oa.jsp页面时间分布ClientConnectionURLWeb DNSDNSIPDNSDNSDNSErrorBufferTime显示从初始HTTP请求（通常为GET）到成功收回来自Web服务器的Web服务（注意：由于缓冲区大小最大为8K，因此第一次缓冲时间可能也就是成元素所需的时间端命令之前，必须验证该客户端。FTP验证度量仅适用于FTP信Receive显示从服务器收到最后一个字节并完成之前经过的时间。接收度是很好的