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

x33g5p2x  于2021-09-19 转载在 其他  
字(1.5k)|赞(0)|评价(0)|浏览(262)

一、背景信息

摘抄关联信息如下:

  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 这个区间的执行比例。

四、小结

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

相关文章

微信公众号

最新文章

更多