小猿日記（8） - 接口優化從13秒到3秒，我做了什麼

口水記

由于以前的一些債務，某些接口是越來越慢，越來越慢。

最近做了一個新需求，其中有個接口的時間需要13秒。其實最開始是需要20多秒，後面優化了一下，就到13秒了。

但是13秒，這能忍嘛。盡管這個接口隻有在使用者第一次使用才會請求到（涉及到三個系統），但也忍不了啊，直接勸退一波不忠實使用者。

隻能是想辦法，而且必須想辦法。

首先想到的是把一些循環查詢去掉。

說幹就幹，先去看看三個系統的鍊路，究竟是哪個系統耗時比較久。

結果，其中最底層的系統花費了11秒，那結果穩了呀，把那個11秒優化了，不就ok。

繼續往下看，方法中隻能通過打日志來看了，究竟是哪個方法，哪行代碼耗時。

涉及到9個方法，每個方法耗時1秒多點，這就很難辦了，沒有明顯的短闆了。

不方，找一個方法看代碼，發現有的方法中有一些周遊，是在循環中去查詢資料庫，這就有一些辦法了。

這裡的循環内查詢還有點懸機，那就是循環内的查詢，是循環對象中json字元串中的某個key的value，雖然處理起來麻煩一點，但最後還是處理好了，空間換時間嘛，總歸要處理的。

很快，優化完畢，結果并不理想，差不多優化了2秒左右，還需要8-9秒的時間。

代碼中是沒有可以優化的點了，因為都是删除、插入、修改，查詢都沒有，緩存自然不用去想了。

此時想到了另外一點，異步。

因為之前在另外一次優化中有用到異步，一個方法，有調用三個不同外部服務，且順序并不相關，是以使用了異步，瞬間那個接口便優化了50%以上，結果甚好（注意，異步一定要注意不要翻車，一定先評估好影響，能否異步）。

但是在此次方案中，效果卻并不行，由于至少有6個步驟依賴于前面的方法的處理結果，是以無法異步，或者單獨把某一兩個方法異步，其實意義并不大。

那麼又從哪方面入手，此時，我想到了預熱。

因為這是一些資料的準備，是對于一些使用者的資料初始化，那麼，完全可以假設使用者已經存在了，把這些資料先準備好，使用者來了，直接修改關聯關系即可。

說幹就幹。理論可行，結果也很理想，這裡的11秒優化到不到1秒，總體的時間不需要3秒。

至于3秒還能不能優化，我的回答是肯定可以的，但是沒必要，這裡的3秒你可以了解為一個使用者注冊的等待資料初始化的時間（一個使用者隻會有一次這個接口的請求）。

從使用者可接受度，以及産品的發展過程、團隊角度來說，并沒有必要。

使用者現在對于3秒注冊，接受度很高。其次，産品的重心，目前依然是業務的疊代，是以，團隊的重心依然是在業務上。

3秒到1秒的優化，這裡的時間成本比前面13秒到3秒的成本甚至還要高，但是起到的團隊/公司收益，卻不及前面的一成。

要不要做優化，什麼時候去做優化，這是一門學問，自己也還有很多要學的。

小結

本次優化的目的是為了提升體驗

是以從減少時間入手，找到瓶頸，先解決瓶頸，再去優化邊邊角角

本次優化并沒有去優化邊角，隻是将瓶頸進行了優化，便完全達到了預期，而且該接口後續的優化，暫時是沒有時間去進行，因為還有更多緊急的任務在排着。

不正經語錄

• 接口多久算慢，優化到多久算快，不要一概而論
• 不同的優化有不同的目的，目的不同，優化過程也可能不同

聲明

本文故事純屬遐想，如有雷同，我是原創。

歡迎轉載。

轉載請務必注明以下資訊。

原作者：谙憶

原文位址：

https://copyfuture.com/blogs-details/20200525215110993ktknwg449hzc2re

公衆号

更多精彩内容、活動、程式猿的小故事，歡迎掃碼關注公衆号