学会看懂LoadRunner分析报表

图表分析：

一、 Web Page Breakdown

DNS 解析时间： 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间； DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器；

Connect 时间： 显示与包含指定 URL 的 Web 服务器建立初始连接所需的时间； Connect 度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；

First buffer 时间： 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间； First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器；

SSL Handshaking time ： 显示建立 SSL 连接所用的时间

Receive Time ： 显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；

FTP 验证时间： 显示验证客户端所用的时间。

Client Time ： 显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。

Error 时间： 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间

二、 关于 TPS （ Transactions per Second ）： 每秒处理事务数

这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数 / 时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。

为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在 Transaactions per Second 这张图中， LoadRunner 是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。 另外，我还在 Analysis 里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键 -> 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位，结果 LoadRunner 提示当前不支持以毫秒为显示粒度，由此我推断 LoadRunner 对于 Transactions per Second 这张图，最小的取样粒度为 1 秒。

三、 Transaction Response Time事务响应时间（百分比）图

这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数）， LoadRunner 会为每个事务实例的处理分别记录响应时间。

在 Summary Report 中， LoadRunner 会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。

事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以 95% 为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。

注意： Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。

四、 Transaction Response Time事务响应时间（负载下）图

这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5 分钟加载 10 个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。

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:理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。

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. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；

2. 内存泄露；

二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；

表明系统中可能产生资源争用情况；

引起原因：

开发人员注意资源调配问题。

三、 所有的事务响应时间、cpu等都很正常，业务出现失败情况；

引起原因：

数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；

当数据量大时，就会出现数据错乱情况。

分析原则：

1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

2. 查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈 网络瓶颈（对局域网，可以不考虑） 服务器操作系统瓶颈（参数配置） 中间件瓶颈（参数配置，数据库，web服务器等） 应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

分析的信息来源：

1. 根据场景运行过程中的错误提示信息

2. 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

1．Error: Failed to connect to server “172.17.7.230″: [10060] Connection Error: timed out Error: Server “172.17.7.230″ has shut down the

connection prematurely

分析：

A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）

B、应用服务没有死

（应用服务参数设置问题）

对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！

C、数据库的连接

(数据库启动的最大连接数（跟硬件的内存有关）)

D、我们的应用程序spring控制的最大链接数太低

2. Error: Page download timeout (120 seconds) has expired 分析：

A、应用服务参数设置太大导致服务器的瓶颈

B、页面中图片太多

C、在程序处理表的时候检查字段太大多

D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境

3. Error “http://172.17.7.230/Home.do....”

分析：

A、脚本设计错误，造成页面异常。服务器有响应！

B、并发数过大，造成服务器响应延迟。

4. Error page “text=xxxxx”

分析：

A、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。

B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反复修改脚本！

二．监控指标数据分析

1．Vusers数

Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。

每个Vuser产生响应的操作，所有的操作对服务器形成并发。

颜色 比例 度量 图最小值 图平均值 图最大值 图中间值 图SD

1 Run 0.0 21.25 44 41 21.276

在实际测试中，Vusers可以根据实际情况的需要，在测试过程中增加或者减少。

2．最大并发用户数：

颜色 比例 度量 最小值 平均值 最大值 SD

100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043 0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924

0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201 应用系统在当前环境下能承受的最大并发用户数。

在方案运行中，如果出现了大批用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

第二篇：LoadRunner分析报表

一、Web Page Breakdown

DNS解析时间：显示使用最近的DNS服务器将DNS名称解析为IP地址所需的时间；DNS查找度量是指示DNS解析问题或DNS服务器问题的一个很好的指示器；

Connect时间：显示与包含指定URL的Web服务器建立初始连接所需的时间；Connect度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；

First buffer时间：显示从初始HTTP请求到成功收回来自WEB服务器的第一次缓冲时为止所经过的时间；First buffer度量是很好的Web服务器延迟和网络滞后指示器；

SSL Handshaking time：显示建立SSL连接所用的时间

Receive Time：显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；

FTP验证时间：显示验证客户端所用的时间。

Client Time：显示因浏览器思考时间或与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。

Error时间：显示从发出HTTP请求到返回错误消息这期间所经过的平均时间

二、关于TPS（Transactions per Second）：每秒处理事务数

这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问，到底这个值是怎么算出来的。既然是每秒事务数，那算法自然是“事务数/时间”。事务数很好理解，执行了多少就是多少，关键是这个时间。是整个场景执行的时间，还是仅仅是在服务器端执行的时间？因为我们知道，这两个时间肯定是有区别的，前者还包括thinktime的时间、pacing的时间以及在网络上耗费的时间等等。

为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。”如果按照这句话

去理解，那么上面那个问题的答案应该是后者，也就是说，在Transaactions per Second这张图中，是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。

另外，我还在Analysis里面找了一下，发现图表的时间显示粒度也是可以设置的。具体方法为：在图表上点击右键->选择“Set Granularity”或者直接按Ctrl+G。我试着把时间粒度调成以毫秒为单位，结果LoadRunner提示当前不支持以毫秒为显示粒度，由此我推断LoadRunner对于Transactions per Second这张图，最小的取样粒度为1秒。

三、事务响应时间（百分比）图

这个图显示的是事务响应时间范围的分布情况。在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数），LoadRunner会为每个事务实例的处理分别记录响应时间。在Summary Report中，LoadRunner会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。

事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长，但是绝大多数事务（通常情况下以95%为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。

注意：Analysis将对每个可用事务百分比的事务响应时间取近似值。因此Y轴的值可能并不准确。

四、事务响应时间（负载下）图

这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看Vuser负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每5分钟加载10个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。