-
景
-
分析过程
-
总结
背景
公司的一个ToB系统，因为客户使用的也不多，没啥并发要求，就一直没有经过压测。这两天来了一个“大客户”，对并发量提出了要求：核心接口与几个重点使用场景单节点吞吐量要满足最低500/s的要求。
当时一想，500/s吞吐量还不简单。Tomcat按照100个线程，那就是单线程1S内处理5个请求，200ms处理一个请求即可。这个没有问题，平时接口响应时间大部分都100ms左右，还不是分分钟满足的事情。
然而压测一开，100 的并发，吞吐量居然只有 50 ...
而且再一查，100的并发，CPU使用率居然接近 80% ...
从上图可以看到几个重要的信息。
最小值：表示我们非并发场景单次接口响应时长。还不足100ms。挺好!
最大值：并发场景下，由于各种锁或者其他串行操作，导致部分请求等待时长增加，接口整体响应时间变长。5秒钟。有点过分了！！！
再一看百分位，大部分的请求响应时间都在4s。无语了！！！
所以 1s钟的 吞吐量 单节点只有 50 。距离 500 差了10倍。难受！！！！
分析过程
定位“慢”原因
❝
这里暂时先忽略 CPU 占用率高的问题
❞
首先平均响应时间这么慢，肯定是有阻塞。先确定阻塞位置。重点检查几处：
-
锁 (同步锁、分布式锁、数据库锁)
-
耗时操作 (链接耗时、SQL耗时)
结合这些先配置耗时埋点。
-
接口响应时长统计。超过500ms打印告警日志。
-
接口内部远程调用耗时统计。200ms打印告警日志。
-
Redis访问耗时。超过10ms打印告警日志。
-
SQL执行耗时。超过100ms打印告警日志。
上述配置生效后，通过日志排查到接口存在慢SQL。具体SQL类似与这种：
<!-- 主要类似与库存扣减 每次-1 type 只有有限的几种且该表一共就几条数据（一种一条记录）-->
<!-- 压测时可以认为 type = 1 是写死的 -->
update table set field = field - 1 where type = 1 and filed > 1;
上述SQL相当于并发操作同一条数据，肯定存在锁等待。日志显示此处的等待耗时占接口总耗时 80% 以上。
二话不说先改为敬。因为是压测环境，直接改为异步执行，确认一下效果。
❝
PS：当时心里是这么想的：妥了，大功告成。就是这里的问题！绝壁是这个原因！优化一下就解决了。当然，如果这么简单就没有必要写这篇文章了...
❞
优化后的效果：
嗯...
emm...
好！这个优化还是很明显的，提升提升了近2倍。
此时已经感觉到有些不对了，慢SQL已经解决了（异步了~ 随便吧~ 你执行 10s我也不管了），虽然对吞吐量的提升没有预期的效果。但是数据是不会骗人的。
-
最大值：已经从
5s -> 2s -
百分位值：
4s -> 1s
这已经是很大的提升了。
继续定位“慢”的原因
通过第一阶段的“优化”，我们距离目标近了很多。废话不多说，继续下一步的排查。
我们继续看日志，此时日志出现类似下边这种情况：
2023-01-04 15:17:05:347 INFO **.**.**.***.50 [TID: 1s22s72s8ws9w00] **********************
2023-01-04 15:17:05:348 INFO **.**.
