猜想
其中耗时最多的子函数会被标红色
Affect(class-cnt:2 , method-cnt:2) cost in 525 ms.
`---ts=2020-0X-0Y 13:33:18;thread_name=DubboServerHandler-127.0.0.1:20880-thread-36;id=24e;is_daemon=true;priority=5;TCCL=com.mmm.WWWClassLoader@4362d7df
`---[1761.834357ms] com.xxx.service.impl.AServiceImpl$$EnhancerBySpringCGLIB$$e3cd7543:refresh()
+---[0.017066ms] com.xxx.service.impl.AServiceImpl$$EnhancerBySpringCGLIB$$e3cd7543:$jacocoInit()
`---[1761.00347ms] org.springframework.cglib.proxy.MethodInterceptor:intercept()
`---[1757.647111ms] com.xxx.service.impl.AdServiceImpl:refresh()
+---[0.006629ms] com.xxx.biz.yyy.service.impl.AServiceImpl:$jacocoInit()
+---[0.004073ms] java.util.Collections:singletonList()
+---[1709.203302ms] com.yyy.service.impl.AServiceImpl:refreshSomeThings()
`---[48.135719ms] com.yzzzz.service.impl.AServiceImpl:createSurvey()
最后发现造成性能瓶颈的函数是一个网络请求，单次请求大概100多毫秒。
假设请求N次，每次请求M毫秒(如200ms)，总耗时就是N*M毫秒。
减少网络请求的次数，可以将多个请求合并成一个批量接口。
最终定位到最影响耗时的函数上，继续往下跟。
最终一个接口从1s-2s降低到了200ms以内。
定位性能瓶颈有两个思路，一个是通过工具去监控，一个是通过经验去猜想。
最后大家在开发阶段或测试阶段，多看错误日志，多关注接口的响应时长等，尽早排除问题，尽早做优化。
总结
因此最有可能成为造成接口延时的是底层依赖的HTTP请求。
这里的批次甚至可以使用动态配置，根据情况动态修改。
本文讲讲是如何定位到性能瓶颈以及修改的思路，将该接口从2s左右优化到200ms以内。
将串行改为并行可以使用CompletableFuture来实现，具体参见：《Java数据分批调用接口的正确姿势》
工具监控
继续再trace耗时最多的子函数。
很多人不愿意学习arthas，如果不去学习不去了解，遇到可以用上的场景想不起来去用。
既然HTTP请求是性能瓶颈，那么要尽量减少请求，或者让请求由串行改为多线程并发/并行。
就工具而言，推荐使用arthas，用到的是trace命令
如果开发经验足够丰富，大致可以猜出哪些接口可能存在性能问题。
最常见的有：
为了避免调用的数据量太大，项目中采用分批调用的方式，但是每个批次太小，导致请求次数过多。
具体安装步骤很简单，大家自行研究。
在开发联调阶段发现一个接口的响应时间特别长，经常超时，囧…
步骤
然后审查一下自己的代码发现SQL查询部分都可以命中索引，调用链路上有一个函数最终会调用HTTP请求，而且是在一个循环里。
解决
我的使用步骤是，先最终待研究的函数的最外层：
最常见的是在循环中执行SQL或者网络请求。
定位
慢SQL会是性能瓶颈，主要原因是没有命中索引。发送远程数据请求。I/O操作等。
文章为作者独立观点，不代表股票交易接口观点
股民评论