前天有个认识多年的做性能测试的朋友发了个信息给我。让我帮他分析一个问题。
一看到性能问题描述，我就想骂人，你自己也做性能测试十年以上了，性能问题还来问我？这家伙是来考我的，第一印象就是这样。
摘抄关联信息如下：
- 场景30分钟，用户100递增到1000，应用服务器CPU使用率70%-80%。tomcat线程数670左右，tcp连接最高是6000左右。从Druid Monitor上看，tpc达到500左右时，数据库连接的等待次数和时长都在增加，最和的等待有110s左右。
- 做个档板，不查数据库，应用服务器CPU使用率可以达到90%，TPS能到600，tomcat线程数1300左右。
系统部署结构很简单：
云服务器上部署结构如下：
压力机 ------ 应用服务器 ----- 数据库服务器
问题是啥呢？看了描述之后，我觉得没啥大问题嘛。走数据库，TPS520；不走数据库，TPS600。So what?
没什么大区别，但是这小伙的疑问是什么呢？走数据库，为什么应用服务器CPU使用率达不到90%呢？
这个问题提的比较刁钻了。
比较简单的判断就是，如果加了数据库TPS上不到600，同时应用服务器CPU又用不上去，那就应该是数据库上有瓶颈。多简单的逻辑呀。
你说，这逻辑是不是简单？是不是对？嗯，我想也是，确实对。哈哈。
那就分析吧。
分析从哪开始呢，加不加数据库开始分析呢？
在这里有一个经验之谈：有本事，就把所有的涉及到的机器都加上一起分析；没本事，就分段分析，层层mock/档板。
而我自认为是有本事的。
加上数据库，开始压力。
应用服务器CPU如下：
数据库服务器因为需要跳板机登录，我也没有看，但是有druid Monitor，先看慢不慢吧。
还好，还好。超过50%的执行时间在0-10ms，但是10-100毫秒也不算少。
哎呀，100ms嘛，这个值很尴尬呀，不多不少的。
我们再来看看前端的曲线，再来说这个100ms是多还是少。
一开始的时候响应时间这个业务的响应时间只有20ms。
现在再来感觉一下，这个100ms是多还是少呢？那还用问！肯定是多呀！
但是，但是，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这个区间的执行比例。
性能分析呢，需要的全局观，有人看到找出来的性能结果，觉得怎么问题这么简单。但是当你不知道的时候，要干什么，才是能力。
