4.x版本Java探針持續剖析效能壓測報告

測試情境

整體架構如下圖所示：

Java應用基於Spring MVC架構編寫，根據壓測源發起的不同請求，會分別訪問MySQL和Redis服務。對於請求${mall-gateway}/case/api/v1/mysql/execute，Java應用會訪問MySQL（每接到一次請求，會訪問1~4次MySQL）；對於請求${mall-gateway}/case/api/v1/redis/execute，Java應用會訪問Redis（每接到一次請求，會訪問1~10次Redis）。兩種請求各佔50%的QPS。

測試環境

• 壓測源由阿里雲效能測試服務PTS提供。

• Java應用、MySQL、Redis都部署在同一個阿里雲Container ServiceACK叢集中，節點執行個體類型為ecs.u1-c1m2.8xlarge，節點的作業系統版本為Alibaba Cloud Linux 2.1903 LTS 64位。

• Java應用的Pod規格為2核4G，雙副本。

• ARMS探針採用Aliyun JavaAgent 4.2.1版本。

• Demo程式碼程式庫

測試流程

1. 安裝ARMS探針後，在採樣原則設定為10%固定採樣率的情況下，分別使用基於500/1000/2000 QPS，發起3次壓測，每次的持續時間長度為1小時，每次壓測前都先基於50 QPS壓測流量對Java應用進行5分鐘預熱，然後運行30分鐘，待各項資料穩定以後，動態開啟持續剖析所有功能（CPU熱點、記憶體熱點和代碼熱點功能）繼續運行30分鐘，觀察開啟持續剖析前後應用的各項效能指標（CPU開銷、記憶體開銷、RT）上的差異情況。

2. 安裝ARMS探針後，在採樣原則設定為100%固定採樣率的情況下，重複第1步的壓測，對比Java應用在CPU開銷、記憶體開銷、RT上的差異。

未開啟持續剖析效能指標

開啟持續剖析效能指標

持續剖析效能開銷

分析結論

1. 持續剖析所有子功能全部開啟的情況下，CPU和記憶體等開銷都在5%以內。如果僅開啟部分功能，例如代碼熱點，開銷會更低。

2. 持續剖析對應用延時影響較小，在一般壓力情境下，開啟持續剖析前後無明顯變化。