前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：
通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：
“要求系统支持 100 个并发用户”
看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其 *** 作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。
事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。
因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角。
对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义：
“要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )
面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction)的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后，LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。
因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。
最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。
花了几天的时间才完成这篇文章，如果它能够帮助大家对性能测试多一些理解或者多一些思考，那就是我的荣幸了。 ^_^
Pacing 是两次迭代之间的间隔时间设置这个时间和不设置这个时间对测试结果影响很大！
设置这个时间可以减轻服务器端的压力！
具体可以参考这个地址，我百度hi给你！
在loadrunner里，有两个概念很容易被混淆：pacing和think time。相关书籍中很难查阅到对pacing的讲解。这两个名词该如何理解，如何应用呢？
它们都出现loadrunner VUGen的run-time settings里，是不同的概念。先引用帮助文档里的解释：
The pacing let you control the time between iterations. The pace tells the Vuser how long to wait between iterations of your actions。
Vuser think time emulates the time that a real user waits between actions. For example, when a user receives data from a server, the user may wait several seconds to review the data before responding. This delay is known as the think time.
为了更好的讲清楚，引入iteration的概念。Iteration，迭代。通过设置，可以指定虚拟用户在同一个Action中重复执行多次，每次重复称之为一个iteration。Iteration可以帮助我们模拟现实世界的重复场景。
Pacing，步调。可以通过设置两次迭代之间的间隔时间，来调整各个action之间的步调（或者称之为节奏）。从定义上来看，Pacing是和iteration绑定在一起的，可以认为是iteration pacing。
Think time，思考时间。可以通过设置思考时间，来模拟真实用户在 *** 作过程中的等待时间。从定义上来看，think time是在iteration内部的某个action中各个步骤的间隔时间。
到这里，已经能看出两者之间的区别，但是容易混淆的。接下来通过一个例子来进一步说明，期望能够深入浅出。
淘 宝 购 物车应用，假定每分钟有6000个在线用户浏览（Browser），共10台服务器。用户在浏览过程中，先打开购 物 车页面，花了1秒钟时间浏览整个页面，然后查看其中的某个宝贝。此时，在性能测试场景中（如果模拟真实场景的话），就会在两个步骤之间设置一个等待时间think time = 1 秒 。如下图1-1所示：
假设用户进行一次上述 *** 作会消耗5秒钟的时间，即完成整个迭代需要5秒钟。如果用户不停顿，继续第二次重复 *** 作，则同样耗费约5秒左右的时间。但是真实世界中肯定是有停顿的。一个真正的用户，做完一系列 *** 作后，会间隔一段时间。假定用户停顿了5秒，再第二次重复 *** 作，则一共耗费10秒钟时间。映射到 loadrunner中，就需要在一次iteration中，设置一个think time = 1秒，然后在两个iteration之间，设置一个pacing为5秒。如下图1-2所示：
一个虚拟用户在1分钟内，就能完成6次的迭代，12次请求。而要达到有6000个用户的浏览量，我们需要6000/12 /10= 50个虚拟用户。
通过上面的例子，相信大家对pacing和think time已经有了相应的理解。至于在loadrunner中符合使用、怎样配置，则可以通过帮助文档来加深认识。在此不一一说明。
尽管性能测试的需求通常都是从客户端角度来定义的，比如“系统需要支撑100个并发用户”、“每分钟有6000个请求量”，但是压力应该以服务器为中心来看待。原因很简单，从loadrunenr端发送出去的请求，需要等待服务器端响应之后才能发送下一个请求。可以说，对于每个虚拟用户，它对服务器发送请求的频率取决于服务器对请求的处理时间。
如果需要模拟真实用户的 *** 作，从而模拟服务器端的真实变动，think time和pacing是两个必不可少的设置项。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）