51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 3783|回复: 10
打印 上一主题 下一主题

[原创] loadrunner 场景中虚拟用户每秒增加多少合适

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2011-10-25 15:06:25 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
今天突然想到这个问题,以前都是随便设置比如10秒2个之类的,问下各位大神这个场景执行过程中递增到规定的用户数你们是怎么分配时间的
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2011-10-25 15:17:28 | 只看该作者
也想知道
设置m秒增加n用户,持续Tmin,然后再降,这样的场景,一般设计有没有常规的数据比例?
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2011-10-25 15:17:37 | 只看该作者
也想知道
设置m秒增加n用户,持续Tmin,然后再降,这样的场景,一般设计有没有常规的数据比例?
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2011-12-2 17:13:34 | 只看该作者
把这个贴子顶起来,我目前也被这个问题困扰着
如果加载太多用户,这脚本能不能跑得下,如果加载得太少了,又担心压力上不去,这性能测试真纠结啊
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2011-12-3 10:43:47 | 只看该作者
顶贴,求答案
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2011-12-9 15:32:00 | 只看该作者
怎么没高手来解答呢
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2014-10-16 09:54
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    7#
    发表于 2011-12-9 15:38:14 | 只看该作者
    1、根据项目实际需求
    2、如果压力不够,可以增加用户

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

    使用道具 举报

    该用户从未签到

    8#
    发表于 2011-12-12 15:30:05 | 只看该作者
    满足需求即可啊,比如用户需求要200个并发,你至少要满足在200个并发时性能没问题,并发280个性能降低也是可以吧
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2011-12-12 16:56:11 | 只看该作者
    首先,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部分脚本执行结果”的角度出发考虑楼主问题的,也许还有不少地方没有考虑到,望楼下继续补充。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

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

    使用道具 举报

    该用户从未签到

    11#
    发表于 2011-12-13 09:54:53 | 只看该作者
    我认为,一个用户量相对较少的范围内是可以的,多了就得考虑PV业务量
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-5-26 04:33 , Processed in 0.077542 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表