LoadRunner-总结（四）

LoadRunner-总结（四）

目录

• 1、Run-Time Setting
• 2、连接不同DB方式
• 3、虚拟用户执行期间的状态
• 4、主要性能指标

1、Run-Time Setting

（1）Run Logic

脚本是如何运行的以及每个Action和Action之间运行的先后顺序就是在这里设置的。

Run Logic提供了两种运行模式：Sequential（顺序）模式和Random（随机）模式。而Iterations用来设置Run上的迭代次数。

设置Run Logic为Sequential模式，Iterations为2。Run下的所有脚本将按照从上到下的先后顺序运行。同时在Run上会出现一个循环的显示。

如果选择Random模式，那么在Run下的所有脚本将根据各自设置的比例进行随机选择并运行。这时Run上的标志会多出一个百分比符号。这里需要对Run下的每一个Action进行单独的属性设置，修改它们的百分比。

通过Random这种方式，能方便地生成一些随机用户行为的模拟。例如需要模拟用户有40%的可能性去注册，有60%的可能性去登录，就可以通过Action在Run Logic中的随机运行来简便地解决这个问题。

Block是一个很有趣的功能，它提供了一个脚本块的功能，方便对脚本进行层次组合。通过单击右侧的Insert Block按钮可以为脚本添加一个块，在这个块中可以继续添加脚本，而每个块都可以实现顺序/随机的运行方式，并且块上还能设置循环的次数，通过这种块的扩展，就能运行各种复杂的脚本。

（2）Pacing

配置脚本运行中每次迭代之间的等待时间。如果需要周期性在脚本中重复做某些事情，可以通过Pacing来实现。

Pacing是根据脚本的Iteration来执行，也就是说每出现一次Starting Iteration或者Ending Iteration就会检查一次Pacing设置。

1．As soon as the previous iteration ends

默认设置下前一次迭代和后一次迭代之间无等待时间。

2．After the previous iteration ends

这里可以设置当前脚本Ending Iteration后，需要等多长时间再进行下一次Starting Iteration。有两种方式，一种是fixed，也就是指固定等多少时间，另一种是random，即随机等待某个范围内的时间。

例如，希望模拟发一个帖子后等待5分钟再发下一个帖子，一共发50个帖子，那么可以将发帖做成一个Action，通过在Run上设置50次迭代，然后设置fixed的值为300秒即可。

3．At(provided that the previous iteration ends by that time)

这里和上面的不同点在于，Pacing的时间是指前一个脚本的Strating Iteration到下一个脚本的Starting Iteration之间的时间。这里同样可以设置为fixed或者random方式。如果要模拟用户每隔5分钟发一个帖子，一共发50个帖子，那么可以将发帖做成一个Action，通过在Run上设置50次迭代，然后设置fixed的值为300秒即可。

补充：两种方式的区别

With是指前一次Ending Iteration到下一次Starting Iteration之间的时间。

At是指前一次Starting Iteration到下一次Starting Iteration之间的时间，所以At包含了前一次迭代执行的时间。

在At模式下，一次迭代执行的时间若大于Pacing的时间，则系统会提示无法达到Pacing的时间设置，脚本不做等待立即运行下一次迭代，可以用来验证一次迭代的处理时间是否在期望的阈值内。

（3）Log

该选项提供了一定的调试分析基础，脚本的回放验证很多时候就是依靠日志来实现的。

日志分为以下两大类：

Standard Log（标准日志）

Extended Log（扩展日志）

1．Parameter substitution

将参数赋值操作作为日志输出（输出内容为蓝色）。

2．Data returned by server

将服务器返回的请求作为日志输出。

3．Advanced trace

高级跟踪日志。

（4）Think Time

Think Time是一种等待时间的方式，由于VuGen回放脚本是全速运行的，而真正用户的操作并不会如此迅速，所以需要通过添加等待时间的方式，在脚本的运行中模拟用户的等待操作。

（5）Additional attributes

