51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 9913|回复: 19
打印 上一主题 下一主题

[求助] 请问依据什么估算应该产生多少并发数?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-5-20 17:08:14 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
通常我们会根据用户的性能需求来估算,但用户一般会说这个系统使用者数量是多少,什么时间是高峰段,甚至可以告诉你半小时内可能有多少个人访问系统,但用户不会跟你说并发数会是多少。通过这些如何估算我应该产生多少并发?50人正在同时使用的一个系统或许从来都没有发生过并发。

另外,一直没搞清loadrunner的并发概念,因为LR做不到同时产生请求,比如50个并发也有可能在1s内完成,也有可能是2s。这种状况如何与实际性能需求相对应?

[ 本帖最后由 kamatyo 于 2010-5-20 17:10 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    开心
    2015-11-18 22:53
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2010-5-21 11:14:53 | 只看该作者
    mark一下
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2010-5-21 11:36:59 | 只看该作者
    我也想知道,等待高手回答~~~~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2010-5-21 11:59:56 | 只看该作者
    可根据pv估算广义并发人数
    可根据在线人数估算狭义的并发人数
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-5-27 22:16:43 | 只看该作者
    建议参考《软件评测师教程》第8章的内容,对于软件需求分析的讲解比较系统。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-11-18 22:53
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    6#
    发表于 2010-5-28 06:17:56 | 只看该作者
    还得捞本书过来看啊。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-5-28 08:57:43 | 只看该作者
    顶起 我也很想知道
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2010-5-28 16:53:54 | 只看该作者
    我也提个问题:
    一个系统假设有1000用户,高峰访问4小时,能够产生200000笔交易。
    我们能够得出高峰访问每分钟的tps=14笔/秒,假设一个vuser运行一次需要10秒,那么600用户运行1小时(负载)产生的数据量216000,满足了这个交易量。

    1.那么这个并发用户数该如何计算呢?
    2.在1000用户范围内,如果应用能够按照14笔/秒的tps处理请求,是否可以断定系统可以支持并发用户的操作呢?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2010-5-28 17:12:43 | 只看该作者
    建议lz和用户进一步明确需求
    弄清楚用户想做性能测试的真正目的。
    反问下,
    你要得到并发数干嘛?我理解是得到最佳并发用户数
    可以确定响应时间,然后来确定当前资源下最佳并发用户数,或者最大并发数
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    10#
    发表于 2010-5-29 19:49:59 | 只看该作者
    主要得看实际业务情况,没有什么好的公式可以提供给你直接使用
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2010-5-31 16:24:24 | 只看该作者
    10%,别太关注虚拟用户数,多关心关心TPS。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
     楼主| 发表于 2010-6-9 16:33:47 | 只看该作者

    回复 9# 的帖子

    但是在确定响应时间的情况下,工具得到的数据是在此响应时间要求下,并发数是多少。而用户想知道此响应时间下可供我多少个用户去使用,或者高峰期用户在线至多为多少。仍然存在工具得到并发数和用户数量之间的转换问题。

    不吝赐教
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2010-6-9 17:10:59 | 只看该作者
    原帖由 dennyqiang 于 2010-5-31 16:24 发表
    10%,别太关注虚拟用户数,多关心关心TPS。

    同意多关注TPS,而不要过多关注前端模拟的并发用户数。但10%还是比较笼统的一个数,并不适用于所有项目的并发用户数估算。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2010-6-9 18:25:33 | 只看该作者
    原帖由 亚瑟王 于 2010-5-28 16:53 发表
    我也提个问题:
    一个系统假设有1000用户,高峰访问4小时,能够产生200000笔交易。
    我们能够得出高峰访问每分钟的tps=14笔/秒,假设一个vuser运行一次需要10秒,那么600用户运行1小时(负载)产生的数据量216000,满 ...

    可以这样说,高峰时段的TPS=14笔/秒,如果用户平均做完一笔交易需要10秒,则600个用户1小时内就可以做完,如果持续4小时的高峰时间,则150人并发即可完成。你前段发起的时候就可以设置150并发。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2010-6-10 10:58:35 | 只看该作者

    回复 12# 的帖子

    可以做以下几点:
    1 保证在较小用户下,例如50并发,不能有失败,或者失败率<1%
    2 知道响应时间的限制后,可以通过实验的方法。
    例如,某个http请求要求avg responst time <200ms.
    先给100个并发,发现是90th 的rps是125ms。
    给200给vusers,发现90th的rps是220ms。
    可以通过rps\vuser数的大概线性关系,确定下一次使用的并发数,例如:170个,最后发现满足需求。170个并发就是你想要的。可能在同时线数大概是3400个(5%-10%)
    3 逐步加压。res time在开始是增加的,然后某个点是上升的(最佳并发数)。最后到达一个点是突然下降的(这个点,精确说是之前对应的并发数是最大并发数)
    吞吐量tps是逐渐增加,然后饱和一段时间,最后下降。
    可以使用最佳并发数去跑24h×3,看系统的稳定性。
    不对的地方,大家多指正

    [ 本帖最后由 xavier_007 于 2010-6-11 15:37 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2010-6-10 11:01:07 | 只看该作者

    回复 14# 的帖子

    8错
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2010-6-11 11:07:36 | 只看该作者
    其实感觉平时关注的并发数主要还是两个,一个是最佳,一个是最大。不过概念理解上和楼上有点出入,我觉得最佳的并发用户数是系统tps停止上升,并且响应时间由平稳转向剧增的时候临界点使用的并发数,超过这个点,再增加用户数就只能等待,并且系统还要提供一些资源来维护这些等待;而最大并发用户数,则是出现第一个error(因等待超时而退出)的时候使用的并发数。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2010-6-11 13:33:22 | 只看该作者

    回复 14# 的帖子

    感谢版主的回答

    我有几个疑问:
    1.高峰TPS=14笔/秒,1个vuser运行一次10秒,600用户(非并发用户数)运行1小时可以产生的数据量满足200000,但是这600用户不是并发用户,那么600/4=150,这个150人可以理解为150并发用户数吗?

    2.假设150并发用户,假设运行了4小时后,在其它指标视为良好情况下:150并发TPS<高峰14笔/秒TPS,是否可以理解为,系统可以支持更大的并发用户数,直至出现性能瓶颈?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2010-6-11 15:27:54 | 只看该作者
    600个用户发起交易持续1小时可以完成高峰时段的数据量,但这600个用户完成一笔交易需要10秒,所以从一个瞬间切片上来看服务器端的并发肯定不到600。如果使用lr测试相当于设置脚本的pacing时间为10秒,这样的场景更偏重于实际业务场景,而不是测试服务器端的并发和最大处理能力。
    服务器并发数应该看服务器端开放了多少连接数,瞬间的最大并发数就是开放的连接数。如果系统处理交易很快,那我们前端设置很大的并发都没问题。我觉得我们更应该关注服务器的最大处理能力,增大并发用户数直至服务端的TPS不再上升,如果这时的TPS没有达到系统的预期那就是系统性能有问题,或者当前的资源只能到达这种处理能力。
    个人理解
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2014-1-7 14:38:08 | 只看该作者
    mark
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-7 22:42 , Processed in 0.076966 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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