关于并发数测试目的的一点困惑
测试一个网站的首页1、设定100个用户，并设置里集合点，运行一分钟。这样相当于100个用户“同时”访问首页，并且访问完一次后，下一次也等100个集合好后再同时请求，持续一分钟。这样每秒只对服务器产生300左右的请求，服务器CPU也不高；
2、只有一个用户，运行一分钟。相当于这个用户在这一分钟内不停地想服务器发送请求。最后平均每秒产生800左右的请求，CPU也很高。
感觉并发用户所造成的压力并没有一个用户不停的请求大。那么，进行并发测试的目的是什么呢？
1、为了实际验证当系统有N个并发的时候，是否每个请求都能响应？
2、几个用户连续发送请求的情况并不多见，但是能产生很大的压力，方便测试系统的最大吞吐量等指标？
比如100个用户设置集合点，登陆一个网站，因为集合点的等待，下次运行要间隔1秒，这样一分钟内只能并发60次；
另一种情况，10个用户不设置集合点，那这10个用户在这一分钟内各自反复登陆网站，理论上并发数只有10，但是却能每秒并发10次，这样产生的压力就比前者大。
实际情况中大家根据自己的需要，都是怎么处理的呢？ 我理解的性能不止是压力大就可以了。
不同应用的并发处理是设置并发集合点的一个意图。这样模拟出不同用户在极短时间内产生的并发，如果这种并发处理有问题，系统可能响应慢，也可能死锁，也可能产生业务错误，甚至可能导致服务宕掉。有可能你的系统不停的连续登录都不产生问题，恰恰就两个人同时一个login一个logout系统就完蛋了。
所以性能测试是要设计的，方案设计更重要些。 性能测试更重要的是模拟真实用户的操作
真实的用户不可能1个用户在1分钟内不停地向服务器发送请求
设置集合点在我经历的测试过程中也不经常用到~ 10个用户不设置集合点，那这10个用户在这一分钟内各自反复登陆网站，理论上并发数只有10，但是却能每秒并发10次。你所说的这10次并发是没有任何保证的。 为什么没有保证？假设“并发”是指一个很短的时间段内同时到达服务器的请求，这样当我有10个用户，一个用户一次事务的响应时间只有0.01秒，就是说这每秒内他可以产生100次的访问，其它九个用户也每秒产生100次访问的时候，那这秒钟的每个0.01秒呢，不就是10个用户“并发”吗？一秒内一共有100次这样的行为。
[ 本帖最后由 never115 于 2008-10-16 15:04 编辑 ] 性能测试重要的还是关注实际运用的场景，我同意hmilyjch 的观点
对于never115关于并发的计算，我觉得可能还是欠妥，如果没有设置集合点，仅仅只是靠对每秒事务数的计算，数据来得不是很可靠 对此我一直也比较疑惑
页:
[1]
