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都部署在同一个阿里云容器服务ACK集群中，节点实例类型为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%固定采样率略有上升。