雙11備戰前夕，總繞不過效能壓測環節，TPS 一直上不去 / 不達標，除了程式碼上的問題外，伺服器環境、配置、網路、磁碟、CPU 亦是導致效能瓶頸的重要一環，本文旨在分享最近專案效能壓測過程中的排查經驗，文中的表單你可以作為排查手冊儲存，如有不對之處，還請在評論區分享、交流你的經驗和觀點：）

通過本文，你可以瞭解和掌握：

• 瞭解常見的系統瓶頸的可能原因。
• 通過效能探查器定位效能瓶頸。
• 幾點關於效能優化的策略。
• 一份關於 windows 效能監視器的部分計數器翻譯及對應的經驗結論。

吞吐量 和 延時的關係

關於吞吐量/吞吐率、延時，你可以通過 Jmeter中的”聚合報告“和”用表格檢視報告“來獲取。

• Throughput 越大，Latency 越差：因為請求過多，系統繁忙導致響應速度降低。
• Latency 的值越小說明能支援的 Throughput 越高：Latency 數值小說明系統處理速度快，自然便可以處理更多的請求。
• Throughput "不用" 通過降低 latency 的方式來提高，排查效能問題的時候，勿在降低 Latency 值上消耗過多時間。

常見系統瓶頸：

• 型別轉換：除了裝箱拆箱外，還要著重看下 JSON 的一些轉換類庫，如 newtown，fastJson 等等，可能會引起 CPU 維持在高位。
• 非同步操作：有些非同步操作會非常影響效能，尤其是在網路較差的情況下，很可能阻塞業務。
  • 如非同步下的狀態通知通常會影響效能。通常而言，非同步操作會讓”吞吐率“提升，但會犧牲 延時（latency）。

定位效能瓶頸

定位的方式不一定是程式級別的，一開始可以先從作業系統的 CPU 使用率，記憶體使用率，系統 IO 和 網路 IO，網路連線數 著手分析。

• CPU 使用率不高，但是 throughtput 和 latency 上不去： 說明程式沒有忙於計算，可能問題在 I/O 上。
  • 一般 CPU 和 IO 是反著來的： CPU 沒問題，問題可能在 IO，反之亦然。
• 如果 CPU、IO、記憶體、網路頻寬使用都不高，但是系統性能上不去： 說明程式有問題，可能是為資源被鎖，存在鎖競爭關係，程式被阻塞；或者是在上下文切換等等。
• 關於 IO，要看 3 個方面：磁碟IO，網路IO 以及 記憶體換頁率。
• 程式級別的效能瓶頸定位：
  • 分段註釋程式碼 / 讓一些函式空轉 / 做一些硬編碼的 Mock，然後再測試下 Throughput 和 latency，看是否有好轉，如果有，說明函式是瓶頸，再進一步在這個函式體內註釋程式碼，直到找到最耗效能的語句。
• 分析記憶體：需要用到的計數器：Memory 類別 和 Physical Disk 類別的計數器，步驟如下：
  1. 檢視 Memory：Available Mbytes 指標：如果該指標的資料較小，系統可能出現了記憶體方面的問題，需要繼續下面步驟進一步分析。
  2. 注意 Memory：Pages/sec、Pages Read/sec 和 Page Faults/sec 的值：作業系統會利用磁碟較好的方式提高系統可用記憶體量或者提高記憶體的使用效率。這 3 個指標直接反映了 OS 進行磁碟交換的頻度。
     • Pages/sec 值 持續高於幾百，可能記憶體有問題。Pages/sec 值大不一定就表明記憶體有問題，可能是執行使用記憶體對映檔案的應用導致。
     • Page Faults/sec 越高說明每秒發生頁面次數越多，說明 OS 向記憶體讀取的次數越多。此時需要檢視 Pages Read/sec 的計數值，該值閾值是 5，超過 5，則可以判斷存在記憶體方面的問題。
  3. 根據 Physical Disk 計數器的值分析效能瓶頸：需要分析 Page Reads/sec 和 %Disk Time 及 Average Disk Queue Length 的分析。如果 Pages Read/sec 很低，同時 %Disk Time 和 Average Disk Queue Length 的值很高，則可能有磁碟瓶頸。但是，如果佇列長度增加的同時 Pages Read/sec 並未降低，則是記憶體不足
