軟體效能問題正確定位思路

上回說了效能問題錯誤修復大法鑑賞，如果不給出正確方法，那就止步於笑談。那麼軟體出了效能問題，究竟應該如何去定位呢？

1.資源

首先，我們要明白一件事，軟體發生效能問題，必定是資源不夠用了。資源分為硬體資源和軟體資源，硬體資源有：

• CPU：記憶體插槽，核心，硬體執行緒
• 記憶體：DRAM，快取
• 網路：乙太網，WIFI，4G
• 儲存裝置：硬碟
• 控制器：儲存，網路

軟體資源有：

• 互斥鎖：鎖的平均佔用的時間是一個重要的指標，等待鎖的佇列側面反映了軟體的飽和度
• 執行緒池：有限的執行緒處理海量的工作，必然會有事務等待處理
• 程式/執行緒/協程容量：系統的程式/執行緒的數量是有上限的，在golang、erlang這種原生支援協程的語言中，協程的數量也不是無上限的
• 檔案描述符容量：系統的檔案描述符也是有上限的

2.資源使用的三個維度

資源在使用時有三個維度：utilization（使用率），saturation（飽和度），errors（錯誤）。我們必須要先弄清楚這三個概念，然後才能查詢效能問題。

2.1使用率

在規定的時間內，資源用於服務工作的時間百分比。

2.2飽和度

資源不能用於服務額外工作的程度，通常有等待佇列。飽和程度可以用排隊長度或者排隊所花時間來衡量。

2.3錯誤

軟體執行出錯。

3.USE方法

研究這三個維度，查詢效能問題的方法就叫USE方法，USE方法是一種研究高使用率、高飽和狀態下效能問題最有效的方法。

3.1工作流程

1. 錯誤檢查優先順序最高的，不僅僅時因為修復錯誤的優先順序比較高，更因為錯誤更容易被發現（只要檢查錯誤日誌）。
2. 使用率和飽和度也是有順序的，只有當使用率高達100%的時候，降低飽和度才有意義[1]。
3. 當你使用USE方法的時候，很可能發現了不止一個效能問題，你關心的問題並不會在一開始就出現，你需要多選擇幾項資源，才能找到你所關心的效能問題。不過，理論上所有的效能問題都應該被修復（在成本允許的情況下）

3.2資源檢查

使用率有兩個紅線：60%，100%

根據排隊理論，60%意味著優先順序較低的工作將會被排在佇列後面執行。100%意味著該資源出現了嚴重的效能瓶頸，亟待解決。

飽和度：任何程度的飽和都是效能瓶頸。

錯誤：錯誤都是值得研究的，不僅僅是為了解決效能問題。

3.3收費站現象

假設高速公路的收費站，一整天的使用率是40%，你能據此斷定收費站在早高峰的時候沒有排隊嗎？

收費站現象表明了資源即使大部分情況下都是綽綽有餘，但是系統依然會出效能問題，只是需要在特定時間點才能觀察到。因此，我們還需要預留應急資源，或者非同步處理分擔峰值壓力。

4.作者的話

4.1吐槽

我一個研究服務端效能的文章竟然找不到話題節點，只能先借用移動效能測試的節點了，麻煩管理員加個服務端效能測試節點。

4.2注

[1] 更準確地說，應該是瞬時使用率高達100%