这里提供了自定义参数的功能，可以在这里先输入一些常用的参数名及对应的值，类似于常量，通过lr_get_attrib_string()函数来获取这些参数名对应的值。

例如，我们在这里添加一个名为test的参数，其对应的值为123456。

（6）Miscellaneous

1．Error Handling（错误处理）

在VuGen中，脚本中某个函数出错会导致整个脚本的停止运行，但是在场景中会继续运行，其原因就在于Continue on error选项。而Generate snapshot on error提供了错误截图的支持。在负载过程中建议不要同时打开Continue on error和Generate snapshot on error支持，这样会大幅降低负载效率。Fail open transactions on lr_error_message是指当事务中出现lr_error_message函数时，将会设置该函数所在的事务状态为Fail。

2．Multithreading（负载进程与线程方式设置）

进程就是指在场景中使用mmdrv.exe的进程方式来模拟虚拟用户，每一个虚拟用户都会使用一个mmdrv.exe进程。而线程模式是指所有的虚拟用户都会使用mmdrv.exe下的线程来进行脚本运行。在进程与线程的选择中，线程模拟用户对负载生成的资源消耗较小，但有些时候会出现负载错误；进程比较稳定，但资源开销较大。

3．Automatic Transactions（自动化事务）

事务是用来获得某一行为所消耗时间的函数。在LoadRunner 11版本中该选项默认不选，而在以前版本会默认将每个Action设置为一个事务。由于Action是一个行为的组合而不是一个行为，对于新手来说往往会错误地理解Action时间导致对性能测试结果中的响应时间产生疑惑。

（7）Speed Simulation

提供了带宽模拟的选项，在默认情况下，脚本是以最大带宽来进行访问的，作为一个局域网，下载图片甚至视频都会十分迅速。如果设置了带宽限制，那么得到的响应时间就会更接近于真实的用户感受。

例如，将带宽设置为128Kb/s，再次运行脚本，会明显感觉到脚本运行的速度比以前要慢了很多。

（8）Browser Emulation

通过Change User-Agent的属性，可以将脚本模拟成各种浏览器，用来做浏览器兼容性测试再合适不过了。在这里不但能设置浏览器模拟的类型，还能设置是否需要模拟Cache的处理方法，从而实现第一次访问较慢，下一次访问读取Cache较快的真实情况。当在一个脚本内执行两个相同的请求时可以在日志中看到，后一个请求会由于Cache机制不下载对应的非资源文件，从而比前一个请求更快完成（服务器上也有类似的Cache机制）。

例如，我们可以在脚本中编写两个相同的请求，当执行脚本后我们可以在日志中看到系统提示Resource "XXX" is in the cache already and will not be downloaded again，说明该请求已经被Cache而不会被下载，整个请求的Body字节变小。

在该设置对话框中，Simulate a new user on each iteration这个选项比较特殊，在前面说过iteration的概念。当打开这个选项后，VuGen会在每次迭代之前清除所有的前后文内容，来模拟一个新用户进行本次迭代的操作，web_cleanup_cookies函数可以实现相同的效果。

Clear cache on each iteration用来在每次迭代中清除对应的Cache，用来模拟新用户第一次访问的效果。如果需要手工清除Cache，避免后面请求被Cache时可以使用web_cache_ cleanup函数。

（9）Preferences

1．Checks

打开图片和文本检查支持。设置该选项后，系统在回放过程中将支持web_find()、web_image_check()函数，对图片和文本进行检查，由于重点是性能测试而非功能测试，从节约系统内存的角度来说一般会关闭该选项。

2．Generate Web performance graphs

该选项用来设置回放时是否监控页面性能计数器。当该选项被选中时，在场景中才能获得Hits per second与Pages per second数据。

3．Advaced

1）WinInet replay instead of Sockets (Windows only)

在默认情况下脚本都是通过Sockets端口的方式进行回放的，在某些情况下这种回放方式会被服务器拒绝，那么可以换用WinInet的引擎来回放脚本。