• 分析處理器：
  1. 排查 System：%Total Processor Time 計數器的數值：該值體現的是伺服器 CPU 的整體利用率，對於多核系統而言，該值體現的是所有 CPU 的平均利用率。
     • 如果該值持續超過 90%，說明整個系統面臨著處理器方面的瓶頸，需要增加處理器來提高效能。
     • P.S.：多核下，如果該資料不大，但是各個 CPU 的 負載不均衡，也可以認為是 CPU 產生了瓶頸。
  2. 排查每個 CPU 的 Processor：%Processor Time 和 %User Time 和 %Privileged Time：
     • %Processor Time 很高時，一般 CPU 都阻塞著，但是反之並不亦然。
     • %User Time：非系統核心操作消耗的 CPU 時間（如呼叫系統本身資源--網路、IO等），若該值較大，可以考慮優化程式碼、優化演算法；如果該伺服器是資料庫 Server，則該值較大的話可能是資料庫的”排序“或是”函式操作“消耗了過多的 CPU 時間，此時可考慮對 DB 進行優化。
     • %Privileged Time：系統核心操作消耗的 CPU 時間
  3. 驗證是否系統 CPU 瓶頸：
     • 檢視 System：Processor Queue Length 計數器：如果該值大於 CPU 數量的總數 + 1 的時候，說明產生了處理器阻塞。
       
• 分析磁碟I/O：
  1. 如果計算得出每個磁碟的I/O 超過了磁碟本身的I/O能力，則可以確認磁碟是引起瓶頸的因素之一。
  2. 與 Processor：%Privileged Time 聯合分析：如果 Physical Disk：%Disk Time 較大，其他值比較適中，則硬碟可能是瓶頸，若幾個值都比較大，且持續超過 80%，則可能是記憶體洩漏。
  3. 分析 Disk sec/Transfer：一般來說，該值小於 15ms 為最佳，15~30ms 為良好，30~60ms 為可接受，超過 60ms 則需要考慮更換硬碟或者更換 raid 方式了。
• 分析程序：
  • 檢視 Process：%Processor Time的值：每個程序的該值反映的是程序消耗 CPU 的時間。
  • 檢視 Process：%Page Failures/sec 和 Memory：%Page Failures/sec 的比值，過濾出是哪個程序產生的最多的頁錯誤，一般這個程序是需要大量記憶體的程序，或者是非常活躍的程序（即在壓測情況下，就是你要壓測的程序）
  • Process：%Private Bytes：該計數器指程序所佔有的私有資料（單位位元組），即無法與其他程序共享的資料量，可以利用該值來判斷應用是否存在記憶體洩漏。
    • 對於 IIS 程序，可以重點監控下 INetInfo程序的 Private Bytes，如果在壓測過程中，該值不斷增加，或是在壓測結束後，該值仍然處於一個高水平，則說明應用存在記憶體洩漏
• 分析網路：
  • Network Interface：Bytes Total/sec 為傳送和接收位元組的速率，可以通過該計數器值來判斷網路連結速度是否是瓶頸，具體操作方法是用該計數器的值和目前網路的頻寬進行比較。
  • 聯合 Processor：%Privileged Time 進行分析：如果 Physical Disk：%Disk Time比較大，其他值比較適中，則硬碟可能是瓶頸，若幾個值都比較大，且持續超過 80%，則可能存在記憶體洩漏。

效能優化的幾個策略

• 應用層面：
  • 善用 CDN，快取，冗餘資料，SLB。
  • 如果瓶頸在網路傳輸，那麼需要對傳輸資料進行壓縮（需要注意，壓縮演算法是很耗時的，只在瓶頸是網路傳輸的時候再考慮，你需要根據測試資料自行權衡。）。
  • 並行處理的時候需要注意下宿主機是否是多核。如果宿主機是單核的，而程式程式碼是多程序、多執行緒的，那麼對於高計算密集型的應用會適得其反，反而更慢。
