LoadRunner性能测试入门教程2

当虚拟用户脚本开发完成后，使用Controller将这个执行脚本的用户从单用户转化为多用户，从而模拟大量用户操作，进而形成负载。（多用户单循环，多用户多循环）我们需要对负载模拟的方式和特征进行配置从而形成场景。

场景（Scenario）是一种用来模拟大量用户操作的技术手段，通过配置和执行场景向服务器产生负载，验证系统

各项性能标是否达到用户要求，而Controller可以帮助我们对场景的设计、执行及监控进行管理

使用Controller管理场景主要分为:场景设计、场景监控。最后通过场景完成性能测试的执行。

手工场景(Manual Scenario)

定义：自行设置虚拟用户的变化，通过设计用户的添加和减少的过程，来模拟真实用户请求

模型，完成负载的生成手工场景 “定量型”性能测试，掌握负载的变化过程中系统各个组件的变化情况，

定位性能瓶颈，了解系统的处理能力，一般在负载测试和压力测试中应用。手工场景的核心就是设置“用户负载 方式”。

手工场景-计划方式

scenario:多个脚本之间按照设定的场景计划来统一运行。

group:多个脚本之间按照独立设置模式跑，各个脚本可以单独设置虚拟用户、运行时间等。

创建目标场景(Goal-Oriented Scenario)

定义：

设置一个运行目标，通过Controller的自动加载功能进行自动化负载，如果测试的结果达到目标，

说明系统的性能符合测试目标，否则就提示无法达到目标。

目标场景-5种目标类型

目标场景配置

负载生成器(LoadGenerators)

对场景进行设计后，需要对负载生成器进行管理和配置。LoadGenerators是运行脚本的负载引擎，(相当于加压力机)主要功能是生成虚拟用户进行负载，在默认情况下使用本地的负载生成器来运行脚本。

但是每生成一个虚拟用户，需要花费负载生成器大约2M-3M的内布空间。通常运行controller的主机很少用作负载生成器。负载生成器的工作由其他装有LRAgent的PC机来担任。如果负载生成器内存的使用率大于了70%,,负载生成器就会变成系统的瓶颈，导致性能测试成绩下降。这种问题需要添加负载生成器来解决。所以在一台电脑上无法模拟大量的虚拟用户，这个时候需要调用多个LoadGenerators 来完成大规模的性能负载。

集合点

1、集合点的含义

当通过controller虚拟多个用户执行该脚本时。用户的启动或运行步骤不一定都是同眇的。集合点是在脚本的某处设置一个标记。当有虚拟用户运行到这个标记时，停下等待

。直到所有的用户都达到这个标记处时，再一财进行下面的步骤，这样能够用最磊的用户并发去做下面操作，就像集合再前进一样。集合点之名由此而得。集合点主要用于对关键步骤的加压。

2、插入集合点的目的

集合点有用处对于LoadRunner来说意义非常大，它可以设置多个虚拟用户等待到一个点，同时触发一个事务，以达到模拟真实环境下同时多个用户操作，同是模拟负载，实现性能测试的最终目的。由些可见，插入集合点主要是为了衡量加重负载的情况下服务的性能情况，从而找到性能瓶颈。可以把集合点理解成果种下特殊情况下的并发。

性能分析

一、图表分析

1、Average Transaciton Time(事务平均响应时间)“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。例如随着时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着时间的变化，整体性能将会有下降的趋势。

2、运行Vuser---平均事务响应时间合并关联图

通过该合并图可以分析出随着用户数量的变化，各个事务平均响应时间的变化，从而可以得出各个事务在指定时间内的最大的并发用户。

3、每秒点击次数(Hit perSecond)是Vusers每秒向Web服务器提交的HTTP请求数，查看其曲线情况可以判断

补测试系统是否稳定，曲线呈下降趋势表明Web服务器的响应时间在变慢，其原因可能是服务器瓶颈问题，也有可能是Vusers数量减少，访问服务器的HTTP请求减少。

4、吞吐量（Throughput）表示服务器在任意时间的吞吐能力，即任意时间服务器发送给Vusers的流量。其度量服务器性能重要指标，度量单位是字节，另外也有兆字节。

5、运行Vuser--吞吐量合并关联图

并发用户数和吞吐量瓶颈之间存一定的关联，（在网络和服务器正常情况下，随着并发用户数增加，网络吞吐量也会增加。）因此可以通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后从网络、数据库、应用服务器和代码本身4个环节确定系统的性能瓶颈。

6、Hits per Second--Throughput合并关联图

在比较吞吐量每秒点击率中我们可以获得服务器在执行过程中的情况。如果服务器如预期的一样在执行，那么吞吐量会随着它每秒的点击量的增加而增加。这是期望实现的情况，因为点击增加一次就会需要服务器发送更多的返回信息给用户。如果点击的次数增加而吞吐量恒定或减少以及在固定范围内波动，就说明服务器无法执行增加的请求（每秒点击率），结果就是事务反应时间的增加。

