LR性能测试结果.docx

LR性能测试结果.docx

《LR性能测试结果.docx》由会员分享，可在线阅读，更多相关《LR性能测试结果.docx（30页珍藏版）》请在冰点文库上搜索。

LR性能测试结果

LR分析

一、用户事务分析 

用户事务分析是站在用户角度进行的基础性能分析。

1、Transation Sunmmary（事务综述） 

对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。

2、Average Transaciton Response Time（事务平均响应时间） 

“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。

根据该图，可以定位出现性能问题的转折点。

说明：

随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。

当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降，可能情况：

1）曲线图持续上升，表明系统的处理能力在下降，事务的响应时间变长；                              

2）持续平衡，表明并发用户数达到一定数量，再多请求也可能接受不了，等待；                       

3）当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。

如果系统没有出现下降，但响应时间越来越长，直到系统瘫痪，引起原因可能如下:

1）程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；                 

2）内存泄露。

3、Transactions per Second（每秒通过事务数，简写TPS） 

“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。

通过它可以确定系统在任何给定时刻的时间事务负载。

分析TPS主要是看曲线的性能走向。

将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。

说明：

当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

TPS值，越大说明系统处理能力越强。

4、Total Transactions per Second（每秒通过事务总数） 

“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

该曲线走向和TPS曲线走向一致。

5、Transaction Performance Sunmmary（事务性能摘要） 

“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。

说明：

重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。

6、Transaction Response Time Under Load（事务响应时间与负载） 

“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。

此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。

7、Transaction Response Time（Percentile）（事务响应时间（百分比）） 

“事务响应时间（百分比）”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。

通过它可以分析在给定事务响应时间范围内能执行的事务百分比。

说明：

主要观察，在给定时间的范围内完成事务的百分比                                      

参考值：

 10%的TRT（P）<=5s、50%的TRT（P）<=5s、90%的TRT（P）<=5s  

8、Transaction Response Time（Distribution）（事务响应时间（分布）） 

“事务响应时间（分布）”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。

如果系统预先定义了相关事务可以接受的最小和最

大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

说明：

主要观察，大多数事务的响应时间                                               

 参考值：

TRT（D）<=5s 

二、确定CPU、内存泄露问题 

1、%processor time（processor_total） 

服务器消耗的处理器时间数量.如果服务器专用于sql server 可接受的最大上限是80% -85 %.也就是常见的CPU 使用率。

说明：

正常负载下，服务器的CPU利用率应该在80%以下。

超过90%,那么很可能存在处理器瓶颈。

如果CPU使用率不断上升，内存使用率也不断上升，表明系统可能产生资源争用情况，引起原因，程序资源调配问题。

判断是否内存泄露问题：

内存问题主要检查应用程序是否存在内存泄漏,如果发生了内存泄漏，P rocess Bytes\Private Bytes计数器和Process\Working set 计数器的值往往会升高，同时Avaiable bytes的值会降低。

内存泄漏应该通过一个长时间的，用来研究分析所有内存都耗尽时，应用程序反应情况的测试来检验。

内存泄露问题经常出现在服务长时间运转的时候,由于部分程序对内存没有释放，而将内存慢慢耗尽，也是提醒大家对系统稳定性测试的关注。

2、%Disk time（physicaldisk_total） 

指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。

如果三个计数器都比较大，那么硬盘不是瓶颈。

如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。

在记录该计数器之前，请在Windows 2000 的命令行窗口中运行diskperf -yD。

说明：

正常值<10。

若数值持续超过80%，则可能是内存泄漏。

3、Availiable bytes（memory） 

用物理内存数. 如果Available Mbytes的值很小（4 MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

参考值：

4 MB或更小，至少要有10%的物理内存值。

4、Page write/sec 

（写的页/秒）每秒执行的物理数据库写的页数。

说明：

如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。

如果大于80，表示有问题（太多的读写数据操作要访问磁盘，可考虑增加内存或优化读写数据的算法）。

【其他参数】 

%User time（processor_total） 

表示耗费CPU的数据库操作，如排序，执行aggregate functions等。

如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

%DPC time（processor_total） 

越低越好。

在多处理器系统中，如果这个值大于50%并且Processor:

% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

Context switch/sec（system） 

 （实例化inetinfo 和dllhost 进程） 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。

增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。

如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

说明：

可判断应用程序的问题。

如果系统由于应用程序代码效率低下或者系统结构设计有缺陷而导致大量的上下文切换（Context switches/sec显示的上下文切换次数太高）那么就会占用大量的系统资源,如果系统的吞吐量降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高。

