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.u1-c1m2.2xlarge，節點的作業系統版本為CentOS Linux release 7.9.2009 (Core) 。
Java應用的Pod規格為2核4G，雙副本。
ARMS探針採用Aliyun JavaAgent 4.1.11版本。
測試流程
在不安裝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 | 5.9% | 12.1% | 57.4 ms |
1000 QPS | 11.1% | 12.3% | 63.2 ms |
2000 QPS | 20.9% | 12.7% | 70.3 ms |
CPU指標代表Pod使用的CPU佔總CPU（2核）的百分比。
記憶體指標代表Pod使用的記憶體佔總記憶體的百分比。由於Pod使用記憶體在達到requests值之前會自然增長，此報告取壓測結束時的記憶體真實佔用。
RT指標代表請求的平均回應時間，單位：毫秒。
安裝ARMS探針後的效能指標
對比項 | 10%採樣率 | 100%採樣率 | ||||
CPU | 記憶體 | RT | CPU | 記憶體 | RT | |
500 QPS | 7.5% | 14.8% | 58.1 ms | 8.9% | 15.2% | 58.2 ms |
1000 QPS | 14.6% | 15.3% | 64.6 ms | 15.5% | 15.9% | 64.8 ms |
2000 QPS | 27.3% | 16.7% | 74.2 ms | 27.8% | 17.4% | 75.8 ms |
採樣率對CPU影響與QPS為非線性關係，預設存在每秒Trace採集上限閾值。
探針效能開銷
對比項 | 10%採樣率 | 100%採樣率 | ||||
CPU | 記憶體 | RT | CPU | 記憶體 | RT | |
500 QPS | +1.6% | +2.7% | +0.7 ms | +3.0% | +3.1% | +0.8 ms |
1000 QPS | +3.5% | +3.0% | +1.4 ms | +4.4% | +3.6% | +1.6 ms |
2000 QPS | +6.4% | +4.0% | +3.9 ms | +6.9% | +4.7% | +5.5 ms |
分析結論
ARMS探針額外造成的CPU和記憶體開銷，都在10%以內。
ARMS探針對於RT（請求回應時間）的影響在10%以內，在1000 QPS的情況下增加約1毫秒。
在100%固定採樣率的情況下，效能開銷比10%固定採樣率略有上升。