51Testing软件测试论坛

标题: 请问依据什么估算应该产生多少并发数？ [打印本页]

作者: kamatyo 时间: 2010-5-20 17:08
标题: 请问依据什么估算应该产生多少并发数？
通常我们会根据用户的性能需求来估算，但用户一般会说这个系统使用者数量是多少，什么时间是高峰段，甚至可以告诉你半小时内可能有多少个人访问系统，但用户不会跟你说并发数会是多少。通过这些如何估算我应该产生多少并发？50人正在同时使用的一个系统或许从来都没有发生过并发。

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

[ 本帖最后由 kamatyo 于 2010-5-20 17:10 编辑 ]

作者: yings_9371 时间: 2010-5-21 11:14
mark一下

作者: shenyy722 时间: 2010-5-21 11:36
我也想知道，等待高手回答～～～～

作者: redforce 时间: 2010-5-21 11:59
可根据pv估算广义并发人数
可根据在线人数估算狭义的并发人数

作者: salt555 时间: 2010-5-27 22:16
建议参考《软件评测师教程》第8章的内容，对于软件需求分析的讲解比较系统。

作者: yings_9371 时间: 2010-5-28 06:17
还得捞本书过来看啊。

作者: kratexi 时间: 2010-5-28 08:57
顶起我也很想知道

作者: 亚瑟王 时间: 2010-5-28 16:53
我也提个问题：
一个系统假设有1000用户，高峰访问4小时，能够产生200000笔交易。
我们能够得出高峰访问每分钟的tps=14笔/秒，假设一个vuser运行一次需要10秒，那么600用户运行1小时（负载）产生的数据量216000，满足了这个交易量。

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

作者: xavier_007 时间: 2010-5-28 17:12
建议lz和用户进一步明确需求
弄清楚用户想做性能测试的真正目的。
反问下，
你要得到并发数干嘛？我理解是得到最佳并发用户数
可以确定响应时间，然后来确定当前资源下最佳并发用户数，或者最大并发数

作者: msnshow 时间: 2010-5-29 19:49
主要得看实际业务情况，没有什么好的公式可以提供给你直接使用

作者: dennyqiang 时间: 2010-5-31 16:24
10%，别太关注虚拟用户数，多关心关心TPS。

作者: kamatyo 时间: 2010-6-9 16:33
标题: 回复 9# 的帖子
但是在确定响应时间的情况下，工具得到的数据是在此响应时间要求下，并发数是多少。而用户想知道此响应时间下可供我多少个用户去使用，或者高峰期用户在线至多为多少。仍然存在工具得到并发数和用户数量之间的转换问题。

不吝赐教

作者: dionysus 时间: 2010-6-9 17:10

原帖由 dennyqiang 于 2010-5-31 16:24 发表
10%，别太关注虚拟用户数，多关心关心TPS。

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

作者: dionysus 时间: 2010-6-9 18:25

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

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

作者: xavier_007 时间: 2010-6-10 10:58
标题: 回复 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 编辑 ]

作者: xavier_007 时间: 2010-6-10 11:01
标题: 回复 14# 的帖子
8错

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

作者: 亚瑟王 时间: 2010-6-11 13:33
标题: 回复 14# 的帖子
感谢版主的回答

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

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

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

作者: yqs01221 时间: 2014-1-7 14:38
mark

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