LoadRunner11学习记录三 -- 迭代和并发

LoadRunner中%d和%s是什么意思？

%d 格式化输出短整形数据,TC环境中占用两个字节，输出整数范围为:32768~32767.Visual C++环境中占用四个字节，输出数据范围为:-2147483648~2147483647

%u 格式化输出无符号短整形

%ld 格式化输出长整形,一般占四个字节

%c 输出字符型数据（单个字符），也可输出整型数据，范围为1~127

%s 输出字符串

Attributes:  
> HTTP_INFO_RETURN_CODE: 返回HTTP头文件的code值，如；200、404等； 200是服务器成功返回网页；404请求网页不存在；503服务器超时；500(服务器内部错误)服务器遇到错误，无法完成请求。

> HTTP_INFO_DOWNLOAD_SIZE: 返回最近一次下载的大小，单位是bytes;   1MB=1024KB，1KB=1024字节；所以1MB=1048576字节。

> HTTP_INFO_DOWNLOAD_SIZE: 返回最近一次下载的时间，单位是millisecond(毫秒).  1毫秒(ms)=0.001秒(s)

lr_output_message("页面下载时间");//输出提示信息

lr_output_message("%d", web_get_int_property(HTTP_INFO_DOWNLOAD_TIME));//输出页面下载时间

lr_output_message("%d", web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE));//输出下载的大小

EXTRARES分隔符后面的代码在没有100%的把握情况下，最好不要去掉。

关于这一点，结论是EXTRARES部分不能删，删除了LR就不会去下载相关资源了，也就意味着一个请求的Response会变小，毫无疑问，响应时间就会变得快一些，吞吐量变得少一些，数据变得非常的不真实。

关于LoadRunner的迭代和并发：

比如，一个用户迭代十次，还是一个用户的压力。

10个用户执行一次，就是10个用户的压力。10个用户迭代10次，还是10个用户的压力。但他们都和参数化的数据有关系（也要看参数化是如何设置的，以及系统如何判断提交值的）。

说一个比较容易理解的层面：迭代就是不停的反复调用同一脚本，反复执行，注意，对1个用户执行10次来说，只会分配一块内存。10个用户执行一次，是调用同一脚本10次，会分配10块内存。LR调用脚本，编译后，运行，按脚本发送数据。

用比喻的方式来回一下：

四车道的马路，如果只有四辆车并排走过就是并发；
                 如果四辆车排成一纵队走过就是迭代；
                 如果有100辆车排成25行依次走过就是并发加迭代。
在以上说法中，只有并排的车是我们设置的用户数。

关于LoadRunner的迭代和持续时间：

Controller运行中，迭代和持续时间是互斥的。

持续时间的优先级高

也就是说：即使你指定了迭代次数，但是运行时间没有结束之前，还是会一直迭代的。所以实际迭代次数可能大于你设置的迭代次数；

还有一种情况，迭代次数还没完，但是运行时间已经到了，此时会将当前执行的Action执行完，停止迭代，此种情况下实际迭代次数小于你设置的迭代次数。

迭代的意义：

以下内容是转载的，只做记录一下：

 

问题1：通过用lr做负载压力测试过程发现，如果设定不同的action迭代次数，每次得出的结果是不同的，曲线的表现形式也是不同的。这点就使我们会感觉困惑,为什么要设置action的迭代次数？以及对于不同的应用系统应该怎样设置迭代次数呢？

 

答：首先你要理解性能测试是在干什么？

 

性能测试是模拟系统一段时间内真实的压力情况，以考察系统的性能。

 

再看怎么模拟系统真实的压力情况？比如在半个小时内，用户都在进行登录操作，且平均分布在这半个小时内。我们要做的是什么？模拟这半个小时用户的行为。怎么模拟？估算出同时操作的人数，并用LoadRunner不断的发送登录请求，这就是我们为什么要迭代。

 

至于迭代次数，只要能够模拟出真实情况，多少次都无所谓，不过10次8次估计是模拟不出来。迭代次数至少要保证压力达到一个稳定值后再运行一段时间，这样我们得到的数据才是有效的。所以我们除非是特别要求，一般不用迭代次数，而是用运行时间。

 

1，迭代和并发，是完全不同的概念。没有什么关系。

 

比如，一个用户迭代十次，还是一个用户的压力。

 

10个用户执行一次，就是10个用户的压力。10个用户迭代10次，还是10个用户的压力。但他们都和参数化的数据有关系（也要看参数化是如何设置的，以及系统如何判断提交值的）。

 

2,你要是想知道，LR是如何实现迭代和并发：

 

说一个比较容易理解的层面：迭代就是不停的反复调用同一脚本，反复执行，注意，对1个用户执行10次来说，只会分配一块内存。10个用户执行一次，是调用同一脚本10次，会分配10块内存。LR调用脚本，编译后，运行，按脚本发送数据。

 

比如：web_url这样的函数，执行就会发HTTP request。

 

如果你还想知道更细节的进程和函数的实现，只能侧面验证（具体方法看各人的能力和擅长），因为我们都不是LR的开发者。

 

3,太显然的问题了，参数化时选择每次出现唯一，只要参数够用就OK，不够用，就设置相应的规则。

 

action在场景运行中iteration只对其起作用，对vuser_init和vuser_end都不起作用，action是一个可以被重复使用的最小单位其实你可以将所有脚本录制到一个action里，只是不方便管理罢了。

 

举个最简单的例子，像lr自带的例子——订票系统，你如果把所有脚本都录制到一个action里，那回放的时候，每个用户登录就只能买一张票，而如果想一个用户买多张票的话，这样就行不通了。那你就要设多个action，并把登录和结束各录制在一个action里，把买票录到一个action中，这样，将买票的action迭代多次，而用户登录和结束只运行一次，这不就模拟了现实中的情况了吗？

 

其实LoadRunner 是以客户端的角度来定义“响应时间”的，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果，设置步长则可以缓解这一情况，这样，应该试试设置pacing，再运行看看情况。

4、并发用户数量，有两种常见的错误观点。

一种错误观点是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；

还有一种比较接近正确的观点是把用户在线数量理解为并发用户数量。

实际上，在线用户不一定会和其他用户发生并发，例如正在浏览网页的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。并发主要是针对服务器而言，是否并发的关键是看用户操作是否对服务器产生了影响。 因此，并发用户数量的正确理解为：在同一时刻与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。 比如说：有一个这样的场景，系统在线用户是100个，但是同时操作某一个事物（比如说登陆操作）的人是20个那么场景怎么设计了？在Controller中设置100个虚拟用户执行这个脚本，然后登陆操作之前放一个集合点，然后设置集合点的策略（20个用户到达时即执行集合点） 对于多个业务场景, 只要录制多个脚本放在同一个场景内, 然后分配不同比例的虚拟用户就可以了, 如果不想跑哪个业务场景, 那就不选中这个脚本即可.

追问

  

并发用户数，我可不可以在采集的时候理解为最大的允许vuser值

 

回答

  

某个脚本设置的vuser值, 可以理解为这个业务场景的并发用户数,但如果要测试具体某个业务的并发操作,  那就需要设置集合点, 而且集合点数目不能大于vuser值.