【jmeter】浅说 think time

接口每天被5000个人调用，同时在线500人，每天要被调用50000次。
  过了没多久测试完成写了一份报告发给项目经理：

• 并发 | 响应时间 | 应用服务器cpu |数据库服务器cpu |TPS |
• 50  |   1s    |    70%     |      20%     |50 |
• 100  |   1.3s   |    95%     |      30%     |75 |
• 200  |   2.9s   |    99%     |      30%     |70 |
• 500  |   7s    |    99%     |      30%     |71 |

小菜结论：A接口在50并发时应用服务器已经到达70%警报点，A接口只能满足50人同时并发操作，建议增加应用服务器数量

  项目经理看到小菜的报告通知运维部门增加A接口的服务器数量，可运维部门反馈：A接口服务器目前日最高CPU只有20%并没有性能风险 项目经理生气的质问小菜怎么测试结果怎么和实际相差那么多。
  小菜很郁闷，就去找从事测试工作七年的同事大鸟，请教原因。大鸟听了事情的经过，笑着说道：“小菜呀，你见过一个正常人在连续操作之间没有停顿的吗？“ 小菜恍然大悟，立马在脚本里加上9秒的 think time 重新测试：

• 并发 | 响应时间 | 应用服务器cpu |数据库服务器cpu |TPS |
• 50  |   0.8s   |    10%     |      5%       |5   |
• 100  |   0.9s   |    20%     |      10%     |10 |
• 200  |   0.9s   |    20%     |      10%     |20 |
• 500  |   1s    |    70%     |      20%     |50 |

小菜看着测试结果感叹 同样是500并发，加了think time后差距为何会如此之大。

50并发用户  ，每个用户  每1秒产生1个请求 ，每秒共产生50个请求。

500并发用户 （9秒think time） 每个用户  10秒产生1个请求 ，每秒共产生50个请求 。

50000个请求，那么它的压力就是50000/（3600*24）＝0.6笔/s... ”小菜挠着头感觉有哪里不对。
大鸟用笔狠狠的敲了小菜的脑袋说：“你这笨蛋，难道你的接口24小时都有人用吗？一般服务器的业务大多发生在工作日9:00˜17:00 ，那么你起码也要这么算50000/（3600*8），当然业务的产生肯定不是平均的，这时候我们会使用80/20原则来计算平均峰值来作为我们的指标。”
80/20峰值公式：80%的业务是在20%的业务时间内完成的
"所以A接口的指标应该是（50000*80%）/（3600*8*20%）＝28笔/s"
“大鸟果然是大鸟，这下我明白了。我以前也不懂，一直听人说并发是衡量系统性能的指标，原来这个并发不是指用户，而是指请求啊”

ps:加不加thinktime取决于是模拟用户 还是 模拟请求。压力和用户数没有直接关系 和用户行为有关系,所以应该分析的是用户行为而非用户数