%Disk reads/sec（physicaldisk_total） 

每秒读硬盘字节数. 

%Disk write/sec（physicaldisk_total） 

每秒写硬盘字节数. 

Page faults/sec 

进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。

Pages per second 

每秒钟检索的页数 

该数字应少于每秒一页Working set:

理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。

如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

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 的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。

三、确定网络问题：

1、Hits per Second（每秒点击次数） 

“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

 通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。

说明：

通过对查看“每秒点击次数”，可以判断系统是否稳定。

系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

2、Throughput（吞吐率） 

“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。

其度量单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。

可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

 “吞吐率”图，是每秒服务器处理的HTTP申请数。

 “点击率”图，是客户端每秒从服务器获得的总数据量。

说明：

观察3张图（Running Vusers（负载数）/His per Second（点击率）/Throughput（吞吐量）），随着负载的加大，点击率和吞吐量会随之增大。

如果系统的吞吐量随着负载的加大出现平坦或降低并且CPU的使用率很高,并且此现象发生时切换水平在15000以上,那么意味着上下文切换次数过高，表明网络饱和。

3、Network Delay Time 

说明：

网络延迟时间的曲线突起显示有网络故障。

4、Network Sub-Path Time 

说明：

网络Sub-Path的时间曲线跳跃式的突起证明存在网络故障。

四、确定性能问题是在网络端还是服务端：

1、Web Page Breakdown（页面分解总图） 

“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。

可以按下面四种方式进行进一步细分：

Download Time Breaddown（下载时间细分） 

   “下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。

    Component Breakdown（Over Time）（组件细分（随时间变化）） 

  “组件细分”图显示选定网页的页面组件随时间变化的细分图。

通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。

该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。

 Download Time Breakdown（Over Time）（下载时间细分（随时间变化）） 

   “下载时间细分（随时间变化）” 图显示选定网页的页面元素下载时间细分（随时间变化）情况，它非常清晰地显示了页面各个元素在压力测试过程中的下载情况。

“下载时间细分”图显示的是整个测试过程页面元素响应的时间统计分析结果，“下载时间细分（随时间变化）”显示的事场景运行过程中每一秒内页面元素响应时间的统计结果，两者分别从宏观和微观角度来分析页面元素的下载时间。

    Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））    

“第一次缓冲时间细分（随时间变化）”图显示成功收到从Web服务器返回的第一次缓冲之前的这段时间，场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间（以秒为单位）。

可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

    First Buffer Time：

是指客户端与服务器端建立连接后，从服务器发送第一个数据包开始计时，数据经过网络传送到客户端，到浏览器接收到第一个缓冲所用的时间。

2、Page Component Breakdown（页面组件细分） 

“页面组件细分”图显示每个网页及其组件的平均下载时间（以秒为单位）。

可以根据下载组件所用的平均秒数对图列进行排序，通过它有助于隔离有问题的组件。

3、Page Component Breakdown（Over Time）（页面组件分解（随时间变化）） 

“页面组件分解（随时间变化）”图显示在方案运行期间的每一秒内每个网页及其组件的平均响应时间 （以秒为单位）。

4、Page Download Time Breakdown（页面下载时间细分） 

“页面下载时间细分”图显示每个页面组件下载时间的细分，可以根据它确定在网页下载期间事务响应时间缓慢是由网络错误引起还是由服务器错误引起。

“页面下载时间细分”图根据DNS解析时间、连接时间、第一次缓冲时间、SSL握手时间、接收时间、FTP验证时间、客户端时间和错误时间来对每个组件的下载过程进行细分。

5、Page Download Time Breakdown（Over Time）（页面下载时间细分（随时间变化）） 

“页面下载时间细分（随时间变化）”图显示方案运行期间，每一秒内每个页面组件下载时间的细分。

使用此图可以确定网络或服务器在方案执行期间哪一时间点发生了问题。

 “页面组件细分（随时间变化）”图和“页面下载时间细分（随时间变化）”图通常结合起来进行分析：

首先确定有问题的组件，然后分析它们的下载过程，进而定位原因在哪里。

6、Time to First Buffer Breakdown（第一次缓冲时间细分） 

“第一次缓冲时间细分”图显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个页面组件的相关服务器/网路时间。

如果组件的下载时间很长，则可以使用此图确定产生的问题与服务器有关还是与网络有关。

网络时间：

定义为第一个HTTP请求那一刻开始，直到确认为止所经过的平均时间。

 服务器时间：