• 優化程式碼：
  • 減少迴圈層數、減少遞迴。
  • 在迴圈體中少做宣告變數、分配 / 釋放記憶體的操作：把迴圈體內的表示式抽離到迴圈體外。
  • 注意函式呼叫在棧上的開銷。
  • 合理使用 try-catch：不要用拋異常作為常規業務的失敗流程（如進行業務報錯）。
  • 字串處理需注意：減少不必要的宣告例項（.net core 出了一個 Span 型別，可以用來替代 Substring。）
  • 不同的語言和程式碼庫，對於複雜度是不一樣的，這個需要注意：如應該用 List.Count==0 來代替List.Any() 來判斷是否有資料。
    • 關於這點，你可以使用計數器來判斷、測試自己寫的程式碼在”耗時、Cpu Cycle，0/1/2代 GC回收“等資料的差異，擇優而定。
• 演算法調優：
  • 雜湊演算法並不高效，使用時候還需注意。
  • 善用預處理和分量分次分批處理：像月報表之類的執行頻率低，但每次執行都很耗資源的，你可以嘗試預先每天/每週處理，不用等到每月才執行。
• 多執行緒調優：
  • 多執行緒的瓶頸主要在互斥和同步鎖上，以及執行緒上下文切換的成本上：你應儘量少用甚至不用鎖，或者用樂觀鎖替代現有直接用 Lock 的鎖。
• 記憶體分配：當記憶體出現碎片時，會相當耗時。
  • 在編碼的時候，意識上儘可能少的進行記憶體的分配。
• 池化技術對於一些短作業來說相當有效：如 HttpClientFactory 就是用了 http 池，可以用來減少物件建立、執行緒建立的開銷。
• 網路調優：
  • TCP 很耗資源，對系統開銷很大：你可以搜尋關鍵字：TCP Tuning 進行相關調優
  • TCP 和 HTTP 要配置下 Keep-Alive，尤其是像 http 這樣的短連線，這也可以在一定程度上防止 DDoS攻擊。
  • 對於 TCP 的 TIME_WAIT，這個狀態預設會持續 4 分鐘（持續 2 個 MSL--Max Segment Lifetime），TIME_WAIT 狀態下的資源不能回收，有大量 TIME_WAIT 連線的情況一般是在 HTTP 伺服器上。
    • 你可以在登錄檔中新建、設定 TCP 的 TcpTimedWaitDelay 和 MaxUserPort 項，來增加 TCP 連線釋放時間和臨時埠數。
  • TCP 一旦發生丟包，TCP 的頻寬使用率會受到影響（盲目減半），再丟包，再減半；什麼時候不丟包了，就會逐步恢復。
• CPU 調優：
  • CPU0 很關鍵， 它一般擔任著調節功能（如核心和非核心操作，上下文切換等），如果 0 號 CPU 被用得過狠的話，別的 CPU 效能也會下降。
    • windows 下可在“工作管理員”中，右鍵“程序”選擇“設定相關性”來設定該程序可以執行在哪些核上。
      • 
    • linux：使用 taskset 命令來設定（可以通過安裝 schedutils 來安裝這個命令） 。

效能監視器

在伺服器上最直觀監視效能的方式就是直接使用系統自帶的”效能監視器“。

>perfmon #直接在 "執行" 中輸入 perfmon 即可開啟

• 若要進一步監控記憶體，可結合使用 RAMMap 和 VMMap 。

windows 下計數器說明：

參考

• Processor queue length：https://social.msdn.microsoft.com/Forums/vstudio/en-US/356b87a3-e8b1-48ad-9355-e68ce3eef754/processor-queue-length?forum=vstest

• Interrupt Time 說明：https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc718984(v=msdn.10)

• 效能計數器：http://www.appadmintools.com/documents/windows-performance-counters-explained/