引用:
原帖由 blue_flower 于 2008-4-14 13:25 发表 
先谢谢lijiepig的回答,谢谢
你说我给的资料太少了,我再补充一点。是这样的:系统运行了一段时间后,大概1小时左右,执行测试时"所有事务都失败”了,以前能通过的事务也失败了。我主要是测并发用户,场景设置是: ...
你既然是【运行直到结束】,那【迭代1次】的设置就无效了,会无穷迭代下去,因此随着你的用户数不断增加,相当于每秒的请求数越来越高,高到一定程度系统就不行了。
从上面的解释,你应该能明白应该怎样修改了吧?
至于被测系统是否存在问题,我认为被测系统在【极端过压】的情况下无法处理请求,是不好不坏的,
好的地方是它好歹还没死;
不好的地方是它没有做好流控,不能达到“强压下能力降低,但还能满足部分业务请求,并拒绝所有其它请求”的状态;
另一个问题就是在它的恢复上,居然要那么久才恢复,通常有两种可能:
1业务处理线程的数量没控制好,导致消耗资源超出服务器硬件能力,对这么多的并发请求处理缓慢;
2接纳请求后的消息队列管理上设计太简单,没有对已经失效的请求进行清理,且又缓存了大量的请求,导致后来被测系统一直忙于处理这些失效请求;
修改你的LR设置,测试几点:
1-规格要求的并发能力;如果不能满足,直接提单让开发调优;如果能满足,则执行2;
2-规格1.1倍的情况下,长时间执行,能成功多少请求,失败多少请求;
3-在2之后,压力降回0.7倍规格,看【需要多久】系统才能够重新成功处理所有的0.7倍规格请求;
4-同2,但是压到2倍;
5-在4之后,同2;
提醒一点,你应该懂得LR脚本里面写【事务】(transaction)吧?上面我说的请求,都要用【事务】去统计。