并发用户的数量根据什么来确定?

blue_flower

测试一个系统，要求可以允许20000人在线使用，现在要测试它的最大并发用户数。并发用户数和使用人数的关系怎么换算呢？查找过不少资料，都认为并发用户数取在线使用人数的5%~20%，到底是不是这样呢？我现在测试并发登陆，发现能过的并发用户数只有500人，那能说明系统的使用人数只有2500~10000人吗？

[ 本帖最后由 blue_flower 于 2008-6-12 13:18 编辑 ]

blue_flower

Wins，我觉得你说得很有道理，考虑的很全面。也正如你所说，具体情况具体分析。目前我的系统只是一个框架，只有登陆功能做出来了其他的还在设计当中，所以要想分析具体的业务还不具备条件，只能下一步了。当然非常感谢你提供建议和帮忙分析。

Wins

个人觉得应该确定一些业务模型，加载性能测试类型，通过监控系统模块中的每一个环节，包括前台、web server、中间件、数据库等监控，先做每一组件的配置调优，结合操作系统以及各服务器资源，通过前面的业务测试类型负载，得到每一环节的监控指标，做线性（横向及纵向）数据分析。前提是我们需要对硬件资源、不同服务器的各类服务、接口逻辑、编码程序都有一定深度的了解，常年软件领域得来的综合分析能力。
这基本是我能说得了。最好具体情况具体分析。

blue_flower

大家多多交流，知识是累积出来的！

森林一木

楼上的不错，加qq聊聊啊，多向你请教请教。

如果说考虑后台，确实很多时候性能测试要考虑的很多，比如监控平台的，数据库日志的、程序代码的，等等。但具体问题分析起来并非易事。性能测试做起来容易，真正的发现问题、定位问题并解决它却是难度非常大。

Wins

哈哈，说得都没错。但是太高深。那是从业务角度看的问题。当我们一个劲在评估平均事务处理能力，平均消耗时间、吞吐量的时候，实际上都是以黑盒的方式去看“世界”。这也是正常的思维习惯。换个角度，这是容量测试的一个范畴。我也有一个“取款机”模型可以摆显，但是有什么用？性能测试不是一朝一夕的。
只是一直都很奇怪，为什么没有人从后台系统地去看这个问题。

本人专攻性能测试，如有兴趣，可以找我切磋。

blue_flower

感谢你一直的支持！！

blue_flower

恩，我也相信我遇到的问题具有普遍性。可我还没有经验只有向前辈请教来学习。打广告也罢，你提出好的观点就不错。如果有不错的书我会看的。
1. 系统注册用户数！=在线用户数
2. 在线用户数！=并发用户数
这个我是知道的。
如果有好书可以介绍一下！谢谢！

[ 本帖最后由 blue_flower 于 2008-6-23 18:07 编辑 ]

森林一木

打广告没错，可得看时候。回答问题说点实际的，书好自然有人看的。

[ 本帖最后由 森林一木 于 2008-6-23 11:03 编辑 ]

sunshinelius

楼主碰到的问题在软件性能测试规划中具有相当的普遍性。
在性能测试的入门初级阶段，关注点往往在技术上，比如架构分析，loadrunner脚本开发等等；但如何把性能测试真正地做好，以最少的重复工作量找出尽可能多的性能瓶颈，并且最终提交一份量化的逻辑清晰有说服力的性能测试报告，这更多依赖于一个高效高质量的性能测试过程模型。
建议楼主和其他朋友可考虑参考GAME过程模型：
一.G(Goal):你的性能测试目标是什么？是定位瓶颈？还是验证新增的模块对原有系统有无性能影响？还是寻找一个最优的硬件配置？还是保证系统在高负荷下有良好的健壮性？等等。不同的目标应该选择不同的性能测试策略
二.A(Analysis) ：要分析。1. 用户有几种类型？每种类型的用户的典型业务场景是什么？以怎样的概率分配？2. 系统的架构如何？有几个节点组成？用户的业务压力会经过几个系统节点？
三.M（Metric）度量：把analysis分析结果转换成loadrunner的度量。比如业务场景转化成controller场景，用户典型操作转化成VU脚本，业务配比转化成controlelr百分比模式等等
四. E(Execution):  开发，调试，运行脚本和场景
五. A(Adjust)调整：调优和修改程序
有两点注意：
1. 上面的每一步都应该是一个里程碑，如果这一步不能得出明确答案，就不能向下一步转移。
2. 和性能测试工具相关的过程（脚本开发，场景监控等等）只有第四步Execution，因此工具只是性能测试规划中一个实现手段而已，对于性能测试的高级人员来说，应该把关注点分配到其他过程步骤中去
以上GAME模型在本人的《性能测试从零开始-loadrunner入门》一书中有详细的介绍和案例分析。呵呵。在这里为自己做个广告。
好，回到楼主的问题来。楼主应该是在analysis阶段遇到的问题。在解决这个问题之前，楼主应该澄清几个概念：
1. 系统注册用户数！=在线用户数
2. 在线用户数！=并发用户数
至于几个数字是多少配比关系，可以根据你的业务模型来决定。

