小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。
本文已参与 「掘力星计划」 ，赢取创作大礼包，挑战创作激励金。
一、背景信息
摘抄关联信息如下：
- 场景 30 分钟，用户 100 递增到 1000，应用服务器 CPU 使用率 70%-80%。Tomcat 线程数 670 左右，TCP 连接最高是6000左右。从 Druid Monitor 上看，TCP 达到 500 左右时，数据库连接的等待次数和时长都在增加，最和的等待有 110s 左右。
- 做个档板，不查数据库，应用服务器 CPU 使用率可以达到 90%，TPS 能到 600，Tomcat 线程数 1300 左右。
系统部署结构很简单，云服务器上部署结构如下：
二、问题现象
问题是啥呢？看了描述之后，我觉得没啥大问题嘛。
- 走数据库，TPS 520；
- 不走数据库，TPS 600。
So what?
没什么大区别，但是这小伙的疑问是什么呢？走数据库，为什么应用服务器 CPU 使用率达不到 90 %呢？ 这个问题提的比较刁钻了。 比较简单的判断就是，如果加了数据库 TPS 上不到 600，同时应用服务器 CPU 又用不上去，那就应该是数据库上有瓶颈。多简单的逻辑呀。 你说，这逻辑是不是简单？是不是对？嗯，我想也是，确实对。哈哈。
那就分析吧。
三、问题分析
分析从哪开始呢，加不加数据库开始分析呢？
在这里有一个经验之谈：
- 有本事，就把所有的涉及到的机器都加上一起分析；
- 没本事，就分段分析，层层mock/档板。
而我自认为是有本事的。
加上数据库，开始压力。
应用服务器CPU如下：
数据库服务器因为需要跳板机登录，我也没有看，但是有 Druid Monitor，先看慢不慢吧。
还好，还好。超过 50 %的执行时间在 0-10 ms，但是 10-100ms 也不算少。 哎呀，100ms 嘛，这个值很尴尬呀，不多不少的。 我们再来看看前端的曲线，再来说这个 100ms 是多还是少？
一开始的时候响应时间这个业务的响应时间只有 20ms。 现在再来感觉一下，这个 100 ms是多还是少呢？那还用问！肯定是多呀！ 但是，但是，100ms 确实是消耗在数据库上的吗？ 确实是数据库的问题导致的时间消耗吗
于是我就登录到数据库上看看sql执行的到底快不快。
通过不断的检查 trx 和 wait、lock 表。如下：
检查了很多次，并没有发现太慢的。有人说，100ms 手工根本查不出来。
Yes! You are totally right!
所以我也同时检查了 wait 和 lock，如果因为等待，至少我能看得到。有人说，你为什么不用其他监控数据库的工具？ 因为，因为，这也不是我的项目呀，他们没配置，只有个 SQL 客户端工具连上，有什么办法，只能手工查查喽。 但是在这里还是要说明一下的，真正的性能分析过程中，这样的手段还是过于粗糙了，还要全局监控数据库的工具才好。 不过大概也可以判断没有问题。（这里留下一个扣！）
于是接着检查一下，看到底哪里有问题。
看操作系统，看网络，看IO，看CPU热点，看...美女！
没看到哪里有什么问题，dump 了一下线程栈，里面也都在正常的处理业务，并且也不慢。
但是性能呢，是要从前查到后的，压力脚本和数据也要查查。
于是，我打开脚本看了一眼。咦，这为什么是公网 IP？
公网 IP 都能跑出这么高的 TPS，也真是不容易。 换成内网IP吧。
之后的结果是：
TPS能达到 680 左右。
应用服务器 CPU 呢？
能用到这么高，也应该满足了吧。
SQL 执行差不多还是那么快。
如果从测试需求上来看，这个 TPS 也不错了。 但是优化是无穷的工作对不对？所以这个系统还有优化的空间，后面要整的，是数据库。要让数据库处理的速度变得稳定，减少 10-100ms 这个区间的执行比例。
四、小结
性能分析呢，需要的全局观，有人看到找出来的性能结果，觉得怎么问题这么简单。但是当你不知道的时候，要干什么，才是能力。
