51Testing软件测试论坛

标题: loadrunner 场景中虚拟用户每秒增加多少合适 [打印本页]

作者: maxhoo8003 时间: 2011-10-25 15:06
标题: loadrunner 场景中虚拟用户每秒增加多少合适
今天突然想到这个问题，以前都是随便设置比如10秒2个之类的，问下各位大神这个场景执行过程中递增到规定的用户数你们是怎么分配时间的

作者: yunonly 时间: 2011-10-25 15:17
也想知道

设置m秒增加n用户，持续Tmin，然后再降，这样的场景，一般设计有没有常规的数据比例？

作者: yunonly 时间: 2011-10-25 15:17
也想知道

设置m秒增加n用户，持续Tmin，然后再降，这样的场景，一般设计有没有常规的数据比例？

作者: 善待自己 时间: 2011-12-2 17:13
把这个贴子顶起来，我目前也被这个问题困扰着
如果加载太多用户，这脚本能不能跑得下，如果加载得太少了，又担心压力上不去，这性能测试真纠结啊

作者: ymwang119 时间: 2011-12-3 10:43

顶贴，求答案

作者: 善待自己 时间: 2011-12-9 15:32
怎么没高手来解答呢

作者: mymagic 时间: 2011-12-9 15:38
1、根据项目实际需求
2、如果压力不够，可以增加用户

类似于百度与51testing 两个网站做性能测试的话，用户量肯定不同。
看实际需求吧。

作者: htt84369045 时间: 2011-12-12 15:30
满足需求即可啊，比如用户需求要200个并发，你至少要满足在200个并发时性能没问题，并发280个性能降低也是可以吧

作者: mr.bee 时间: 2011-12-12 16:56
首先，vuser初始化本身的配置不应该影响到测试场景的结果，至少不能起到太大的影响
然后，action部分脚本执行效率的问题，vuser初始化的速度的问题，怎么说呢，希望你懂的。。。就是。。。。比如你需要模拟10个用户在线，执行action部分只需1秒，而你配置一秒加载一个vuser，那结果里面显示的自然就是最高1vuser了
有没有达到你要模拟的效果呢？也许有的人会觉得没有，但是我觉得这是不一定的
因为“10个用户在线”本身对业务操作的模拟场景这个需求本身就很模糊，但是，感觉上吧，大家都这么说，好像也就这么回事这么做了。
我觉得，确定初始化vuser的速度，你至少需要了解这些信息：
1.你测试的这个业务模块在它的业务峰值区间中，平均在线的用户是多少，峰值在线用户又是平均的多少；
2.你测试的这个业务模块在用户业务场景中，峰值是什么周期出现的？日度？周度？月度？交易量是多少？
假定你已经很确定第一个问题，需要模拟的A业务，峰值区间里面，平均在线用户是10个，峰值是平均的2倍，你测试的这个业务的业务量峰值是以周度的形式出现的，所以你的一个测试场景最好保守一点，去模拟一周的业务量。

我不敢说模拟10个用户就配置10个vuser是对的，因为vuser的本质是执行脚本线程嘛，不能和你要模拟的用户划等号，这里先不考虑这个问题，详细请在lr版里面看看之前的问题，假定你了解到一周的业务量是100笔交易，那就是脚本迭代10次。

现在要做的事就剩下一件了：
让你的初始化中，vuser尽快慢，慢到最后一个vuser初始化成功的时候，第一个初始化成功的vuser还没有完成第一次迭代。
你要达到这个目标需要先进行基准测试，，，然后，，，，其实我想说真的不要太纠结这个问题，要是初始化都能影响action部分的结果好坏，，，为什么不先解决初始化里面的业务请求的性能问题？

我是从“尽量避免初始化操作引发action部分脚本执行结果”的角度出发考虑楼主问题的，也许还有不少地方没有考虑到，望楼下继续补充。

作者: 夏日摸摸茶 时间: 2011-12-13 09:33
我觉得没啥规律，看自己的业务
你测用户量小的平台，肯定每次增加的用户较少，当你测试新浪百度这样的大型网站时，就不能用相同的用户增量去衡量了。所以还是看自己的实际用户量来估算一下，在多长的时间内，让用户增到最大在线用户数量。

此外，重要的不是在递增多少个用户上，而是在压力不断增加的同时，关注吞吐量的变化，在用户在多少并发量时，服务器吞吐量趋于稳定。这个才是关键。

作者: mr.bee 时间: 2011-12-13 09:54
我认为，一个用户量相对较少的范围内是可以的，多了就得考虑PV业务量

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