口水記

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

最近做了一個新需求，其中有個接口的時間需要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

更多精彩內容、活動、程序猿的小故事，歡迎掃碼關注公眾號
程序編程之旅