Nacos 2.0 服务发现性能测试报告
测试目的
Nacos2.0对连接模型，服务发现的数据模型也运作模式进行了大范围的重构，因此需要在相同或类似的场景下，了解Nacos2的服务发现性能负载和容量与Nacos1的区别，帮助用户更快的运用评估Nacos系统负荷。
Nacos1.0性能测试参考 服务发现性能测试报告
测试工具
我们使用自研的PAS性能评估服务平台进行压测，其原理是基于利用JMeter引擎，使用PAS自动生成的JMeter脚本，进行智能压测。
测试环境
1. 环境
| 指标 | 参数 |
|---|---|
| 机器 | CPU 8核，内存16G |
| 集群规模 | 3节点 |
| Nacos版本 | 服务端：Nacos2.0.0-ALPHA2， 客户端：Nacos2.0.0-ALPHA2 |
2.设置启动参数
${JAVA_HOME}/bin/java -DembeddedStorage=true -server -Xms10g -Xmx10g -Xmn4g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=320m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/nacos/logs/java_heapdump.hprof -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:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -Dloader.path=/home/admin/nacos/plugins/health,/home/admin/nacos/plugins/cmdb -Dnacos.home=/home/admin/nacos -jar /home/admin/nacos/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
测试场景
以下测试场景都是服务发现重要接口：
- 验证Nacos服务发现注册实例的能力
- 验证Nacos服务发现查询实例的能力
- 验证Nacos服务发现注销实例的能力
测试数据
1. 注册实例
施压机模拟100个客户端同时发起注册服务，每个客户端一条长连接，每个客户端注册1W个服务。总数100W个服务及实例。
注册完成之后每个客户端继续不停进行注册请求，模拟重复注册请求（会进行更新替换），同时记录下整个过程中的相关数据。
相关API
NamingService.registerInstance(String serviceName, Instance instance)
结果数据如下
| 施压机数量 | 每台线程数 | 平均TPS | 平均RT | 最小RT | 最大RT | 80%RT(ms) | 95%RT(ms) | 99%RT(ms) | CPU使用率 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 100 | 7256.32 | 13.14 | 0.39 | 2522.25 | 6.72 | 12.86 | 126.33 | 80% |
| 2 | 50 | 16418.04 | 5.8 | 0.41 | 3906.77 | 4.0 | 8.88 | 48.84 | 90% |
| 5 | 20 | 26784.84 | 3.6 | 0.38 | 1606.41 | 3.82 | 8.91 | 30.62 | 90% |
结果分析
相较Nacos1.X版本，注册性能总体提升至少2倍，在服务端机能减半的情况下，服务实例数基本一致的情况下，TPS仍能做到2倍左右的提高。
2. 查询实例
施压机先模拟发起注册服务，总数10W个服务，每个服务10个实例，总数100W实例。
注册完成后，模拟100个客户端同时不停进行随机服务查询请求，并且有实例长度校验。同时记录下整个过程中的相关数据。
相关API
NacosNamingService.getAllInstances(String serviceName, boolean subscribe)
注意 subscribe 为 false 进行测试，否则将会优先查询客户端缓存。
结果数据如下
| 施压机数量 | 每台线程数 | 平均TPS | 平均RT | 最小RT | 最大RT | 80%RT(ms) | 95%RT(ms) | 99%RT(ms) | CPU使用率 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 100 | 12998.46 | 7.54 | 0.55 | 213.86 | 9.68 | 10.69 | 27.92 | 40% |
| 2 | 50 | 12785.01 | 7.93 | 0.38 | 900.48 | 8.34 | 14.18 | 33.04 | 40% |
| 2 | 100 | 18451.78 | 10.63 | 0.6 | 829.42 | 11.95 | 23.79 | 44.19 | 45% |
| 5 | 20 | 30680.48 | 3.12 | 0.46 | 1138.38 | 4.33 | 5.9 | 9.57 | 50% |
结果分析
相较Nacos1.X版本，查询性能总体提升至少3倍，在服务端机能减半的情况下，服务实例数基本一致的情况下，TPS仍能做到3倍左右的提高，单机多线程场景甚至有10倍的提升。
3. 注销实例
施压机先模拟100个客户端同时发起注册服务，每个客户端一条长连接，每个客户端注册1W个服务。总数100W个服务及实例。
注册完成后，模拟使用相同100个客户端同时不停进行随机服务注销请求，同时记录下整个过程中的相关数据。
相关API
NacosNamingService.deregisterInstance(String serviceName, String ip, int port)
结果数据如下
| 施压机数量 | 每台线程数 | 平均TPS | 平均RT | 最小RT | 最大RT | 80%RT(ms) | 95%RT(ms) | 99%RT(ms) | CPU使用率 |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 100 | 9614.96 | 9.88 | 0.41 | 1115.27 | 8.85 | 15.32 | 104.76 | 70% |
| 2 | 50 | 22252.07 | 4.28 | 0.39 | 856.1 | 4.03 | 5.65 | 31.02 | 90% -> 60% |
| 5 | 20 | 29393.8 | 2.55 | 0.42 | 741.09 | 2.67 | 8.91 | 15.85 | 90% -> 60% |
结果分析
相较Nacos1.X版本，注销性能总体提升至少2倍，在服务端机能减半的情况下，服务实例数基本一致的情况下，TPS仍能做到2倍左右的提高。 关于CPU由90% 降低为 60%的场景， 是由于随着注销的的服务和实例增多，重复注销的操作变得频繁，未命中服务和实例的操作会被快速返回且操作量小，因此CPU下降、TPS相对注册略高。
测试结论
Nacos2服务发现性能测试都是针对重点功能，通过对3节点规模集群进行压测，可以看到接口性能负载和容量，以及对比相同/类似场景下Nacos1.X版本的提升。
- 压测时服务及实例容量达到百万级，集群运行持续稳定，达到预期；（该场景没有计算频繁变更导致的频繁推送内容，仅单纯计算容量上线，附带推送的真实场景将在下轮压测报告中给出）
- 注册/注销实例TPS达到 26000 以上，总体较Nacos1.X提升至少2倍，接口达到预期；
- 查询实例TPS能够达到 30000 以上，总体较Nacos1.X提升3倍左右，接口达到预期；
注意
- 本次只测试临时实例注册/查询/注销，未涉及持久实例；
- 本测试为对比Nacos1.X版本的测试场景，仅测试单核心接口的能力值，真实模拟场景压测 将在后续版本给出；
- 本测试供给大家作为参考，如有不足或偏差，请指正! 如果对性能有其他需求，可以给我们提issue。