有think time和没有think time的区别
在controller里,设置run-time setting时,将think time忽略,比如有一个场景,10个用户并发登录,在忽略掉think time 的时候,事务"登录"响应时间很短,但是后台CPU利用率却很高,同时在规定的时间内,比如运行3分钟后,通过的事务数要比有think time的时候多很多.反之,有think time 的时候,事务"登录"响应时间会比较长(因为把think time算在了里面),同时不会对后台CPU造成很大的压力,但事务通过数却会少很多.
问题1:如果说没有think time的时候,CPU利用率很高,但有think time,利用率一般,那么我们到底是否应根据think time来判断后台CPU利用率到达瓶颈了呢?也就是说,后台CPU利用率到底是看有think time的时候还是没有think time的时候?
问题2:我们在测试的时候,是不是应该关注think time?除了能更真实的反应用户的操作以外,think time还有什么作用?
期待大家的解答,谢谢! 顶一下~~~ 下班前最后一顶 若是追求更真实反应性能状况的话,为何不考虑思考时间? 同样多的用户数的情况下,不加think time 在单位时间内产生的请求数肯定多于加思考时间了,当然给服务器产生的压力会更大
致于是否需要加思考时间,要看你测试的目的 加上为好,不但要加,而且还不能固定用同样的思考时间,建议用设定思考时间范围的方式来定义思考时间,这样才能更好的模拟用户行为(比如有的人发帖慢点,有的人发帖快点). 多谢楼上各位的回复,我就是觉得,加上think time以后,事务的响应时间就会加上think time的时间,比如本来一个简单的登录操作,加上think time以后,比如,think time 有5秒,那么最后看到的结论,登录事务的响应时间肯定超过5秒,那这样的话,还需要和客户解释为什么会这么长时间,比较麻烦,所以我想索性不加了,简单点,不知道对不对 思考时间可以在Analysis里面通过设置Filter把它去掉的,所以你也不用去跟客户解释什么。你如果不加思考时间,那测出来的效果是完全不一样的。 OK,了解,非常感谢~~~ 也可以在录制好脚本后,把思考时间放在事务的外面。 从压力考虑不加为好从测试的真实性考虑应该加上这样才能更真实的得到结果看你出于什么样的目的 侧重点是哪里 谢谢,学习了。我一般是在插入事物之前,插入集合点的
页:
[1]