Nacos 性能报告

爱被打了一巴掌 2023-10-09 16:49 19阅读 0赞

![ae5d48e948f6455c800974085f036f62.png][]

**目录**

一、测试目的

二、测试工具

三、测试环境

1. 环境

服务端

客户端

2. 启动参数

服务端

客户端

四、测试场景

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

场景描述

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

场景描述

五、测试数据

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

编辑 结果分析

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

结果分析

六、测试结论

--------------------

## 一、**测试目的** ##

> Nacos2.0 对连接模型、服务发现的数据模型及运作模式进行了大范围的重构，因此需要在相同或类 似的场景下，了解 Nacos2.0 的服务发现性能负载和容量与 Nacos1.X 的区别，帮助用户更快的运 用评估 Nacos 系统负荷。 
> 
> 本次测试不再仅关注某⼀接口或能力的性能区别，而是期望模拟较真实的大规模使用场景下，Nacos1.X 和 Nacos2.0 服务发现模块的性能区别，提供更加准确的参考。

## 二、**测试工具** ##

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

![c44d9eaea1914eabbecd26813e66aa34.png][]

## 三、**测试环境** ##

### 1. 环境  ###

#### 服务端 ####

![6436a432b52d4067a634fc2ef6051086.png][]

#### 客户端 ####

![2c0880e44a2045b485b744719175e942.png][]

### 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. 大规模服务注册后达到稳定状态 ###

![d879e5e1f68a406787d5d251f89a01a2.png][]

![cc2b49b21db54b55a57311cbf2a3d13e.png][]

#### ![2a3aa00da2b34605a34aa324d6ac138e.png][] 结果分析 ####

> 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. 大规模服务注册达到稳定状态后，部分实例频繁发布 ###

![b5943d934e9e4e49ae018a74b9d8a413.png][]

#### 结果分析 ####

> 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 倍。

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

[ae5d48e948f6455c800974085f036f62.png]: https://img-blog.csdnimg.cn/ae5d48e948f6455c800974085f036f62.png
[c44d9eaea1914eabbecd26813e66aa34.png]: https://img-blog.csdnimg.cn/c44d9eaea1914eabbecd26813e66aa34.png
[6436a432b52d4067a634fc2ef6051086.png]: https://img-blog.csdnimg.cn/6436a432b52d4067a634fc2ef6051086.png
[2c0880e44a2045b485b744719175e942.png]: https://img-blog.csdnimg.cn/2c0880e44a2045b485b744719175e942.png
[d879e5e1f68a406787d5d251f89a01a2.png]: https://img-blog.csdnimg.cn/d879e5e1f68a406787d5d251f89a01a2.png
[cc2b49b21db54b55a57311cbf2a3d13e.png]: https://img-blog.csdnimg.cn/cc2b49b21db54b55a57311cbf2a3d13e.png
[2a3aa00da2b34605a34aa324d6ac138e.png]: https://img-blog.csdnimg.cn/2a3aa00da2b34605a34aa324d6ac138e.png
[b5943d934e9e4e49ae018a74b9d8a413.png]: https://img-blog.csdnimg.cn/b5943d934e9e4e49ae018a74b9d8a413.png