ARMS探針在應用運行態進行位元組碼增強，實現應用效能管理能力。與其他通過位元組碼增強技術實現的效能管理方案一樣，ARMS探針會帶來一定的應用效能開銷，但ARMS團隊已經採用多項技術對探針進行最佳化，將探針的效能開銷降低到極低的範圍，以確保應用的穩定運行。在本篇測試報告中，我們類比了真實的使用情境，測試ARMS探針在不同業務流量下帶來的效能開銷，您可以參考本篇分析報告，在接入ARMS應用監控前，基於效能影響進行充分的評估。
測試情境
整體架構如下圖所示：
Java應用基於Spring MVC架構編寫，根據壓測源發起的不同請求，會分別訪問MySQL和Redis服務。對於請求${mall-gateway}/case/api/v1/mysql/execute，Java應用會訪問MySQL；對於請求${mall-gateway}/case/api/v1/redis/execute，Java應用會訪問Redis。兩種請求各佔50%的QPS。
測試環境
壓測源由阿里雲效能測試服務PTS提供。
Java應用、MySQL、Redis都部署在同一個阿里雲Container ServiceACK叢集中，節點執行個體類型為ecs.c6.2xlarge，節點的作業系統版本為CentOS Linux release 7.9.2009 (Core) 。
Java應用的Pod規格為2核4G，雙副本。
ARMS探針採用Aliyun JavaAgent 3.1.4 版本。
測試流程
在不安裝ARMS探針的情況下，分別使用基於500 / 1000 / 2000 QPS，發起3次壓測，每次的持續時間長度為1小時，每次壓測前都先基於100 QPS壓測流量對Java應用進行3分鐘預熱，壓測結果將作為基準效能指標。
安裝ARMS探針，在採樣原則設定為10%固定採樣率的情況下，重複第1步的壓測，對比Java應用在CPU開銷、記憶體開銷、RT上的差異。
安裝ARMS探針，在採樣原則設定為100%固定採樣率的情況下，重複第1步的壓測，對比Java應用在CPU開銷、記憶體開銷、RT上的差異。
關於ARMS的採樣原則設定，請參見調用鏈取樣模式選擇（3.2.8以下探針版本）。
ARMS應用監控的準系統都將開啟，包括統計指標、調用鏈、分位元等，並開啟所有外掛程式功能。
基準效能指標
對比項 | CPU | 記憶體 | RT |
500 QPS | 6.50% | 14.49% | 2ms |
1000 QPS | 17.01% | 14.86% | 2ms |
2000 QPS | 32.36% | 19.04% | 2ms |
CPU指標代表Pod使用的CPU佔總CPU的百分比。
記憶體指標代表Pod使用的記憶體佔總記憶體的百分比。由於Pod使用記憶體在達到requests值之前會自然增長，此報告取壓測結束時的記憶體真實佔用。
RT指標代表請求的平均回應時間，單位：毫秒。
安裝ARMS探針後的效能指標
對比項 | 10%採樣率 | 100%採樣率 | ||||
CPU | 記憶體 | RT | CPU | 記憶體 | RT | |
500 QPS | 7.72% | 18.37% | 2ms | 7.90% | 18.83% | 2ms |
1000 QPS | 19.94% | 18.95% | 2ms | 20.78% | 19.61% | 2ms |
2000 QPS | 40.49% | 25.69% | 3ms | 42.25% | 25.80% | 3ms |
探針效能開銷
對比項 | 10%採樣率 | 100%採樣率 | ||||
CPU | 記憶體 | RT | CPU | 記憶體 | RT | |
500 QPS | +1.21% | +3.88% | - | +1.39% | +4.35% | - |
1000 QPS | +2.92% | +4.09% | - | +3.76% | +4.75% | - |
2000 QPS | +8.13% | +6.66% | +1ms | +9.89% | +6.76% | +1ms |
分析結論
ARMS探針額外造成的CPU和記憶體開銷，都在10%以內。
ARMS探針對於RT（請求回應時間）的影響非常小，在2000 QPS的情況下僅增加了1毫秒。
在100%固定採樣率的情況下，效能開銷比10%固定採樣率略有上升。