Nacos2.0.0-ALPHA2 服务发现性能测试报告
测试目的
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。