LR测试报告分析2015

LoadRunner分析一、用户事务分析用户事务分析是站在用户角度进行的基础性能分析。1、TransationSunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。2、AverageTransacitonResponseTime（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。根据该图，可以定位出现性能问题的转折点。说明：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降，可能情况：1）曲线图持续上升，表明系统的处理能力在下降，事务的响应时间变长；2）持续平衡，表明并发用户数达到一定数量，再多请求也可能接受不了，等待；3）当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。如果系统没有出现下降，但响应时间越来越长，直到系统瘫痪，引起原因可能如下：1）程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；2）内存泄露。3、TransactionsperSecond（每秒通过事务数，简写TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。说明：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。TPS值，越大说明系统处理能力越强。4、TotalTransactionsperSecond（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。该曲线走向和TPS曲线走向一致。5、TransactionPerformanceSunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。说明：重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。6、TransactionResponseTimeUnderLoad（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。7、TransactionResponseTime(Percentile)（事务响应时间(百分比)）“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。说明：主要观察，在给定时间的范围内完成事务的百分比参考值：10%的TRT（P）=5s、50%的TRT（P）=5s、90%的TRT（P）=5s8、TransactionResponseTime(Distribution)（事务响应时间(分布)）“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。说明：主要观察，大多数事务的响应时间参考值：TRT（D）=5s二、确定CPU、内存泄露问题1、%processortime(processor_total)服务器消耗的处理器时间数量.如果服务器专用于sqlserver可接受的最大上限是80%-85%.也就是常见的CPU使用率。说明：正常负载下，服务器的CPU利用率应该在80%以下。超过90%,那么很可能存在处理器瓶颈。如果CPU使用率不断上升，内存使用率也不断上升，表明系统可能产生资源争用情况，引起原因，程序资源调配问题。判断是否内存泄露问题：内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏，ProcessBytes\PrivateBytes计数器和Process\Workingset计数器的值往往会升高，同时Avaiablebytes的值会降低。内存泄漏应该通过一个长时间的，用来研究分析所有内存都耗尽时，应用程序反应情况的测试来检验。内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放，而将内存慢慢耗尽，也是提醒大家对系统稳定性测试的关注。2、%Disktime(physicaldisk_total)指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%DiskTime比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows2000的命令行窗口中运行diskperf-yD。说明：正常值10。若数值持续超过80%，则可能是内存泄漏。3、Availiablebytes(memory)用物理内存数.如果AvailableMbytes的值很小(4MB或更小)，则说明计算机上总的内存可能不足，或某程序没有释放内存。参考值：4MB或更小，至少要有10%的物理内存值。4、Pagewrite/sec(写的页/秒)每秒执行的物理数据库写的页数。说明：如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题(太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法)。【其他参数】%Usertime(processor_total)表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。%DPCtime(processor_total)越低越好。在多处理器系统中，如果这个值大于50%并且Processor:%ProcessorTime非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。Contextswitch/sec(system)(实例化inetinfo和dllhost进程)如果你决定要增加线程字节池的大小，你应该监视这三个计数器(包括上面的一个)。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。说明：可判断应用程序的问题。如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换(Contextswitches/sec显示的上下文切换次数太高)那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高。%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的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。.三、确定网络问题：1、HitsperSecond（每秒点击次数）“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。说明：通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput（吞吐率）“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。“吞吐率”图，是每秒服务器处理的HTTP申请数。“点击率”图，是客户端每秒从服务器获得的总数据量。说明：观察3张图（RunningVusers（负载数）/HisperSecond（点击率）/Throughput(吞吐量)），随着负载的加大，点击率和吞吐量会随之增大。如果系统的吞吐量随着负载的加大出现平坦或降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高，表明网络饱和。3、NetworkDelayTime说明：网络延迟时间的曲线突起显示有网络故障。4、NetworkSub-PathTime说明：网络Sub-Path的时间曲线跳跃式的突起证明存在网络故障。四、确定性能问题是在网络端还是服务端：1、WebPageBreakdown（页面分解总图）“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。可以按下面四种方式进行进一步细分：DownloadTimeBreaddown（下载时间细分）“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。ComponentBreakdown(OverTime)（组件细分(随时间变化)）“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。DownloadTimeBreakdown(OverTime)（下载时间细分(随时间变化)）“下载时间细分(随时间变化)”图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分(随时间变化)”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。TimetoFirstBufferBreakdown(OverTime)（第一次缓冲时间细分(随时间变化)）“第一次缓