定义为从收到初始HTTP请求确认开始，直到成功收到来自Web服务器的一次缓冲为止所经过的平均时间。

说明：

找出下载耗费时间最多的网页。

有助排出DNS的故障，SSL的故障，网络连接的故障。

【其他Web资源分析】 

1、HTTP Status Code Summary（HTTP状态代码概要） 

“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。

HTTP状态代码表示HTTP请求的状态。

2、HTTP Responses per Second（每秒HTTP响应数） 

“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

3、Pages Downloader per Second（每秒下载页面数） 

“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。

使用此图可依据下载的页数来计算Vuser生成的负载量。

和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。

但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。

而每秒下载页面数只考虑页面数。

注：

要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数（仅HTML模式）”。

4、Retries per Second（每秒重试次数） 

“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。

 在下列情况将重试服务器连接：

 A、初始连接XX B、要求代理服务器身份验证 C、服务器关闭了初始连接 D、初始连接无法连接到服务器 

E、服务器最初无法解析负载生成器的IP地址 

5、Retries Summary（重试次数概要） 

“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。

将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。

6、Connections（连接数） 

“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。

 借助此图，可以知道何时需要添加其他连接。

说明：

当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。

7、Connections Per Second（每秒连接数） 

“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。

理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。

通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。

8、SSLs Per Second（每秒SSL连接数） 

“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。

当对安全服务器打开TCP/IP连接后，浏览器将打开SSL连接。

9、Web Page Breakdown（网页元素细分） 

“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的 元素。

10、Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化）） 

“第一次缓冲时间细分（随时间变化）”图显示成功收到从Web服务器返回的第一个缓冲之前的这段时间内，场景运行的每一秒中每个网页组件的服务器时间和网络时间。

可以使用此图确定场景运行期间服务器或网络出现问题的时间点。

11、Downloader Component Size（KB）（已下载组件大小） 

“已下载组件大小”图显示每个已经下载的网页组建的大小。

通过它可以直接看出哪些组件比较大并需要进一步进行优化以提高性能。

▪测试结果分析

　　　　LoadRunner性能测试结果分析是个复杂的过程，通常可以从结果摘要、并发数、平均事务响应时间、每秒点击数、业务成功率、系统资源、网页细分图、Web服务器资源、数据库服务器资源等几个方面分析，如图1-1所示。

性能测试结果分析的一个重要的原则是以性能测试的需求指标为导向。

我们回顾一下本次性能测试的目的，正如 所列的指标，本次测试的要求是验证在30分钟内完成2000次用户登录系统，然后进行考勤业务，最后退出，在业务操作过程中页面的响应时间不超过3秒，并且服务器的CPU使用率、内存使用率分别不超过75%、70%，那么按照所示的流程，我们开始分析，看看本次测试是否达到了预期的性能指标，其中又有哪些性能隐患，该如何解决。

图1-1性能测试结果分析流程图

▪结果摘要

　　　LoadRunner进行场景测试结果收集后，首先显示的该结果的一个摘要信息，如图1-2所示。

概要中列出了场景执行情况、“StatisticsSummary（统计信息摘要）”、“TransactionSummary（事务摘要）”以及“HTTPResponsesSummary（HTTP响应摘要）”等。

以简要的信息列出本次测试结果。

图1-2性能测试结果摘要图

场景执行情况

该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图5-3所示。

从该图我们知道，本次测试从15:

58:

40开始，到16:

29:

42结束，共历时31分2秒。

与我们场景执行计划中设计的时间基本吻合。

 图1-3场景执行情况描述图

StatisticsSummary（统计信息摘要）

该部分给出了场景执行结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图5-4所示。

从该图我们得知，本次测试运行的最大并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。

图1-4统计信息摘要图

TransactionSummary（事务摘要）

该部分给出了场景执行结束后相关Action的平均响应时间、通过率等情况，如图1-5所示。

从该图我们得到每个Action的平均响应时间与业务成功率。

注意：

　　因为在场景的“Run-timeSettings”的“Miscellaneous”选项中将每一个Action当成了一个事务执行，故这里的事务其实就是脚本中的Action。

 图1-5事务摘要图

HTTPResponsesSummary（HTTP响应摘要）

该部分显示在场景执行过程中，每次HTTP请求发出去的状态，是成功还是失败，都在这里体现，如图5-6所示。

从图中可以看到，在本次测试过程中LoadRunner共模拟发出了211974次请求（与“统计信息摘要”中的“TotalHits”一致），其中“HTTP200”的是209811次，而“HTTP4