適用於需要進行性能分析及調優的工作。預期讀者爲測試管理人員、測試實施人員、技術支持人員、項目質量管理人員、項目管理人員等系統技術質量相關人員。

2|0 性能分析

前提

• 性能分析的前提除了需要豐富的性能測試監控（如 PTS 自身的客戶側監控、基礎類監控 - 阿里雲監控、應用類監控 - ARMS 監控等），還需要具備相關的技術知識（包括但不限於：操作系統、中間件、數據庫、開發等）。

流程

• 很多情況下壓測流量並沒有完全進入到後端（服務端），在網絡接入層（雲化的架構，例如：SLB/WAF / 高防 IP，甚至是 CDN / 全站加速等）可能就會出現由於各種規格（帶寬、最大連接數、新建連接數等）限制或者因爲壓測的某些特徵符合 CC 和 DDoS 的行爲而觸發了防護策略導致壓測結果達不到預期。

• 接着看關鍵指標是否滿足要求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務器端問題可能性比較大，也有可能是客戶端問題（這種情況非常小）。

• 對於服務器端問題，需要定位的是硬件相關指標，例如 CPU，Memory，Disk I/O，Network I/O，如果是某個硬件指標有問題，需要深入的進行分析。

• 如果硬件指標都沒有問題，需要查看中間件相關指標，例如：線程池、連接池、GC 等，如果是這些指標問題，需要深入的分析。

• 如果中間件相關指標沒問題，需要查看數據庫相關指標，例如：慢查 SQL、命中率、鎖、參數設置。

• 如果以上指標都正常，應用程序的算法、緩衝、緩存、同步或異步可能有問題，需要具體深入的分析。

具體如下圖所示：

可能瓶頸點

• 硬件、規格上的瓶頸

• 一般指的是 CPU、內存、磁盤 I/O 方面的問題，分爲服務器硬件瓶頸、網絡瓶頸（對局域網可以不考慮）。

• 中間件上的性能瓶頸

• 一般指的是應用服務器、web 服務器等應用軟件，還包括數據庫系統。例如：中間件 weblogic 平臺上配置的 JDBC 連接池的參數設置不合理，造成的瓶頸。

• 應用程序上的性能瓶頸

• 一般指的是開發人員開發出來的應用程序。例如，JVM 參數不合理，容器配置不合理，慢 SQL（可使用阿里雲 APM 類產品如 ARMS 協助定位），數據庫設計不合理，程序架構規劃不合理，程序本身設計有問題（串行處理、請求的處理線程不夠、無緩衝、無緩存、生產者和消費者不協調等），造成系統在大量用戶訪問時性能低下而造成的瓶頸。

• 操作系統上的性能瓶頸

• 一般指的是 windows、UNIX、Linux 等操作系統。例如，在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大降低，從而導致行爲的響應時間大大增加，這時認爲操作系統上出現性能瓶頸。

• 網絡設備上的性能瓶頸

• 一般指的是防火牆、動態負載均衡器、交換機等設備。當前更多的雲化服務架構使用的網絡接入產品：包括但不限於 SLB、WAF、高防 IP、CDN、全站加速等等。例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將後續的交易請求發送到其他負載較輕的應用服務器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認爲網絡瓶頸。

方法

CPU

CPU 資源利用率很高的話，需要看 CPU 消耗 User、Sys、Wait 哪種狀態。

• 如果 CPU User 非常高，需要查看消耗在哪個進程，可以用 top（linux）命令看出，接着用 top –H –p 看哪個線程消耗資源高。

• 如果是 Java 應用，就可以用 jstack 看出此線程正在執行的堆棧，看資源消耗在哪個方法上，查看源代碼就知道問題所在；如果是 c++ 應用，可以用 gprof 性能工具進行分析。

• 如果 CPU Sys 非常高，可以用 strace（linux）看系統調用的資源消耗及時間。

• 如果 CPU Wait 非常高，考慮磁盤讀寫了，可以通過減少日誌輸出、異步或換速度快的硬盤。

• Memory

操作系統爲了最大化利用內存，一般都設置大量的 cache，因此，內存利用率高達 99% 並不是問題，內存的問題主要看某個進程佔用的內存是否非常大以及是否有大量的 swap（虛擬內存交換）。

