51Testing软件测试论坛

标题: 谈谈LoadRunner中Pacing的设置 [打印本页]

作者: xingcyx 时间: 2006-12-28 15:16
标题: 谈谈LoadRunner中Pacing的设置
在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。

前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：

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

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

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

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

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

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

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

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

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

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

花了几天的时间才完成这篇文章，如果它能够帮助大家对性能测试多一些理解或者多一些思考，那就是我的荣幸了。 ^_^

[ 本帖最后由 xingcyx 于 2006-12-28 15:18 编辑 ]

作者: Zee 时间: 2006-12-29 01:21
我的理解是：pacing排除了需要过分的因网络而排队的需要，是网络拥塞控制的一个功能，抓住这点就行了。

作者: s1ckness 时间: 2006-12-29 09:41
每次用迭代均告失败，郁闷。
测试理论欠缺，学习中。

作者: xingcyx 时间: 2006-12-29 10:24

原帖由 Zee 于 2006-12-29 01:21 发表
我的理解是：pacing排除了需要过分的因网络而排队的需要，是网络拥塞控制的一个功能，抓住这点就行了。

网络只是其中的一方面而已。
系统中还可能存在各种情况下的拥塞。。。

作者: xingcyx 时间: 2006-12-29 10:26
从我的blog上转贴Jackie兄的回复：

其实这篇文章最早是在 2006 年初看到的，过去几个月，发现对里面的内容已经有点遗忘了。所以看到你在我 blog 留言后，就又翻出来看了几遍。这次再看，发现有不少地方同 Kirk 的看法有分歧。本来想专门写篇文章来讨论一下，不过看到兄台已经打了个基础，不妨咱们就依照这个基础来讨论下去 ^_^

由于晚上时间也有限，所以我想今天我先说说我对 Tuning your stress test harness 这篇文章的一些不同看法，改天咱们可以继续讨论，搞个连载 ^_^

Kirk 在 Tuning your stress test harness 一文中提出的一个重要的观点就是“放慢速度，做得越多”。这其实是一种场景设计的思路，Kirk 提出这个的原因是他认为那些“不增加服务器负载的线程看起来会降低服务器的性能”，于是，Kirk 通过人为的方法来限制了 RPS（Request per Second）的值——这里我们要注意到的是，实际上 Kirk 是将 RPS 控制为小于 The Number of Concurrent Users 的值。以文中的例子来说，Kirk 是在 50 个并发用户的情况下，将 RPS 控制在了 9 个左右。这样的结果是什么？不知道你有没有注意到，在这篇文章中，Kirk 是以 RPS 作为指标衡量系统负载的，这种做法就算是所谓的“服务器视角”了吗？

我们知道对于一个给定的系统来说，在某个特定的环境和场景中，它的“最佳并发用户数(The Optimum Number of Concurrent Users)”是客观存在的——关于“最佳并发用户数”的概念可以参见我的《LoadRunner没有告诉你的之三——理发店模型》一文（http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html ）。当并发用户数大于这个“最佳”时，就会出现排队的情况。如果这个并发量一直持续，那么随着时间的流逝，队列也会越来越长，而越往后的请求在队列中等待的时间也越长，从性能测试工具中看到的响应时间也会越来越长。而这就是 Kirk 认为不合理的地方。但实际上是这样吗？当我们使用 LR 或者 JMeter 这类性能测试工具测试时，队列真的会越来越长吗？响应时间也会越来越长吗？

今天先写这么多，如果有了不同的看法，我们明天继续 ^_^

作者: xingcyx 时间: 2006-12-29 10:27
以下是我的回复：

谢谢Jackie的回复！
按照我的理解，Kirk所说的RPS，是以服务器为视角来看的每秒请求数，也就是每秒钟到达服务器端的请求，而不是从客户端发出请求的频率，我们知道这二者是会有差别的，否则的话，我们也用不着一直强调说做性能测试的时候一定要排除网络等因素的影响。同时这也是我看这篇文章获得最大的一个收获，因为他教我们用一个不同角度去看待问题。不过说实话，我也没有弄明白他把RPS设成9的原因，从他的描述和图中，我看不出这其中的对应关系。这个问题其实也让我想了好久，但他所说的RPS代表服务器视角，这一点我还是比较认同的，不知道你的意见如何，欢迎继续讨论。

当我们使用LR等工具的时候，队列确实不会越来越长，这个问题Kirk在文中也提到过了，他想告诉我们的是，由于我们所使用的工具的限制，导致了看似服务器在应付一种稳定状态的负载，其实却是个发散的队列（因为工具会在收到服务器响应后才会发出第二个请求），这也是他所指出的问题关键所在。但响应时间的确会越来越长的，因为当客户端收到服务器请求以后，如果我们没有设置延时，那么客户端会立即发出下一个请求，同时启动计时器，而此时如果服务器的资源已经满负荷，这个请求并不会进入排队队列，那么这个时间其实是多计算的，因此后面的这些请求的平均时间将越来越长，导致整个平均值不准确。

另外这里我再提一个没有在我上面的文章中提到的一个问题，就是这个以“服务器视角”提出的性能需求应该是什么样子的，以前从来没有考虑过这个问题。

