关于LoadRunner的迭代

通过用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，再运行看看情况。