关于think-time的一点研究和疑问
本帖最后由 didi909 于 2014-4-4 10:18 编辑对think-time有一些了解，并由此引发了一些疑问，提出来大家看看我的结论是否正确，我的疑问是否可以解答，谢谢！
关于think-time的一点研究
大众认知
目前压测人员对think-time的普遍两个认识：
1. 其作用是模仿用户真实的操作等待行为
2. 当场景中忽略think-time运行时，服务器的压力会增大
我的认知
在此基础之上，我对think-time也有一些了解：“执行了think-time的场景所获得的响应时间” – “录制事务的think-time” = “忽略think-time的场景所获得的响应时间”
证明结论
为了证明这个结论，我做了以下验证：
场景1
运行场景时不忽略think-time，运行场景完成后，生成analysis报告如下(lra-1)，可以看到登录和退出的平均响应时间比较的长，检查脚本，可以发现我的登录事务，录制了33秒的think-time，我的退出事务，录制了15秒
lra-1-pic1
那么在场景1的基础上，将过滤器改为“do not include think time”，得到以下数据(lra-1-pic2)
lra-1-pic2
场景2
场景2中，replay think time as recorded，其余与场景1完全一致，得到如下报告(lra-2-pic1)：
lra-2-pic1
对比
分析
1. 场景1中，“include think-time”时，减去脚本中所录制的思考时间，事务响应时间几乎可以等于“do not include think-time”
2. 在1的结论基础上，场景1与场景2的响应时间非常相近
3. 在场景1中，无论是否包含think-time，吞吐量与点击率均没有变化
4. 在场景2中，吞吐量与点击率均比场景1高
结论
1. 场景中的think-time与响应时间是可以直接相加减的关系
2. 这种加减关系并不影响吞吐量和点击率等其他指标
3. 忽略think-time将给服务器造成更大的压力
疑问
1. 为什么场景1中，不包含think-time的响应时间与场景2的响应时间基本一致，根据结论3，场景2受到了更大的压力，响应时间上应该比场景1的要长 大家一起讨论一下呗 51testing上面的朋友都只对共享的资料感兴趣么？资料看得再多也都是别人的东西，把他们转化成自己的只是不好吗？ 个人理解：
两次测试并没有达到系统性能瓶颈，即使场景2对系统压力有所增大，系统仍然能及时响应，所以响应时间变化不大。 楼主场景2的情况下，实际的数量已经是第一次的8倍了。
登录和退出的资源消耗比较少，如果换个业务逻辑负责点的流程可能就看出效果了吧。 应该你的负载还不够高，所以看不太出来是否包含think time的区别
页:
[1]
