如何对系统性能优化

一.cpu打满分析

image.png

1. log.info非常耗性能，json转换也非常耗性能，耗时占用cpu10%

   
   image.png
   image.png
   

   2.查询db非常耗cpu

   
   image.png
   image.png
   image.png
   查询db的解决办法有2中：
   

   1.增加缓存，减少对db的依赖
   2.层层点开之后，返现主要聚焦在 mybatis，sharding 之上的一些损耗 ，框架层面的无法在代码层面优化，可以通过增加机器来解决。

3.apm打点上报损耗13%

image.png
image.png
链路打点上报，主要损耗在json转换和http请求，不过这个也是必须的，只能加机器来解决了
二、QPS低RT高的分析解决
典型场景：
1.从调用链路分析，找出耗时较高部分，从代码层面进行分析，找出原因具体分析
image.png
链路显示标签查询耗时非常高，到了惊人的34ms
image.png
通过代码发现，标签串行查询了几次，经过分析，这几次查询可以作为并行处理
image.png
通过并行处理后，标签查询的耗时降下来了,耗时在9ms左右,如果命中缓存，会更快
2.从调用链里发现查询商家配置，有多次查询
image.png
分析讨论后，将这多次查询合并为一次查询，商家内部优化为多个配置并行查询，并增加缓存，我们这边将查询结果放在上下文中，后续节点使用，直接从上下文中拿取就ok
image.png
3.查询粒度细化
减少无用的查询，例如c端查询前台价格，会默认查询后台价格，有些场景，就不需要后台价格，所以对领域进行边界划分，每一个子域查询，都增加一个过滤器，需要的查，不需要的就不查，减少不必要的查询，对性能的提升是非常重要的。

4.动态线程池名称优化
并行框架工具里面operationName的生成 比较耗时，占比在0.7%，可以有优化的空间

image.png

本地测试耗时

image.png
源码分析：
image.png
image.png
image.png

5. redis 耗时5 分片/4GB/2 副本，平均耗时9ms

   
   image.png
   企业微信截图_164638228038.png
   

   redis升级后 16 分片/2GB/2 副本,平均耗时<1ms

   
   image.png

总结：

image.png