这个场景怎么设置

1019

开发同事就告诉我要测试1万个用户并发，不管测哪个功能，我就选择了最简单的登录，考虑到数据库里的用户较多，并且用户还有约束条件才可以登录的，太麻烦了，我就选了20个用户作为登录的参数，这种情况如何能测出1万用户的并发效果呢，一下是一个用户运行的结果：
Maximum Running Vusers:                 1
Total Throughput (bytes):                  861,765
Average Throughput (bytes/second):         35,907
Total Hits:                             75
Average Hits per Second:                  3.125

Transaction Name        SLA Status        Minimum        Average        Maximum        Std. Deviation        90 Percent        Pass        Fail        Stop
Action_Transaction                          11.729        11.729        11.729        0.001                 11.729                 1        0        0
login                                   11.714        11.714        11.714        0.001                 11.714                 1        0        0
vuser_end_Transaction                 0.297        0.297        0.297        0                 0.297                 1        0        0
vuser_init_Transaction                 10.061        10.061        10.061        0.001                 10.061                 1        0        0

HTTP Responses        Total        Per second
HTTP_200                70        2.917
HTTP_302          5        0.208

1019

现在还不知道怎么设置这个场景是最有效的，我是这样算的，一个USER登录完成所花的时间是6S，一小时就是600次登录，20个VUSER在1小时内如果完成12000条就可以了。以每6秒增加一个VUSER，持续运行1小时，这样我就测试1小时内应该可以完成12000条登录业务，这样可以实现并发的效果吗？并且不知为什么结果登录事务只有1K多条。

htlg

想问下楼主  你要测的服务器 架构是怎么样的？ 前面一台负载机器 后面跟几台前台呢 和后台呢？

你可以反问 你开发同事  他怎么可以证明 这样的结构能承受10000用户的并发  你可以先测试出 单台服务器 能承受最大并发  
还有 你要计算 页面大小  网络带宽  来考虑 是否 1W 用户是否能同时在线？？

samueloyang

就算循环登陆   在那个脚本中写入循环脚本  运行设置里面设置循环  这样的双重循环应该是可以的吧

TIB

试试：
Unique
Each iteration
Continue in a cyclic manner

qiguojie

实际上，10000个并发用户也是可以实现的，你找10个负载机就应该能加到10000.然后集合跑脚本即可，你们的登录服务和服务器没有设置负载均衡的话，肯定不行。

如果条件不允许，可以通过减少思考时间，使用固定的虚拟用户数也能增加到你想要的压力。

1019

集合点是在脚本里设置的，我问的是参数化的用户只有几十个，怎么模拟出测试需求所要的一万个并发用户
另外还要测试同事在线1万个用户，也就是说用户登录后不要退出，这样用户名肯定是不够的，需要登录循环，那么在参数化里设置什么样的取值方式呢？

[ 本帖最后由 1019 于 2010-4-14 14:50 编辑 ]

TIB

如果要测试真正意义上的并发，应该在登录脚本的事务之前设置一个集合点