優化API接口響應速度

前言

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.代碼確實差，那也無藥可救了。我選擇狗帶。