LoadRunner中的Pacing(步长)---转载

上一篇 / 下一篇  2012-09-06 15:29:28 / 个人分类:性能测试

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

 

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

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

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

 

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

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

因此,上面所描述的做法的局限性就是,它反映的仅仅是客户端的视角。51Testing软件测试网5k+@S y­g&Nh| X |L`

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


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

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

 

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

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

最后,祝福测友们在软件测试和质量保证这条道上 越走越宽  越走越深!


TAG:

引用 删除 早安中国   /   2015-10-10 08:14:18
5
小柯烨的测试世界 引用 删除 小柯烨   /   2013-02-20 13:48:02
菜鸟@大虾的个人空间 引用 删除 菜鸟@大虾   /   2012-09-11 14:52:34
谢谢 云层的回复,现在小弟又有新问题了,请陈哥教诲, 1:到底要不要设置步长?2:若设置步长,设为多少合适呢?哪些数据可以作为步长的参考信息呢?  望云层大哥引领小弟,弟再拜
云层专版 引用 删除 云层   /   2012-09-06 18:39:20
但是你忽略了一个真实负载中可能出现排队的情况,而无法得到多少负载会产生排队导致响应时间变长的真实结果!
那么你设置不合理的pacing就片面的降低了负载
 

评分:0

我来说两句

Open Toolbar