前言
API 接口响应慢?
SLA 一直提不上去?
其实这是后端程序员想进阶必须要跨过去的坎: 就是把它优化掉.
那么这其中到底有没有套路呢? 答案是: 有的.
本文将介绍目前正在用并且十分 "无脑" 有效的这个套路.
正文
埋点追踪分析, 找出真凶
首先呢, 第一部肯定是在关键函数 (有 db, 文件, 复杂计算等操作) 的前后, 进行时间的记录.
此时去找 log 就可以找到每一步跑的时间. 根据实际可以一眼看出是哪一步跑慢了. 那么这一步就是主要优化的方向了.
ps: 此类对线上接口产生的耗时基本可以忽略, 所以放心用.
根据上下文, 找到解决方案
既然找到了跑得慢的函数. 那么就开始优化吧.
先说前提: 前端已有 lvs 负载均衡, nginx 反向代理转发请求.
首先需要分析为何跑慢了?
1. 是不是资源层面的瓶颈?
2. 是不是缓存没添加, 如果加了, 是不是热点数据导致负载不均衡?
3. 是不是有依赖于第三方接口?
4. 是不是接口涉及业务太多, 导致程序跑很久?
5. 是不是 sql 层面的问题导致的等待时机加长, 进而拖慢接口?
6. 网络层面的原因? 带宽? DNS 解析?
7. 代码确实差???
8. 未知?
暂时就想到这么多, 有补充欢迎留言, 谢谢.
对症下药
1. 资源紧张, 加机器, 干上去, 负载均衡搞起来
2. 加缓存可以解决的问题都不是什么大问题, 存在热点数据可以将某几个热点单独出来用专门的机器进行处理, 不要因为局部影响整体
3. 一方面与第三方沟通接口响应问题, 另一方面超时时间注意把控, 如果可以非核心业务能异步久异步掉.
4. 把非核心的业务进行异步化操作. 记住如果代码层面是非核心业务, 但是会影响用户感知, 需要慎重决定是否异步.
5. 如果是代码不良导致加锁了, 尽量优化索引或 sql 语句, 让锁的级别最小(到行), 一般来说到行差不多了. 如果是单个 sql 跑慢了, 需要分析是不是索引没加或者 sql 选的索引错了, 索引该加的就加了, 该 force index 也加了.
6. 网路原因, 需要联系运营商一起商量下怎么解决, 单方面比较难有大的优化.
7. 代码确实差, 那也无药可救了. 我选择狗带.
来源: http://www.bubuko.com/infodetail-3094867.html