• 磁盤 I/O

磁盤 I/O 一個最顯著的指標是繁忙率，可以通過減少日誌輸出、異步或換速度快的硬盤來降低繁忙率。

• 網絡 I/O

網絡 I/O 主要考慮傳輸內容大小，不能超過硬件網絡傳輸的最大值 70%，可以通過壓縮減少內容大小、在本地設置緩存以及分多次傳輸等操作提高網絡 I/O 性能。

• 內核參數

內核參數一般都有默認值，這些內核參數默認值對於一般系統沒問題，但是對於壓力測試來說，可能運行的參數將會超過內核參數，導致系統出現問題，可以用 sysctl 來查看及修改。

• JVM

JVM 主要分析 GC/FULL GC 是否頻繁，以及垃圾回收的時間，可以用 jstat 命令來查看，對於每個代大小以及 GC 頻繁，通過 jmap 將內存轉儲，再借助工具 HeapAnalyzer 來分析哪地方佔用的內存較高以及是否有內存泄漏可能。簡單點可以使用 APM 工具，例如阿里雲 ARMS。

• 線程池

如果線程不夠用，可以通過參數調整，增加線程；對於線程池中的線程設置比較大的情況，還是不夠用可能的原因是：某個線程被阻塞來不及釋放，可能在等鎖、方法耗時較長、數據庫等待時間很長等原因導致，需要進一步分析才能定位。

• JDBC 連接池

連接池不夠用的情況下，可以通過參數進行調整增加；但是對於數據庫本身處理很慢的情況下，調整沒有多大的效果，需要查看數據庫方面以及因代碼導致連接未釋放的原因。

• SQL

SQL 效率低下也是導致性能差的一個非常重要的原因，可以通過查看執行計劃看 SQL 慢在哪裏，一般情況，SQL 效率低下原因主要有：

3|0 調優

調優步驟

確定問題

• 應用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對於發現瓶頸的模塊，應該首先檢查一下代碼。

• 數據庫配置：經常引起整個系統運行緩慢，一些諸如大型數據庫都是需要 DBA 進行正確的參數調整才能投產的。

• 操作系統配置：不合理就可能引起系統瓶頸。

• 硬件設置：硬盤速度、內存大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。

• 網絡：網絡負載過重導致網絡衝突和網絡延遲。

分析問題

• 當確定了問題之後，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？

• 是多數用戶還是少數用戶遇到了問題？如果是少數用戶，這幾個用戶與其它用戶的操作有什麼不同？

• 系統資源監控的結果是否正常？CPU 的使用是否到達極限？I/O 情況如何？

• 問題是否集中在某一類模塊中？

• 是客戶端還是服務器出現問題？系統硬件配置是否夠用？

• 實際負載是否超過了系統的負載能力？是否未對系統進行優化？

通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的瞭解，進而分析出真正的原因。

• 確定調整目標和解決方案

高系統吞吐量，縮短響應時間，更好地支持併發。

• 測試解決方案

對通過解決方案調優後的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試對象的某項性能指標進行定量的和可對比的測試）。

• 分析調優結果

系統調優是否達到或者超出了預定目標；系統是整體性能得到了改善，還是以系統某部分性能來解決其他問題；調優是否可以結束了。最後，如果達到了預期目標，調優工作可以先告一段落。

調優注意事項

• 在應用系統的設計開發過程中，應始終把性能放在考慮的範圍內，將性能測試常態化，日常化的內網的性能測試 + 定期的真實環境的業務性能測試，PTS 都可以支持。

• 確定清晰明確的性能目標是關鍵，進而將目標轉化爲 PTS 中的壓測場景並設置好需要的目標量級，然後視情況選擇併發、TPS 模式，自動遞增 / 手工調速的組合進行流量控制。

• 必須保證調優後的程序運行正確。

• 系統的性能更大程度上取決於良好的設計，調優技巧只是一個輔助手段。

• 調優過程是迭代漸進的過程，每一次調優的結果都要反饋到後續的代碼開發中去。

• 性能調優不能以犧牲代碼的可讀性和可維護性爲代價。

來源：

https://www.toutiao.com/a7029571614383817229/?log_from=f838c29923f9c_1636939626747

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/LzaVP0iq9jMrblfLNChxzg