｜－－－－－－－－
｜ 
｜－－－－－－－－ ｜ ｜－－－－－－－－
｜ ｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜ ｜－－－－－－－－
｜ ｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜ 小菜拿着两份测试报告跑去找大鸟，让他分析为什么同样的并发用户加上 think time 差距会如此巨大。大鸟笑着说：“你等一下我给你画一张图，你就懂了。”
用户 http 请求 服务器 用户 http 请求 服务器
｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜
｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜
｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜
｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜
｜－－－－－－－－ ｜ ｜－－－－－－－－ ｜
大鸟指着图说道：“服务器的压力并不直接来自于用户 ，而来自于用户所产生的请求 ，请求 的数量才是影响服务器压力的关键因素 “
” 你再看看你的测试结果 “
50 并发用户 ，每个用户 每 1 秒产生 1 个请求 ，每秒共产生 50 个请求 。
并发 | 响应时间 | 应用服务器 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 |
500 并发用户 （9 秒 think time）每个用户 10 秒产生 1 个请求 ，每秒共产生 50 个请求 。
并发 | 响应时间 | 应用服务器 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 |
“这下我知道怎么回事了，判断一个应用是否满足性能指标，只需要判断这个应用每秒能处理多少请求和用户并没有直接关系。” 小菜点着头说。
“那 A 接口每天会有 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"
“大鸟果然是大鸟，这下我明白了。我以前也不懂，一直听人说并发是衡量系统性能的指标，原来这个并发不是指用户，而是指请求啊”
