如何制定性能調優策略

性能測試攻略

微基準性能測試

宏基準性能測試

熱身問題

多 JVM 情況下的影響

合理分析結果，制定調優策略

性能測試攻略

? ?性能測試是提前發現性能瓶頸，保障系統性能穩定的必要措施。下面我先給你介紹兩種常用的測試方法，幫助你從點到面地測試系統性能。

微基準性能測試

? ?微基準性能測試可以精準定位到某個模塊或者某個方法的性能問題，特別適合做一個功能模塊或者一個方法在不同實現方式下的性能對比。例如，對比一個方法使用同步實現和非同步實現的性能。

宏基準性能測試

宏基準性能測試是一個綜合測試，需要考慮到測試環境、測試場景和測試目標。

首先看測試環境，我們需要模擬線上的真實環境。

? ?然后看測試場景。我們需要確定在測試某個接口時，是否有其他業務接口同時也在平行運行，造成干擾。如果有，請重視，因為你一旦忽視了這種干擾，測試結果就會出現偏差。

? ?最后看測試目標。我們的性能測試是要有目標的，這里可以通過吞吐量以及響應時間來衡量系統是否達標。不達標，就進行優化；達標，就繼續加大測試的并發數，探底接口的 TPS（最大每秒事務處理量），這樣做，可以深入了解到接口的性能。除了測試接口的吞吐量和響應時間以外，我們還需要循環測試可能導致性能問題的接口，觀察各個服務器的 CPU、內存以及 I/O 使用率的變化。

以上就是兩種測試方法的詳解。其中值得注意的是，性能測試存在干擾因子，會使測試結果不準確。所以，我們在做性能測試時，還要注意一些問題。

熱身問題

? ?當我們做性能測試時，我們的系統會運行得越來越快，后面的訪問速度要比我們第一次訪問的速度快上幾倍。這是怎么回事呢？

? ?在 Java 編程語言和環境中，.java 文件編譯成為 .class 文件后，機器還是無法直接運行 .class 文件中的字節碼，需要通過解釋器將字節碼轉換成本地機器碼才能運行。為了節約內存和執行效率，代碼最初被執行時，解釋器會率先解釋執行這段代碼。

? ? 隨著代碼被執行的次數增多，當虛擬機發現某個方法或代碼塊運行得特別頻繁時，就會把這些代碼認定為熱點代碼（Hot Spot Code）。為了提高熱點代碼的執行效率，在運行時，虛擬機將會通過即時編譯器（JIT compiler，just-in-time compiler）把這些代碼編譯成與本地平臺相關的機碼，并進行各層次的優化，然后存儲在內存中，之后每次運行代碼時，直接從內存中獲取即可。

所以在剛開始運行的階段，虛擬機會花費很長的時間來全面優化代碼，后面就能以最高性能執行了。

? ?這就是熱身過程，如果在進行性能測試時，熱身時間過長，就會導致第一次訪問速度過慢，你就可以考慮先優化，再進行測試。

多 JVM 情況下的影響

? ?如果我們的服務器有多個 Java 應用服務，部署在不同的 Tomcat 下，這就意味著我們的服務器會有多個 JVM。任意一個 JVM 都擁有整個系統的資源使用權。如果一臺機器上只部署單獨的一個 JVM，在做性能測試時，測試結果很好，或者你調優的效果很好，但在一臺機器多個 JVM 的情況下就不一定了。所以我們應該盡量避免線上環境中一臺機器部署多個 JVM 的情況。

合理分析結果，制定調優策略

? ?這里我將“三步走”中的分析和調優結合在一起講。

? ?我們在完成性能測試之后，需要輸出一份性能測試報告，幫我們分析系統性能測試的情況。其中測試結果需要包含測試接口的平均、最大和最小吞吐量，響應時間，服務器的 CPU、內存、I/O、網絡 IO 使用率，JVM 的 GC 頻率等。

? 通過觀察這些調優標準，可以發現性能瓶頸，我們再通過自下而上的方式分析查找問題。首先從操作系統層面，查看系統的 CPU、內存、I/O、網絡的使用率是否存在異常，再通過命令查找異常日志，最后通過分析日志，找到導致瓶頸的原因；還可以從 Java 應用的 JVM 層面，查看 JVM 的垃圾回收頻率以及內存分配情況是否存在異常，分析日志，找到導致瓶頸的原因。

? ?如果系統和 JVM 層面都沒有出現異常情況，我們可以查看應用服務業務層是否存在性能瓶頸，例如 Java 編程的問題、讀寫數據瓶頸等等。分析查找問題是一個復雜而又細致的過程，某個性能問題可能是一個原因導致的，也可能是幾個原因共同導致的結果。我們分析查找問題可以采用自下而上的方式，而我們解決系統性能問題，則可以采用自上而下的方式逐級優化。下面我來介紹下從應用層到操作系統層的幾種調優策略。