7、HTTP Responses Second(每秒HTTP响应数)

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

进而定位生成错误的代码脚本。常见http状态返回代码如下：

200 （成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。

201 （已创建） 请求成功并且服务器创建了新的资源

202 （已接受） 服务器已接受请求，但尚未处理。

203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一个源。

204 （无内容） 服务器成功处理了请求，但没有返回任何内容。

205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。与204响应不同，此响应要求

请求者重置文档视图（例如，清除表彰内容以输入新内容。）

206 （部分内容） 服务器成功处理了部分请求。

301 （永久重定向） 请求的网页已永久移动到新位置。服务器返回此响应（对GET 或HEAD请求的响应）时，会自动将请求者转到新位置。

404 （请求的内页未找到）服务器找不到请求的网页。例如，对于服务上不布在的网页经常会返回此代码。

500 （服务器内部错误）服务器遇到错误，无法完成请求，一般是由于页面代码加载出错造成。

503 (服务不可用) 您的 Web 服务器实际上处于“关闭维修”状态。 它仍然在最低限度地运行， 因为它至少可以响应 503 状态码，但全面服务是不可能的， 即您的网站不可用。 可能的原因有很多， 但一般来说， 是由于您的 Web 服务器操作员的人为干预。通常您就应知道有人正在努力解决此问题，正常服务将被尽快恢复。

二、系统资源分析

1、内存分析方法

内存分析方法主要是用于判断系统有无遇到内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。主要计数器包括Memory和PhysicalDisk类别的计数器

内存分析的主要步骤和方法如下

（1）首先查看Available Mbytes指标

该值是用于描述系统可以内存的直接指标，在对系统进行操作系统级别的内存分析时，首先应通过该值建立一个初步的印象，了解性能系统测试过程中，系统是否仍然有足够的内存可用。

如果该指标的数据比较小，系统可能出现了内存方面的问题，此时需要进一步分析。

（2）注意Pages/sec、Pages Read/sec和Page Faults/sec的值

操作系统经常会使用磁盘交换的方式来提高系统可用的内存量或是提高内存的使用效率。这三个指标直接反映了操作系统进行磁盘交换的频度。

如果Pages/sec的计数器持续高于几百，很可能存在内存方面的问题，但其值很大不一定表示内存有问题，

而可能是运行使用内存映射文件的程序所致。

PageFaults/sec说明了每秒发生页面失效的次数，页面失效次数越多，说明操作系统向内存中读取的次数越多。

些时不需要查看Pages Read/sec 计数器。该计数器阀值为5，如果超过5，则可以判定存丰内存方面的问题。

（3）根据Physical Disk 计数器的值分析性能瓶颈

对于Physical Disk 计数器的分析包括Pages Read/sec和%Disk Time 及AverageDisk Queue Length 的分析。

如果Pages Read/sec很低，同时%Disk Time 和Average Disk Queue Length的值很高，则可能有磁盘瓶颈。

但是如果Average Disk Queue Length增加的同时PagesRead/sec并未降低，则是由于内存不足。

2、处理器分析方法

（1）首先查看%Total Processor Time性能计数器值

该值用于体现服务器整体的处理器利用率，对多处理器的系统而言，该数值体现的是所有CPU的平均利用率。

如果该值的数值持续超过90%，则说明整个系统面临这处理器方面的瓶颈，需要增加处理器来提高性能。

注意：

由于操作系统本身的特性，在某些CPU系统中，该数据本身并不大，但此时CPU之间的负载状况不均衡，

此时也应视作系统产生了处理器方面的瓶颈。

（2）其次查看每个CPU的%Processor Time 和%User Time 和A%PrivilegedTime.

%User Time 是指系统的非核心操作的CPU时间，如果该值较大，可以考虑是否通过算法优化等方法降低该

值。如果服务器是数据库服务器，Processor的%UserTime值大原因很可能是数据库存的排序或函数操作消耗了过多的CPU时间，此时可考虑对数据库系统进行优化。

（3)研究系统处理器瓶颈

查看Processor Queue Length 计数器的值，当该值大于您的Web 服务器实际上处于“关闭维修”状态。 它仍然在最低限度地运行， 因为它至少可以响应 503 状态码， 但全面服务是不可能的，即您的网站不可用。 可能的原因有很多， 但一般来说， 是由于您的 Web 服务器操作员的人为干预。通常您就应知道有人正在努力解决此问题，正常服务将被尽快恢复.当该值大于CPU数量的总数+1时，说明产生了处理器阻塞。如果该值持续超过95%,就表示当前系统的瓶颈为CPU,可以考虑增加一个处理器或更换一个性能更好的处理器。（参考值:<80%）

%DPC Time是另一个需要关注的内容，该数值越低越好，在多系统处理中，如果这个值大于50%并且Processor\%ProcessorTime非常高，加入一个网卡可能会提高性能。