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

原文地址（樣式排版上更好點） ：https://blog.zhuliang.ltd/2019/08/server/test-with-perfmon.html

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

• 瞭解常見的系統瓶頸的可能原因。
• 通過性能探查器定位性能瓶頸。
• 幾點關於性能優化的策略。
• 一份關於 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/