目录

一、测试目的

二、测试工具

 三、测试环境

1. 环境

服务端

客户端

2. 启动参数

服务端

客户端

四、测试场景

1. 大规模服务注册后达到稳定状态

场景描述

2. 大规模服务注册达到稳定状态后，部分实例频繁发布

场景描述

五、测试数据

1. 大规模服务注册后达到稳定状态

​编辑 结果分析

2. 大规模服务注册达到稳定状态后，部分实例频繁发布

结果分析

六、测试结论

一、测试目的

Nacos2.0 对连接模型、服务发现的数据模型及运作模式进行了大范围的重构，因此需要在相同或类 似的场景下，了解 Nacos2.0 的服务发现性能负载和容量与 Nacos1.X 的区别，帮助用户更快的运 用评估 Nacos 系统负荷。

本次测试不再仅关注某⼀接口或能力的性能区别，而是期望模拟较真实的大规模使用场景下，Nacos1.X 和 Nacos2.0 服务发现模块的性能区别，提供更加准确的参考。

二、测试工具

我们使用自研的 PAS 性能评估服务平台进行压测，其原理是基于利用 JMeter 引擎，使用 PAS 自动生成的 JMeter 脚本，进行智能压测。

 三、测试环境

1. 环境

服务端

客户端

2. 启动参数

服务端

${JAVA_HOME}/bin/java -DembeddedStorage=true -server -Xms10g -Xmx10g -Xmn4g -XX:Met
aspaceSize=128m -XX:MaxMetaspaceSize=320m -XX:-OmitStackTraceInFastThrow -XX:+HeapD
umpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/nacos/logs/java_heapdump.hpr
of -XX:-UseLargePages -Dnacos.member.list= -Djava.ext.dirs=${JAVA_HOME}/jre/lib/ext:${JAVA
_HOME}/lib/ext -Xloggc:/home/admin/nacos/logs/nacos_gc.log -verbose:gc -XX:+PrintGCDetai
ls -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation -XX:Number
OfGCLogFiles=10 -XX:GCLogFileSize=100M -Dloader.path=/home/admin/nacos/plugins/health, /home/admin/nacos/plugins/cmdb -Dnacos.home=/home/admin/nacos -jar /home/admin/n
acos/target/nacos-server.jar --spring.config.additional-location=file:/home/admin/nacos/conf/
--logging.config=/home/admin/nacos/conf/nacos-logback.xml --server.max-http-header-size=
524288 nacos.nacos

# Nacos1.4.1 的 application.properties 添加下列参数
server.tomcat.max-http-post-size=-1
server.tomcat.max-connections=20000
server.tomcat.max-threads=1000
server.tomcat.accept-count=1000

${JAVA_HOME}/bin/java -Xms4g -Xmx4g -Xmn2g

1. 大规模服务注册后达到稳定状态

场景描述

启动 200 台施压机，每台施压机 500 个线程，每个线程模拟⼀个 nacos 客户端，每个客户端从服务池中随机选择 5 个服务进行注册，随后随机订阅 5 个服务池中的服务；共 10w 个客户端，10w个服务，50w 服务实例，观察注册过程中的服务端性能指标及推送 SLA。

注册完成后放置，达到稳定状态后再观察服务端性能指标，整个过程持续 20min。

之后所有施压机关闭，观察集群注销的服务端性能指标。

1. 大规模服务注册后达到稳定状态

 结果分析

 

Nacos2.0 注册时，有大量的并发注册，因此有大量的推送任务需要同时执行，即使服务端有 500 ms 推送等待并将 500ms 内该服务的变化进行合并，但仍然有大量推送同时推送到客户端中，对 客户端施压机造成比较大的压力，因此推送出现了超时现象，但推送有重试机制，最终会推送成功。由于有部分推送任务发生了重试，且施压机在接受推送时的延迟较高，因此平均 SLA 和 90% SLA 均超过 1s。最大 SLA 出现了超过 10s 的情况， 原因是该客户端推送⼀直超时，重试了很多次， 最终才推送成功。

