接口每天被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取决于是模拟用户 还是 模拟请求。压力和用户数没有直接关系 和用户行为有关系,所以应该分析的是用户行为而非用户数