IE浏览器也是基于WinInet引擎的，所以兼容性会好一点，但WinInet不支持UNIX系统（即负载生成服务器只能安装在Windows平台上）。另一方面该引擎在线程模式下无法正常统计连接用户数和连接带宽。

2）File and line in automatic transaction names

当添加一个新的脚本时，系统是否自动添加唯一的事务名。

3）Non-critical resource errors as warnings

在录制的脚本中，大多数请求都会带一个参数EXTRARES。在这个参数后会带有一些图片资源文件的链接地址，VuGen函数在发出请求后会验证一下该请求是否能返回EXTRARES下相关地址的对应资源，如果修改相关资源的地址，脚本回放时会发现服务器即便没有返回相关的图片资源脚本也不会出错。如果希望脚本完全验证整个访问过程中的每个页面请求和相关资源，这个时候就需要取消该选项。

资源文件如果出错，将不以Warnings提醒的方式出现，而直接出现ERROR。

Advanced Options很重要，提供了对HTTP请求的所有设置选项，包括HTTP超时的时间限制、请求的发送和接收格式。

（10）Download Filters

很多时候我们的被测对象里面都会带一些站外链接，但是测试一般不能访问到外网的，就会由于被访问对象中读取外网资源导致响应时间的变化，Download Filters功能就是帮助我们在回放脚本的时候对某些特定的访问进行屏蔽，来解决页面读取中跨服务器带来数据影响的问题。

过滤规则中有3种策略，即URL、Host、HostSfx。

URL是对一个固定地址的，无法通配，只能写一个固定的地址。

Host是主机，你写一个主机名就可以过滤所有这个主机名下的内容。

HostSuffix是加强，只需要写服务器的域名后端，就能过滤所有前面的内容。

（11）Data Format Extensions

与录制选项中的该功能相比，这里就简单得很多了。主要是指是否在回放脚本的过程中对返回的数据包进行DFE格式转化，便于后期的关联函数的使用，该功能与LoadRunner 11新的关联函数有关，如果需要使用新的关联函数该功能选项需要打开。

2、连接不同DB方式

3、虚拟用户执行期间的状态

4、主要性能指标

Transaction Performance Summary（事务性能概要）

落差越小说明响应时间的波动较小，如果落差很大，那么说明系统不够稳定。

Transaction Response Time Under Load（在用户负载下事务响应时间）

数据线条越平稳，说明系统越稳定。

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

数据越平稳说明响应时间变化越小。

Transaction Response Time（Distribution）（每个时间段上的事务数）

响应时间较小的分类下的事务数越多越好。

Hits per Second（每秒点击数）

每秒点击数提供了当前负载中对系统所产生的点击量记录。每一次点击相当于对服务器发出了一次请求，一般点击数会随着负载的增加而增加，该数据越大越好。

Throughput（带宽使用）

该数据越小说明系统的带宽依赖越少，通过这个数据能确定是否出现了网络带宽的瓶颈（注意这里使用的单位是字节）。

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

该数值一般和每秒点击量相同。点击量是指客户端发出的请求数，而HTTP响应数是指服务器返回的响应数。如果服务器返回的响应数小于客户端发出的点击数，那么说明服务器无法应答超出负载的连接请求。

Retries Per Second（每秒重接数）

主要说明被服务器主动断开导致重试服务器连接的数目，该数据越低，说明服务器端的连接释放越长。导致的情况可能如下:

A. 初始连接未经授权

B. 要求代理服务器身份验证

C. 服务器关闭了初始连接

D. 初始连接无法连接到服务器

Connections Per Second（每秒连接数）

中断的连接和新建的连接，方便用户了解当前每秒对服务器产生连接的数量。

同时的连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止上升时，说明系统的连接池已满，无法连接更多的用户，通常这个时候服务器会返回504错误。可以通过修改服务器的最大连接数来解决该问题。