关于loadrunner pacing设置对测试结果的影响问题，请大家帮忙解答
比如我现在有两个场景：一是，有50个用户并发，每个用户的iteration设为5次，pacing（间隔时间）设为0，即as soon as那种
二是，有50个用户并发，每个用户的iteration设为5次，pacing（间隔时间）设为3
对于以上的两个不同设置，我有三个问题，请大家不吝指教，谢谢了先！
一，每个用户是将脚本中的请求都发送到服务器后，即可认为一个iteration完成，而不管服务器有没有响应完成这些请求？还是每个用户不光要将请求发出去，还要等到服务器将这些请求响应完毕才算一个iteration的完成，才开始下一个iteration呢？
二，如果我加入了pacing时间，比如为3S，那么loadrunner在计算每秒交易数的平均值时，包不包括这个pacing时间呢？我个人感觉应该是不包括的
三，一般加入pacing值的主要目的是什么，什么情况下会对测试结果有较明显的影响？ 顶一个，关于第一个问题，是等到服务器响应后算一个iteration完成。
其他的我就不知道了。 1.一个iteration完成，说明所有请求都已经得到服务器的响应了。
2.试试就知道。我认为不会。
3.你喜欢加就加，如果设有运行持续时间，会对你的迭代次数完成有影响。
[ 本帖最后由 snnylip 于 2009-2-13 16:41 编辑 ] 谢谢上面朋友的解答，我自己做了一个试验，我觉得上面三个问题的答案应该如下：
问题一，待客户端收到服务器响应后，才算一个iteration完成，当然这是针对同步的处理系统，如果是异步的就不同，不过如果是异步的LR也管不了后台了，可以不用太关注，我当时测的就是异步情况，50个并发迭代5次，未设pacing值，异步的后台就和250个并发差不多了。
问题二，loadrunner在计算每秒交易数的平均值时，是不包括这个pacing时间的。
我用两个场景做了测试，只有pacing值不同，其他都相同，发现测得的每秒交易数是差不多的。
问题三，我觉得pacing值的大小对系统的压力影响也不同，肯定是as soon as 类型的压力最大，不给系统喘息的机会。
pacing的设置要与实际系统的处理情况结合，比如1小时内要完成600个交易，如果你不考虑峰值，用600/60/1=10Transaction/S,10笔交易每秒是一个平均的值，没考虑峰值的情况，这样平均来算，就是要系统一秒接一秒的持续完成10Transaction/S，此时设pacing就应该设为0，或者as soon as了
回复 1# 的帖子
理解了pacing就意思就能明白了pacing就是每次迭代之间加了个停顿时间而已 回复 4# yoyo0915
实践出真知
页:
[1]
