記一次接口壓力測試與性能調優

〇、經驗總結

1.如果總的CPU占用率偏高，且基本都被業務線程占用時，CPU占用率過高的原因跟JVM參數大小沒有直接關系，而跟具體的業務邏輯有關。
2.當設置JVM堆內存偏小時，GC頻繁會導致業務線程停頓增多，TPS下降，最后CPU占用率也低了；
3.當設置JVM堆內存偏大時，GC次數下降，TPS上升，CPU占用率立刻上升。
4.Dom4J 這個xml解析工具性能很強大，但在處理節點和層級都較多的xml文本時，整體解析效率依然會成為業務處理瓶頸。

一、背景說明

最近新項目上線，需要對項目中的一個HTTP接口進行壓力測試，以保證接口性能穩定性。該接口涉及到的主要業務是接收HTTP請求，獲取請求中的xml報文參數，并將xml報文解析后存入MySQL數據庫。接口業務流程如下：

該業務接口部署的服務器配置和部署MySQL組件的服務器配置一致，都是4核8G，50G普通硬盤，并且處于同一個內網網段，我們預估的性能指標要達到200并發，500TPS。
在壓力測試過程中，我們重點關注TPS、GC次數、CPU占用率和接口響應時間等指標。

二、測試過程

完成項目部署后，我們開始編輯jemeter測試腳本，設置壓力測試的標準為200個并發線程，在10秒內全部啟動，持續壓測時間15分鐘，接著開始啟動jemeter腳本進行測試。

1、第一次壓力測試

（1）JVM配置

垃圾收集策略包括：老年代啟用CMS垃圾收集算法，新生代啟用ParNew垃圾收集算法，新生代最大存活周期為15次minorGC，FullGC時使用CMS算法，并開啟CMS中的并行標記。
JVM內存分配：最大/最小堆內存為512MB，Eden和Survivor比例為8:2，永久代初始化64MB，最大128MB。
JVM配置參數如下：
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=15 -XX:+ExplicitGCInvokesConcurrent
-XX:+CMSParallelRemarkEnabled -Xms512m -Xmx512m -XX:SurvivorRatio=8 -XX:PermSize=64m -XX:MaxPermSize=128m

（2）性能指標監控

top命令觀察java線程的CPU占用率(us表示用戶進程，sy表示系統進程)：

jemeter工具輸出的TPS和接口響應時間：

jstat -gcutil {pid} {period_time} 輸出GC情況

我們根據上述指標監控的情況可以看出，目前CPU占用率很高，每個CPU上的業務線程都占用了90%以上的CPU時間，年輕代GC次數頻繁，平均每秒鐘有8次左右，但TPS目前只有400左右。
一開始看到這個情況，我們以為是JVM堆內存分配的不足，導致GC頻繁，從而引起CPU的高占用率。所以我們調大了堆內存參數，并進行第二次壓力測試。

2、第二次壓力測試

（1）JVM配置

JVM內存分配：最大/最小堆內存為2048MB，Eden和Survivor比例為8:2，永久代初始化512MB，最大512MB。
JVM配置參數如下：
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:MaxTenuringThreshold=15 -XX:+ExplicitGCInvokesConcurrent
-XX:+CMSParallelRemarkEnabled -Xmx2048m -Xms2048m -Xmn1024m -XX:NewSize=640m -XX:MaxNewSize=640m
-XX:SurvivorRatio=8 -XX:PermSize=512m -XX:MaxPermSize=512m

（2）性能指標監控

top命令觀察java線程的CPU占用率(us表示用戶進程，sy表示系統進程)：

jemeter工具輸出的TPS和接口響應時間：

jstat -gcutil {pid} {period_time} 輸出GC情況:

根據上述指標監控的情況可以看出，這次JVM參數調整后，隨著堆內存擴大，年輕代GC次數降低了，平均每秒有2次左右，TPS提高到600左右。但是CPU占用率依然很高，且都為業務進程占用。
從這個性能結果來看，堆內存的增大，可以降低GC頻率，提高TPS。但CPU占用率幾乎沒有變化，可能的原因預計有兩個：
第一、業務邏輯中存在耗CPU的計算操作；
第二、業務代碼存在鎖，導致大量線程在等待鎖。
根據這個猜測，我們決定打印出JVM線程快照，看下能否找到線程等待鎖的相關信息。
jstack -l {pid} > /log_dir/stack_log.txt 命令輸出線程快照信息到指定的目錄文件。
在線程快照文件里查找狀態為BLOCKED的線程記錄，發現出現較多BLOCKED狀態的線程是：

從線程快照來看，大量xml解析線程處于BLOCKED狀態，xml解析的業務處于阻塞狀態，降低了接口處理效率。

接著我們把接口代碼中其他邏輯代碼屏蔽，只留下xml解析代碼，發現CPU占用率依然在90%以上，而一旦把xml解析代碼屏蔽，留下其他業務代碼，CPU占用率馬上降低到了70%，TPS上升，GC次數下降并保持穩定。

從上面這些處理的結果來看，CPU占用率過高的原因跟JVM參數大小沒有直接關系，而跟xml參數解析有關，因為xml參數報文包含十幾個節點，層級也較多，解析后生成的都是比較復雜的大對象。
當設置JVM堆內存偏小時，GC頻繁會導致業務線程停頓，TPS下降，最后CPU占用率也低了；
當設置JVM堆內存偏大時，GC次數下降，TPS上升，CPU占用率立刻升高到95%以上。
由于我們對xml參數解析使用的是dom4j的方法，所以沒辦法在xml解析上面進行優化，只能在JVM參數和并發數上進行處理。
最終為了平衡CPU占用率、TPS、GC三個方面的指標，考慮業務實際場景，我們設置JVM堆內存為1.5G，限制TPS為200。