21 | 支付前查询订单列表：如何分析优化一个固定的技术组件？
高楼
今天我们来分析支付前查询订单列表接口。
在这节课中，我将带你来看一下对于一个固定的技术组件，分析优化思路应该是怎样的，也就是说组件不是我们开发的，但是又要分析优化它，我们该怎么办？
此外，我们还会遇到一个问题，就是当数据库的 CPU 并没有全部用完，而是只用了几颗的时候，我们应该如何具体定向？对此，我们将用到查看数据库本身线程栈的方法，这和前面直接看 trx 表有所不同。
下面，我们一起进入今天的内容。
场景运行数据
对于支付前查询订单列表接口，我们先来看第一次运行的性能场景结果：
从运行的场景数据来看，这个接口的 TPS 一开始还是挺高的，达到了 800 多。但是，响应时间也增加了，瓶颈已经出现。我们只要知道瓶颈在哪，就能知道这个接口有没有优化空间。
根据高老师的分析逻辑，在正式分析之前，我们看一下架构图。
架构图
这张架构图是非常清楚的，可以看到，当前接口的逻辑为：Gateway - Order - Member，其中也使用到了 MySQL 和 Redis。
下面我们来看看，响应时间消耗到哪里去了。
拆分响应时间
Gateway：
Order：
Member：
从响应时间的分布来看，Gateway（网关）上消耗的时间要长一些。所以，我们接下来得从 Gateway 下手，分析一下到底是哪里消耗了时间。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了如何分析和优化一个固定的技术组件，以支付前查询订单列表接口为例进行了详细分析。首先从性能场景数据入手，发现接口的TPS较高但响应时间也在增加，存在瓶颈。通过架构图和响应时间分布的拆分，确定了Gateway上消耗时间较长，因此进行全局监控和定向监控分析，发现Gateway服务在worker-4上，线程CPU消耗正常，但仍对线程进行调整以提高CPU利用率。优化效果显示TPS有所增加。然后转入第二阶段分析，重新从全局监控开始，发现数据库中有两个CPU的使用率异常高，进一步进行定向分析。文章强调了在性能项目中不轻易给出加CPU的建议，而是要在分析了逻辑之后确定没有其他优化空间再给出这样的建议。整体内容详实，涵盖了性能优化的多个方面，对读者进行了深入的技术指导。文章内容丰富，通过实例详细介绍了性能优化的方法和思路，对于需要进行性能优化的技术人员具有一定的指导意义。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《高楼的性能工程实战课》，新⼈⾸单¥59
《高楼的性能工程实战课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(6)
- 最新
- 精选
Alisa1.因为一个全局监控方法可能不能包含所有性能计数器，要知道自己想看什么计数器，知道计数器可以通过哪些工具来查看，使用全部是为了不漏点存在问题的任何可能性 2.单cpu高，可以先查看cpu在跑哪些线程，找到对应高效耗线程，然后再去使用工具查看这些线程在干什么，从而定位问题作者回复: 总结正确。不错。
2021-06-023
alley老师，我看到一句话，说一切性能问题，都能通过jstack pid找到线索作者回复: 那要看是不是和代码有关的问题喽。 jstack是查看栈信息的，也就是代码的执行逻辑。
2021-05-0731
冒冒还有一个问题想问下，高老师，在压测过程中，一个服务启了多少个pod？作者回复: 这是不固定的呀，取决于业务容量的要求。
2022-01-21- 冒冒预热 该怎么做？
作者回复: 就是先跑一遍场景。
2022-01-21 
天若有情在容器上的服务，会因为lxcfs的计算方式，导致看到的应用使用的cpu不均衡的情况嘛？ 比如申请的容器是4c8g的，宿主机是24核的，top命名看到应用用的4核很不均衡，只是其中的一个核是满的，其他都很空闲。作者回复: 这个说法和实际看到的好像有点不符哦。
2022-01-132- 道长1、也可能存在关联系统影响导致性能差； 2、CPU使用率高，也可以使用perf抓去调用函数
作者回复: 1，在性能分析中没有“可能”。其实这个问题要问的是一个思路，而不是原因。 2. 也同样是问思路。不过cpu使用率，应该先看是哪个计数器，再确定后续的思路，而不是直接用perf去看系统调用。
2021-05-12
收起评论
