浏览 14069 次
锁定老帖子 主题:请教:压力测试如何换算并发用户数
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-01-03
一个企业内部的OA审批系统,大约3万个注册用户,锋值大约2万个在线用户,现在要做压力测试,要开多少个并发连接进行压力测试,才能模拟2万个再线用户?我知道不同使用情况,在线用户和并发连接并没有直接的换算关系,但我对这一点概念也没有,所以很想了解了解你们一般是怎么做的 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-01-03
一般会看每秒的事务数,能达到多少.
|
|
返回顶楼 | |
发表时间:2008-01-03
web系统,在线不等于并发,这个数字应该从需求分析得到~
你的系统不只有一个功能,所以,完整的压力测试至少有单场景、混合场景的压力(极限)测试、性能测试、稳定性测试......场景怎么来?看用户需求:例如用户预计一个月大概1000个单据,每个单据4个审批节点,用户没有特别的审批时间习惯,可看作这些审批工作在每周工作时间是平均分布的,那么可以近似估算单场景的峰值=2倍的均值 压力测试的环境,也有比较严格的要求,理想情况下,应该和生产环境是完全一致的配置,一般也可略小于生产环境。应用服务器和数据库服务器分开,这样才能测出瓶颈并进行调整。 建议你看看下面这本书: 软件性能测试过程详解与案例剖析 [专著]/段念 编著 |
|
返回顶楼 | |
发表时间:2008-01-04
balaschen 写道 有做过压力测试的哥们来说说,做压力测试如何计算并发用户数,我的应用场景如下:
一个企业内部的OA审批系统,大约3万个注册用户,锋值大约2万个在线用户,现在要做压力测试,要开多少个并发连接进行压力测试,才能模拟2万个再线用户?我知道不同使用情况,在线用户和并发连接并没有直接的换算关系,但我对这一点概念也没有,所以很想了解了解你们一般是怎么做的 如果要近可能的精确,那就用loadrunner或者其他的性能测试工具模拟出2万个虚拟用户好了,多找几台机器加压 |
|
返回顶楼 | |
发表时间:2008-01-07
多谢楼上几位的建议
|
|
返回顶楼 | |
发表时间:2008-01-07
其实本来所谓"在线用户"也是个模糊的概念:
如何确定一个用户是否在线?从技术实现来看,就是一个用户的session是否保持有效,这个直接跟session实效时间设置有关,一般为20-30分钟.这个就有很大弹性了,一个用户10分钟访问一次页面,跟一个忙碌的用户,每分钟访问20次都属于一个"在线用户". 所以这个只是一个模糊的概念,必须要设置一个典型标准用户操作的场景来衡量,而如何设置它则是你们应做的,每个应用不同. |
|
返回顶楼 | |
发表时间:2008-03-01
balaschen 写道 有做过压力测试的哥们来说说,做压力测试如何计算并发用户数,我的应用场景如下:
一个企业内部的OA审批系统,大约3万个注册用户,锋值大约2万个在线用户,现在要做压力测试,要开多少个并发连接进行压力测试,才能模拟2万个再线用户?我知道不同使用情况,在线用户和并发连接并没有直接的换算关系,但我对这一点概念也没有,所以很想了解了解你们一般是怎么做的 您需要先估算一个数字,就是系统的用户的操作频率是多少?假如系统的用户的操作频率是每10秒操作一次. 峰值约为20000个在线用户的话,那就是说理论上每秒有2000个操作. 假设2000个操作中每个操作的单独运行时间(除去网络传输及其它相关因素也就是从系统接收到用户的操作并由系统返回操作响应的时间,这个时候有一个问题,就是系统返回操作响应有两个时间,一个是系统开始响应用户操作时间,一个是系统响应完成时间,在WEB方面可以简单的描述成系统输出用户操作返回结果所需要的时间.按照多数的说法,就是系统完全输出用户操作返回结果的时间为一个元操作所需要的时间. 应用二八原则,就是说在0.2秒内需要响应2000个操作中的80%,也就是1600个操作.结果也就是说系统需要响应8000个操作并输出结果.假设平均结果输出为50Kb,则系统需要的最大输出为8000*50Kb/80%=500,000Kb约为489Mb的输出. 通过压力测试工具(如loadrunner)建立虚拟用户并执行,然后观察系统输出,当观察到虚拟用户数增加到某个值之后,此时模拟用户的数目约为这个系统测试时需要的并发用户数 |
|
返回顶楼 | |
发表时间:2008-11-27
我觉得做压力测试首先要搞清楚测试的target,我一般做一个stress test第一个想的出来的结论就是系统的瓶颈在什么地方,是在应用服务器呢还是在数据库IO性能呢还是在建立连接消耗呢还是在java代码问题上,而不应该简单的用一个模拟的线程数来掩盖短处,有时候可能系统的确能满足1000用户同时在线plus200请求的并发,但或许这个时候数据库io已经很吃紧了,再加上个10并发就能挂掉,这样的情况下谁能保证哪天不会down掉,挂掉还好只要reboot就行,关键是到那个时候你在思考瓶颈在哪是不是稍微有点晚?
JMeter支持对AS和对DB的测试,不知道有没有朋友做过系统瓶颈侦测之类的活?拿出来分享一下 |
|
返回顶楼 | |