网站接入商,河北邯郸做网站的公司,手机端网站制作,太原经济型网站建设价格景 分析过程 总结 背景
公司的一个ToB系统，因为客户使用的也不多，没啥并发要求，就一直没有经过压测。这两天来了一个“大客户”，对并发量提出了要求：核心接口与几个重点使用场景单节点吞吐量要满足最低500/s的要求。
当时一想，500/s吞吐量还不简单。Tomcat按照100个线程… 景 分析过程 总结 背景
公司的一个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类似与这种：
!--主要类似与库存扣减每次-1type只有有限的几种且该表一共就几条数据（一种一条记录）--
!--压测时可以认为type=1是写死的--
updatetablesetfield=field-1wheretype=1andfiled1;上述SQL相当于并发操作同一条数据，肯定存在锁等待。日志显示此处的等待耗时占接口总耗时 80% 以上。
二话不说先改为敬。因为是压测环境，直接改为异步执行，确认一下效果。 ❝ PS：当时心里是这么想的：妥了，大功告成。就是这里的问题！绝壁是这个原因！优化一下就解决了。当然，如果这么简单就没有必要写这篇文章了... ❞ 优化后的效果： 嗯...
emm...
好！这个优化还是很明显的，提升提升了近2倍。
此时已经感觉到有些不对了，慢SQL已经解决了（异步了~ 随便吧~ 你执行 10s我也不管了），虽然对吞吐量的提升没有预期的效果。但是数据是不会骗人的。 最大值：已经从5s - 2s 百分位值：4s - 1s 这已经是很大的提升了。
继续定位“慢”的原因
通过第一阶段的“优化”，我们距离目标近了很多。废话不多说，继续下一步的排查。
我们继续看日志，此时日志出现类似下边这种情况：
2023-01-0415:17:05:347INFO**.**.**.***.50[TID:1s22s72s8ws9w00]**********************
2023-01-0415:17:05:348INFO**.**.
