关于think-time的一点研究和疑问

didi909 · 发表于 2014-4-4 10:00:11

本帖最后由 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的要长