loadrunner--步长（Pacing）的设置及作用

Pacing时间的设置需要根据使用您系统的用户的行为来决定。

如果您那边的用户在您的系统上做完一套操作后不会做下一套，则可能不需使用Pacing。

如果您那边用户在系统上需要不断地做同样的操作，比如他要反复的浏览或者操作一些信息，每做完一套操作后可能需要做一些确认或者是停顿，则需要添加Pacing时间。

1、步长的设置会影响虚拟用户一次迭代中的Action之间的等待时间和该虚拟用户上次迭代和下次迭代的等待时间，不同虚拟用户之间的迭代等待时间是不受影响的。

2、这个设置的功能从字面上就很容易理解，即在场景的两次迭代(iteration)之间，加入一个时间间隔（步进）。

3、通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：

“要求系统支持100个并发用户”

看到这样的性能需求，我们往往会不假思索地就在测试场景中设置100个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。

事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。

因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角。

对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义：

---

“要求系统的事务处理能力达到100个/秒”(这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求)

面对以这样方式提出的性能需求，在LoadRunner中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了100个并发用户数，它就会每秒向服务器提交100个请求，这是两个不同的概念，因为LoadRunner模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（RPS），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务(transaction)的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道，LoadRunner是以客户端的角度来定义“响应时间”的，当客户端请求发出去后，LoadRunner就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。

因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的Pacing这个值的作用。

最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。

云层：

但是你忽略了一个真实负载中可能出现排队的情况，而无法得到多少负载会产生排队导致响应时间变长的真实结果！
那么你设置不合理的pacing就片面的降低了负载