ARMS 探针在应用运行时为应用提供持续剖析能力。与其他类似采集工具一样，持续剖析功能会带来一定的应用性能开销，但ARMS团队已经采用多项技术对其进行优化，将相关性能开销降低到极低的范围，以确保应用的稳定运行。在本篇测试报告中，我们模拟了真实的使用场景，测试ARMS持续剖析在不同业务流量下带来的性能开销，您可以参考本篇分析报告，在使用ARMS持续剖析前，基于性能影响进行充分的评估。
测试场景
整体架构如下图所示：
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都部署在同一个阿里云容器服务ACK集群中，节点实例类型为ecs.u1-c1m2.8xlarge，节点的操作系统版本为Alibaba Cloud Linux 2.1903 LTS 64位。
Java应用的Pod规格为2核4G，双副本。
ARMS探针采用Aliyun JavaAgent 4.2.1版本。
测试流程
安装ARMS探针后，在采样策略设置为10%固定采样率的情况下，分别使用基于500/1000/2000 QPS，发起3次压测，每次的持续时长为1小时，每次压测前都先基于50 QPS压测流量对Java应用进行5分钟预热，然后运行30分钟，待各项数据稳定以后，动态开启持续剖析所有功能（CPU热点、内存热点和代码热点功能）继续运行30分钟，观察开启持续剖析前后应用的各项性能指标（CPU开销、内存开销、RT）上的差异情况。
安装ARMS探针后，在采样策略设置为100%固定采样率的情况下，重复第1步的压测，对比Java应用在CPU开销、内存开销、RT上的差异。
未开启持续剖析性能指标
对比项 | 10%采样率 | 100%采样率 | ||||
CPU | 内存 | RT | CPU | 内存 | RT | |
500 QPS | 8.112% | 13.52% | 55.5 ms | 8.416% | 13.62% | 56.5ms |
1000 QPS | 15.247% | 14.14% | 62.9 ms | 15.614% | 14.42% | 65.3 ms |
2000 QPS | 30.550% | 14.64% | 70.6 ms | 30.945% | 14.67% | 71.1 ms |
开启持续剖析性能指标
对比项 | 10%采样率 | 100%采样率 | ||||
CPU | 内存 | RT | CPU | 内存 | RT | |
500 QPS | 8.912% | 15.52% | 55.6 ms | 9.316% | 15.71% | 56.6 ms |
1000 QPS | 17.140% | 16.24% | 63.0 ms | 17.710% | 16.82% | 65.4 ms |
2000 QPS | 34.650% | 16.84% | 70.7 ms | 35.245% | 16.89% | 71.3 ms |
持续剖析性能开销
对比项 | 10%采样率 | 100%采样率 | ||||
CPU | 内存 | RT | CPU | 内存 | RT | |
500 QPS | +0.80% | +2.00% | +0.1 ms | +0.90% | +2.09% | +0.1 ms |
1000 QPS | +1.893% | +2.10% | +0.1 ms | +2.096% | +2.40% | +0.1 ms |
2000 QPS | +4.10% | +2.20% | +0.1 ms | +4.30% | +2.22% | +0.2 ms |
分析结论
持续剖析所有子功能全部开启的情况下，CPU和内存等开销都在5%以内。如果仅开启部分功能，例如代码热点，开销会更低。
持续剖析对应用延时影响较小，在一般压力场景下，开启持续剖析前后无明显变化。