關於最佳化API介面響應速度

關於最佳化API介面響應速度

關於最佳化API介面響應速度。。。

今天只是粗略寫寫，關於這個最佳化設計的方面很多，接下來再仔細研究研究。

今天發現介面響應很慢，調開發者工具出來檢視才發現介面居然耗時2秒左右，然後查了下後臺邏輯，發現裡面邏輯很多，有呼叫外部幾個介面，還要查詢資料庫。

兩個介面耗時都接近1.5秒了。看了下是查詢工作流的介面，看來只能找平臺部那邊最佳化了。

剩下的就是最佳化我們這邊系統的查詢效率了。

首先需要分析為何慢了

是不是資源層面的瓶頸？

是不是快取沒新增，如果加了，是不是熱點資料導致負載不均衡？

是不是有依賴於第三方介面？

是不是介面涉及業務太多，導致程式跑很久？

是不是sql層面的問題導致的等待時機加長，進而拖慢介面？

網路層面的原因？頻寬？DNS解析？

程式碼不行？

未知？

對症下藥

資源緊張，加機器，幹上去，負載均衡搞起來！

加快取可以解決的問題都不是什麼大問題，存在熱點資料可以將某幾個熱點單獨出來用專門的機器進行處理，不要因為區域性影響整體（這一次好像不涉及這個）

一方面與第三方溝通介面響應問題，另一方面超時時間注意把控，如果可以非核心業務能非同步久非同步掉。

把非核心的業務進行非同步化操作。記住如果程式碼層面是非核心業務，但是會影響使用者感知，需要慎重決定是否非同步。

如果是程式碼不良導致加鎖了，儘量最佳化索引或sql語句，讓鎖的級別最小（到行），一般來說到行差不多了。如果是單個sql跑慢了，需要分析是不是索引沒加或者sql選的索引錯了，索引該加的就加了，該force index也加了。

網路原因，需要找運維人員，單方面比較難有大的最佳化。

程式碼確實差，那也無藥可救了。毀滅吧！

剛開始以為是機器效能不行，看了下系統負載，發現佔用率並不高，好像也不是效能問題。

接著以為是應用最佳化，但是看了下 JVM 的相關引數和 Java 堆的使用情況，發現都不高，感覺應該是資料庫的原因了，當時建表的時候沒有建相關的索引。

然後考慮加下索引試試。

加了一個組合索引，還有一個單列索引。

加了之前在程式碼中加了時間記錄，感覺有所提升。

剩下的就是外部介面的耗時了。