注销时，由于大量订阅者随着链接断开⼀起被注销，因此推送任务大减，推送 SLA 及失败率均大幅降低。

整个过程中 CPU 和 LOAD 均处于较低水位，且过程中完全没有 Full GC。

整体符合预期。

Nacos 1.X 规模在 200 台机器*大于 200 线程时，服务端无法达到稳定状态，在 500 线程和 250 线程时，Full GC 非常频繁，服务端出现节点间无法正常通信的情况。 大致推算每台服务端 TPS 至少 50w/10/5=1w（单纯心跳），显然有些超出处理能力（最大 tomcat 线程只有 1k，CPU 只 有 8C）。在该场景下，CPU 几乎都是 GC 消耗，因此抖动很大；推送由于 FullGC 几乎全部超时， 客户端测大量连接超时，可以理解为无法支撑这个量级的客户端数和实例数。

当 200 台机器* 100 线程时，服务端处于可用状态，Full GC 不是那么频繁，但实例数达不到稳定 状态，⼀直有实例被移除。推测为心跳无法及时处理，类似 ISSUE 。由于⼀直在摘除实例，又⼀直 由心跳注册实例，因此 CPU ⼀直抖动且数值不低；推送方面，虽然实例⼀直在变更，但是相对比 较分散，所以推送量不大，平均 20～30 次/s，推送是可以成功的。

当 200 * 60 时，服务端很快达到稳定状态，也没有触发 Full GC，CPU 和 LOAD 也都处于低水 位，但是平均每台服务端 6k 个实例，相比 Nacos2.0，仅有约 10%。所以推送也没有太大压力。

稳定状态时依旧有 10% 的 CPU 损耗，主要是心跳请求和客户端每 10s 查询⼀次订阅服务的轮训 请求导致。

总的来说，Nacos2.0，在稳定场景的能力至少是 Nacos1.X 的 9 倍，达到稳定状态后，Nacos2.0 的表现也更加优秀，在客户端和实例数约 10 倍数量的情况下，却有更小的 CPU 消耗。

2. 大规模服务注册达到稳定状态后，部分实例频繁发布

结果分析

Nacos2.0 频繁变更场景的系统指标和批量启动时没有太大的区别，但是推送方面则有很大改善，主 要是不会出现瞬时的单台客户端推送风暴，客户端不会有处理积压和延迟，不再出现推送超时，推送失败率归 0。SLA 主要耗时均在服务端的延迟合并队列中。

 

Nacos1.X 由于 200 * 500 等场景无法达到稳态，因此频繁变更场景直接使用 200 * 60 的压力规 模。

同样，频繁变更场景的系统指标和批量启动时没有太大的区别，比稳态时略高，符合预期。过程中 无 Full GC。

由于 UDP 推送的不可靠性，在推送数量增加后，开始出现无 ack 回复的情况。可见客户端的轮询 查询保证数据⼀致性是非常必要的。

总的来说，Nacos2.0，在频繁变更的场景也能在较大的规模下稳定支撑，能力至少是 Nacos1.X 的9 倍。

六、测试结论

• Nacos2.0 能够较无压力的支撑 10w 级的客户端和 50w 级的服务实例，在模拟实际场景上有较 大的优化，特别是针对 dubbo 的接口级服务发现的单客户端注册多服务的场景，有更大的优化 幅度，符合预期；
• Nacos1.X 能够支撑万级的客户端和数万级的服务实例，平均每台节点的真实场景容量上限约在 6000～7000 实例。符合预期；
• Nacos1.X 和 Nacos2.0 在容量上有较大的差别，Nacos2.0 承载能力至少是 Nacos1.X 的 9 倍；
• 在达到稳态后的频繁变更场景，Nacos1.X 和 Nacos2.0 都没有太大问题。但是 Nacos2.0 在规 模上更大，实际的频繁变更幅度也更大，可见在该场景 Nacos2.0 的性能依旧是 Nacos1.X 的 9 倍。

注意：本次只测试临时实例，未涉及持久实例。