目录
一、测试目的
二、测试工具
三、测试环境
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
注意： Nacos2.0.0-BETA 服务端关闭升级用的双写。
客户端
${JAVA_HOME}/bin/java -Xms4g -Xmx4g -Xmn2g四、测试场景
1. 大规模服务注册后达到稳定状态
场景描述
启动 200 台施压机，每台施压机 500 个线程，每个线程模拟⼀个 nacos 客户端，每个客户端从服务池中随机选择 5 个服务进行注册，随后随机订阅 5 个服务池中的服务；共 10w 个客户端，10w个服务，50w 服务实例，观察注册过程中的服务端性能指标及推送 SLA。注册完成后放置，达到稳定状态后再观察服务端性能指标，整个过程持续 20min。之后所有施压机关闭，观察集群注销的服务端性能指标。
2. 大规模服务注册达到稳定状态后，部分实例频繁发布
场景描述
再次运行上述测试场景，当注册服务达到稳定状态后， 对其中 10～20% 的实例，每隔 10 秒进行 ⼀次变更（重新注册或注销再注册）。测试服务端在频繁发布/上下线场景下的系统指标和推送情况。持续进行 30min。
五、测试数据
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 倍。
注意：本次只测试临时实例，未涉及持久实例。
