请问依据什么估算应该产生多少并发数？
通常我们会根据用户的性能需求来估算，但用户一般会说这个系统使用者数量是多少，什么时间是高峰段，甚至可以告诉你半小时内可能有多少个人访问系统，但用户不会跟你说并发数会是多少。通过这些如何估算我应该产生多少并发？50人正在同时使用的一个系统或许从来都没有发生过并发。另外，一直没搞清loadrunner的并发概念，因为LR做不到同时产生请求，比如50个并发也有可能在1s内完成，也有可能是2s。这种状况如何与实际性能需求相对应？
[ 本帖最后由 kamatyo 于 2010-5-20 17:10 编辑 ] mark一下 我也想知道，等待高手回答～～～～ 可根据pv估算广义并发人数
可根据在线人数估算狭义的并发人数 建议参考《软件评测师教程》第8章的内容，对于软件需求分析的讲解比较系统。 还得捞本书过来看啊。 顶起 我也很想知道 我也提个问题：
一个系统假设有1000用户，高峰访问4小时，能够产生200000笔交易。
我们能够得出高峰访问每分钟的tps=14笔/秒，假设一个vuser运行一次需要10秒，那么600用户运行1小时（负载）产生的数据量216000，满足了这个交易量。
1.那么这个并发用户数该如何计算呢？
2.在1000用户范围内，如果应用能够按照14笔/秒的tps处理请求，是否可以断定系统可以支持并发用户的操作呢？ 建议lz和用户进一步明确需求
弄清楚用户想做性能测试的真正目的。
反问下，
你要得到并发数干嘛？我理解是得到最佳并发用户数
可以确定响应时间，然后来确定当前资源下最佳并发用户数，或者最大并发数 主要得看实际业务情况，没有什么好的公式可以提供给你直接使用 10%，别太关注虚拟用户数，多关心关心TPS。
回复 9# 的帖子
但是在确定响应时间的情况下，工具得到的数据是在此响应时间要求下，并发数是多少。而用户想知道此响应时间下可供我多少个用户去使用，或者高峰期用户在线至多为多少。仍然存在工具得到并发数和用户数量之间的转换问题。不吝赐教 原帖由 dennyqiang 于 2010-5-31 16:24 发表 http://bbs.51testing.com/images/common/back.gif
10%，别太关注虚拟用户数，多关心关心TPS。
同意多关注TPS，而不要过多关注前端模拟的并发用户数。但10%还是比较笼统的一个数，并不适用于所有项目的并发用户数估算。 原帖由 亚瑟王 于 2010-5-28 16:53 发表 http://bbs.51testing.com/images/common/back.gif
我也提个问题：
一个系统假设有1000用户，高峰访问4小时，能够产生200000笔交易。
我们能够得出高峰访问每分钟的tps=14笔/秒，假设一个vuser运行一次需要10秒，那么600用户运行1小时（负载）产生的数据量216000，满 ...
可以这样说，高峰时段的TPS=14笔/秒，如果用户平均做完一笔交易需要10秒，则600个用户1小时内就可以做完，如果持续4小时的高峰时间，则150人并发即可完成。你前段发起的时候就可以设置150并发。
回复 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 编辑 ]
回复 14# 的帖子
8错 其实感觉平时关注的并发数主要还是两个，一个是最佳，一个是最大。不过概念理解上和楼上有点出入，我觉得最佳的并发用户数是系统tps停止上升，并且响应时间由平稳转向剧增的时候临界点使用的并发数，超过这个点，再增加用户数就只能等待，并且系统还要提供一些资源来维护这些等待；而最大并发用户数，则是出现第一个error（因等待超时而退出）的时候使用的并发数。回复 14# 的帖子
感谢版主的回答我有几个疑问：
1.高峰TPS=14笔/秒，1个vuser运行一次10秒，600用户（非并发用户数）运行1小时可以产生的数据量满足200000，但是这600用户不是并发用户，那么600/4=150，这个150人可以理解为150并发用户数吗？
2.假设150并发用户，假设运行了4小时后，在其它指标视为良好情况下：150并发TPS<高峰14笔/秒TPS，是否可以理解为，系统可以支持更大的并发用户数，直至出现性能瓶颈？ 600个用户发起交易持续1小时可以完成高峰时段的数据量，但这600个用户完成一笔交易需要10秒，所以从一个瞬间切片上来看服务器端的并发肯定不到600。如果使用lr测试相当于设置脚本的pacing时间为10秒，这样的场景更偏重于实际业务场景，而不是测试服务器端的并发和最大处理能力。
服务器并发数应该看服务器端开放了多少连接数，瞬间的最大并发数就是开放的连接数。如果系统处理交易很快，那我们前端设置很大的并发都没问题。我觉得我们更应该关注服务器的最大处理能力，增大并发用户数直至服务端的TPS不再上升，如果这时的TPS没有达到系统的预期那就是系统性能有问题，或者当前的资源只能到达这种处理能力。
个人理解:) mark
页:
[1]
