若是是本身写的代码,加上又熟悉业务场景,很容易就知道性能瓶颈点。但若是上来就去优化别人的代码,甚至是其余产品线的代码,仍是有一些挑战的。最近就在作这事,接手了优化公司一个业务引擎接口的任务,在这儿对优化方法作一些总结。数据库
优化接口总共分两步,一是找到性能热点,二是解决热点。在不熟悉代码的状况下,找热点是最难的,找到后对症下药就容易多了。先主要说一下如何找性能热点。缓存
微服务下,调用链追踪能很容易的定位到是链路上的哪一个环节出现问题。从而肯定是别人接口把你的拖慢了,仍是本身接口内代码有问题;且调用链反映的是线上真实数据,比跑线下测试数据更有说服力。异步
这里以A->B->C举例,简单说一下调用链经常使用的几个参数:函数
明白这几个参数后,再看看具体使用。咱们公司是用Kibana做为查询统计工具的。那么,个人分析步骤有以下几步:微服务
须要用到Kibana的Visualize功能,指定一个Metric为中位数、一个Metric为Max,再按照服务路径聚合便可工具
用Visualize能够统计出平均每一个线程中,每一个子链路的被调用次数、总耗时。而后看看在主链路耗时的占比状况。若是占比比较大,说明链路有问题了。好比我最近优化的几个接口,在链路上能看到数据库存储过程执行次数多且慢,那么确定能够定位是数据访问的问题。性能
若是占比很少,那就要继续分析方法内部了。测试
方法内部的分析,最主要的是采用合理的参数来驱动被测方法。这里我会选最耗时的参数来覆盖被测方法的大多数分支,而且充分暴露问题。优化
还要注意一点的是,在正式采样前,先对程序预热一下,也就是跑一次被测方法,让该缓存的缓存下来。这样更能反映线上通常状况。线程
dottrace能够说是异常的强大了。给你列出了某个方法的被调用次数、耗时、Collection操做耗时、系统函数耗时、用户函数耗时。基本上看这个图就知道热点在什么地方了。
热点找到了,后面就是对症下药的优化了。总结一下优化方法也就是:
1. 循环体内的IO、远程调用,改成循环外去重后批量执行,避免重复发起调用
2. 数据库慢查询,优化SQL、索引
3. 基础的、频繁查询的方法,能够把执行结果放到缓存
4. 串行的远程调用能够改成并行。(慎用,请求高峰期会形成内存暴涨,同时也可能致使上下文丢失)
5. 非主流程的方法,好比发消息通知、增删会员积分,改成发消息到队列而后异步消费。
......
先写到这儿吧。。公司要求严、打马好辛苦