性能分析之公有云小程序服务分析案例

背景信息

摘抄关联信息如下：

1. 场景 30 分钟，用户 100 递增到 1000，应用服务器 CPU 使用率 70%-80%。Tomcat 线程数 670 左右，TCP 连接最高是6000左右。从 Druid Monitor 上看，TCP 达到 500 左右时，数据库连接的等待次数和时长都在增加，最和的等待有 110s 左右。
2. 做个档板，不查数据库，应用服务器 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 这个区间的执行比例。

小结

性能分析呢，需要的全局观，有人看到找出来的性能结果，觉得怎么问题这么简单。但是当你不知道的时候，要干什么，才是能力。