blue_flower

非常感谢你的耐心指导！我明白你说的意思了，我将按照你的方法测试看看。“性能测试不是简简单单的靠一两次测试就找到问题的，得多次测试，进行比较分析定位。”你说得很有道理！再次谢谢你的解答！

森林一木

原帖由 blue_flower 于 2008-6-20 14:43 发表
谢谢！我也不知道请求数是指什么，是指事务吗？
还有这个：“3、B/A=用户数，这里得出在一段时间内，模拟出的在线用户数”，这个一段时间是说（比如刚才运行了20分钟）20分钟内的在线用户数吗？还是说用户数需要除以 ...

不客气，请求数就是里面的点击数：hit，这个表示了在一个业务流程中的请求数。举个例子，一个用户，不设置持续时间，运行场景，完成后的hit数就是该业务流程的请求数，这样就可以得出A了。然后根据经验值，并发数取测试要求的15%左右做并发，并根据需要设计持续时间，比如OA系统中的考勤系统，一般可能的使用高峰在8：40到9：15左右（根据实际情况来），那么持续时间可设计为35分钟，运行完成后再统计总的hits数，即得到B，这样就可以用B/A，得出一共完成了多少个考勤事件了。那么一般情况下，每个员工都是进行一次考勤操作，这样就可以知道在35分钟内，支持多少用户了，如果跟你的要求有差距，再慢慢调整吧。多了，系统没有问题，那表示性能不错，少了，再增加并发数，争取达到要求。还是强调一下，性能测试不是简简单单的靠一两次测试就找到问题的，得多次测试，进行比较分析定位。
仅供参考！

[ 本帖最后由 森林一木 于 2008-6-20 15:36 编辑 ]

blue_flower

谢谢！我也不知道请求数是指什么，是指事务吗？
还有这个：“3、B/A=用户数，这里得出在一段时间内，模拟出的在线用户数”，这个一段时间是说（比如刚才运行了20分钟）20分钟内的在线用户数吗？还是说用户数需要除以20分钟才能得到？
希望你可以再说明一下啊。非常感谢你！

maihua258

请问森林一木：
    恕我无知，请求数该怎样看呢？谢谢了

森林一木

确定并发数方法：
首先申明，个人经验，仅供参考
1、录制一个脚本，运行一次，看有多少个请求，假设请求数为A；
2、按经验值，取15%左右，持续运行一段时间，比如20分钟，看共有多少个请求，假设请求数为B；
3、B/A=用户数，这里得出在一段时间内，模拟出的在线用户数，如果这个数据与你的20000有差距，则再调整并发数；
4、性能测试不是一次就能做好的，个人经验是多次测试求一个平均值，就像喝红酒一样，慢慢品才有收获，呵呵。

blue_flower

谢谢Wins！原来是web server 的设置决定的呀，那我让开发人员看看它的设置。

Wins

并发数是在某一特定时段内同时连接的数量。
当请求需要通过web server进行请求并需要web server返回处理结果。这里的并发数是相对web server而言的，也就是说，需要关注的是web server 连接池最大能处理的连接数量，不管tomcat,apache，weblogic等都好，都是一样的道理，需要调整的是这里的参数。至于DB，那是web server 跟它之间的通信了。
简言之，连接池的数量、作用时效决定并发数。

blue_flower

原帖由 adiao 于 2008-6-16 10:17 发表
JVM的问题？
我上次测试系统用户超过300就出错，听开发讲my sql 的JVM最大只能设置为多少来着，不能再高了。

反正我现在测试最多就过500，550都不行。不管怎样测试，都500多一点而已，可能和它有关吧

blue_flower

原帖由 joetree 于 2008-6-16 10:13 发表
30%的 OA...还有，上线用的服务器环境和你现在的服务器环境是一样的吗？
不一样的话，需要进行并发数调整的
如果一样。。。。。那就使劲吧，说实在的，500并发到10秒，也不是很坏的结果了

应该不一样吧,现在是局域网啊，放到外网会更慢的。现在在内部要求要2秒左右呢，但是100用户并发就要2秒了。所以让开发的再设置好了。

adiao

JVM的问题？
我上次测试系统用户超过300就出错，听开发讲my sql 的JVM最大只能设置为多少来着，不能再高了。