作者: xingcyx 时间: 2006-12-29 10:28
更多讨论，尽在：
http://www.blogjava.net/xingcyx/ ... l?Pending=true#Post

作者: Zee 时间: 2006-12-29 13:22
顶一下，有想法再回。

作者: hxxhhl 时间: 2006-12-29 14:30
纯mark

作者: zhenhaiou 时间: 2006-12-29 15:34

原帖由 xingcyx 于 2006-12-29 10:26 发表
从我的blog上转贴Jackie兄的回复：

Kirk 通过人为的方法来限制了 RPS（Request per Second）的值——这里我们要注意到的是，实际上 Kirk 是将 RPS 控制为小于 The Number of Concurrent Users 的值。以文中的例子来说，Kirk 是在 50 个并发用户的情况下，将 RPS 控制在了 9 个左右

如果认为控制了RPS，那使用多少个用户还有有意义么？100个用户并发时也可以控制rps在9个阿，1000用户时个也可以阿，这样做的目的是什么呢？

作者: lemon_hawk 时间: 2006-12-29 16:02
不要忘了测试的目的！更不要为了达到一个好的测试结果而去刻意设置参数，来达到你心目中的结果。

作者: lijian422202 时间: 2006-12-29 16:28
个人意见，其实这个问题和THINKTIME差不多，用THINKTIME和不用的区别！其实关键是要尽可能的模拟现实的环境。

在脚本ACTION的最后加THINKTIME应该和pacing一样的效果的！

作者: xingcyx 时间: 2006-12-29 17:04

原帖由 zhenhaiou 于 2006-12-29 15:34 发表

如果认为控制了RPS，那使用多少个用户还有有意义么？100个用户并发时也可以控制rps在9个阿，1000用户时个也可以阿，这样做的目的是什么呢？

有意义。
可能我在文中还没有写得太清楚。“并发用户”是从客户端的角度来提的性能需求，而“每秒请求数”是从服务器的角度来提的，并没有谁对谁错，这只是一个问题的两个方面而已。
我接下来在考虑的一个问题是，如果从服务器的角度，性能需求应该怎么提的？

作者: xingcyx 时间: 2006-12-29 17:04

原帖由 lemon_hawk 于 2006-12-29 16:02 发表
不要忘了测试的目的！更不要为了达到一个好的测试结果而去刻意设置参数，来达到你心目中的结果。

这个参数不是为了一个好的测试结果而设置的，而是为了进行更严谨的测试而设置的

作者: xingcyx 时间: 2006-12-29 17:06

原帖由 lijian422202 于 2006-12-29 16:28 发表
个人意见，其实这个问题和THINKTIME差不多，用THINKTIME和不用的区别！其实关键是要尽可能的模拟现实的环境。

在脚本ACTION的最后加THINKTIME应该和pacing一样的效果的！

你说的没错，也有这方面的原因。而这也是很能迷惑人的，我在文中也提到了，我在以前之所以没有对这个问题进行深入的思考，一部分就是因为想当然地把它和thinktime等同起来，其实这仅仅是一部分的原因而已。

作者: lijian422202 时间: 2006-12-29 17:10
而是为了进行更严谨的测试而设置的!

这句话顶一下！

作者: picture 时间: 2006-12-30 09:34
帖子不错,个人也认为从客户端和服务器去看测试有很大的不同,如果是从响应时间上看,LR确实是从客户端考虑的,这也是比较合理的,但LR设置100个用户去负载WEB是否真正的模拟了100个用户并发那,这个我一直就没弄明白,LR是如何定义并发的概念的,那位高人能指点一下

作者: zhenhaiou 时间: 2006-12-30 09:54

原帖由 xingcyx 于 2006-12-29 17:04 发表

有意义。
可能我在文中还没有写得太清楚。“并发用户”是从客户端的角度来提的性能需求，而“每秒请求数”是从服务器的角度来提的，并没有谁对谁错，这只是一个问题的两个方面而已。
我接下来在考虑的一 ...

rps就是从服务器的角度提的，如果请求数很高，而服务器也能很快地处理，说明服务器满足性能要求；如果产生了排队，说明不能满足要求，就要通过人为的方法改变rps的值，知道没有排队现象；
是不是可以这样理解呢，呵呵

作者: xingcyx 时间: 2006-12-30 12:55

原帖由 zhenhaiou 于 2006-12-30 09:54 发表

rps就是从服务器的角度提的，如果请求数很高，而服务器也能很快地处理，说明服务器满足性能要求；如果产生了排队，说明不能满足要求，就要通过人为的方法改变rps的值，知道没有排队现象；
是不是可以这样理 ...

不是这样的，并不是说只要在服务器端产生了排队，就是不能满足要求。

这个问题可以到这里看看，
http://www.blogjava.net/xingcyx/ ... l?Pending=true#Post

我相信你能够得到满意的答案。^_^

作者: kun_fly 时间: 2008-11-19 17:39
我有点困惑，如果设置步进的话，限制了用户的并发请求是不是就达不到所谓的并发了。我个人理解并发是所有的用户同时提交数据，而设置步进就失去了同时的意义！请指教。。。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)