跳转到内容
云原生开源开发者沙龙 | AI 应用工程化专场杭州站邀您参会点此了解

Nacos2.0服务配置性能测试报告

Nacos 2.0.0-ALPHA2 配置性能测试报告

测试目的

  1. 长链接各项业务指标的最高值
  2. 长链接相比短链接的差异数据对比

测试工具

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

Pas图

测试环境

1.环境

指标参数
机器CPU 8核,内存16G
集群规模单机
Nacos版本Nacos 2.0.0-ALPHA2, Nacos 1.4.0
数据库32C128G

2.设置启动参数

因为grpc使用的直接内存,堆内存相对使用较少,所以jvm参数有所调整

Nacos2.0 gRPC

JAVA_OPT="${JAVA_OPT} -server -Xms9216m -Xmx9216m -XX:MaxDirectMemorySize=4096m -XX:NewSize=4096m -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics -DisPushContent=false -XX:MaxNewSize=4096m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/nacos/logs/java_heapdump.hprof -XX:-UseLargePages -Xloggc:/home/admin/nacos/logs/nacos_gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -DQUERYTIMEOUT=90 -XX:SurvivorRatio=10 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/nacos/logs -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:CMSMaxAbortablePrecleanTime=5000 -XX:CMSInitiatingOccupancyFraction=74 -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=8 -Dnacos.core.auth.enabled=false "

Nacos1.X HTTP

-server -Xms12880m -Xmx12880m -XX:MaxDirectMemorySize=1024m -XX:NewSize=1024m -XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics -DisPushContent=false -XX:MaxNewSize=4096m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/nacos/logs/java_heapdump.hprof -XX:-UseLargePages -Xloggc:/home/admin/nacos/logs/nacos_gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M -DQUERYTIMEOUT=90 -XX:SurvivorRatio=10 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/admin/nacos/logs -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:CMSMaxAbortablePrecleanTime=5000 -XX:CMSInitiatingOccupancyFraction=74 -XX:+UseCMSInitiatingOccupancyOnly -XX:ParallelGCThreads=8 -Dnacos.core.auth.enabled=false -Dnacos.member.list= -Djava.ext.dirs=/opt/taobao/java/jre/lib/ext:/opt/taobao/java/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

测试场景

以下测试场景都是服务配置重要接口:

  • 验证Nacos服务发布配置的能力
  • 验证Nacos服务获取配置的能力
  • 验证Nacos服务监听配置的能力
  • 验证Nacos服务长连接容量能力

测试方式均是在相同的环境下,使用相同的压力进行测试,分别比对Nacos2.X版本和Nacos1.X版本的性能差异。

测试数据

1. 发布配置

Nacos2.0

tps500100012001500200025003000
avg rt(ms)78129910.891044
80% rt(ms)7.98119910.691581
95% rt(ms)8.71125151424.742966
cpu12222836475562
load0.51.51.51.53.545

Nacos1.X

tps500100012001400200025003000
avg rt(ms)98.67891011.881038
80% rt(ms)99.41091012.481090
95% rt(ms)1111.412141825.71170
cpu14253035506065
load0.91.422.532.53.7

结果分析

发布配置两者差别不大,TPS 在2500tps左右出现拐点,http和长链接通道的cpu消耗分布类似。长链接对发布配置提升不大。

2. 获取配置

随机获取200个 5K大小配置

Nacos2.0

tps2000400060008000100001400018000(实际15000)
avg rt(ms)3.343.55726133
80% rt(ms)2.22.22.52.5441174
95% rt(ms)3.34.85.4243893238
cpu12253748658385
load1.223452036

Nacos1.X

|tps|2000|4000|6000|8000|10000|14000(实际11000)| |---|---|---|---|---|---|---|---| |avg rt(ms)|3|7.4|12|22|46|176| |80% rt(ms)|1.8|2|4|7|35|185| |95% rt(ms)|4.4|6|15|33|118|380| |cpu|15|30|40|52|60|70| |load|1.1|2.2|2.5|4|5.5|9|

结果分析

长链接支撑的读QPS提升50%,CPU消耗降低50%,http的CPU消耗50%在于请求地址解析

3. 监听配置

两者均为单链接监听200配置。

Nacos2.0

tps150030006000
cpu303060
ygc03.75s/次,7次 0.5秒3s/次,10次 1.4秒
cmsgc000
load61420

Nacos1.X

tps300040006000
cpu80%90%80%
ygc3s一次,10次耗时0.5s2s一次,15次耗时1.5s1.5s一次,20次耗时1.3秒
cmsgc3s一次,10次耗时18s4.5一次,7次耗时10s7.5s一次,4次耗时5s
load6811

结果分析

gRPC以1500tps持续变更推送,可以保证系统指标稳定,超过1500tps,系统内存和load持续升高,但完全没有CMS GC,CPU也维持在较低的水准。 Http 则有较高的CMS GC,GC耗时严重,CPU损耗高。

4. 长连接容量测试

两者均为单链接监听200配置。快上为同时进行大量配置发布。

Nacos2.0

count600080001200015000210003150042000
快上时cpu40608077798074
快上时load1.533.33.65.455.66.3
快上耗时55s55s7610080140130
稳定时cpu1111.32.81.72.1
稳定时load0.30.50.50.80.90.80.8
gc稳定后无GC消耗稳定后无GC消耗稳定后无GC消耗稳定后无GC消耗稳定后无GC消耗稳定后无GC消耗稳定后无GC消耗

Nacos1.X

count600080001200015000210003150042000
快上时cpu80------
快上时load8------
快上耗时100s------
稳定时cpu60------
稳定时load1------
gccmsgc频繁,4秒一次------

结果分析

当连接量达到600时,Nacos1.X的CMS GC已经十分严重,4s一次,基本已经达到极限;反观Nacos2.0,可以继续增长,单从支撑长链接数量角度,Nacos2.0比Nacos1.X支撑7倍以上长链接。

测试结论

单项基础接口压测

  • Nacos2.0读QPS 14000QPS,对比Nacos1.X QPS 8000 提升75%。
  • Nacos2.0写TPS 2500TPS,对比Nacos1.X无明显提升。
  • Nacos2.0支撑长链接40000以上,对比Nacos1.X提升7倍以上。
  • Nacos2.0变更推送1500/s, 对比Nacos1.X无明显提升。

注意

  • 本测试为对比Nacos1.X版本的测试场景,仅测试单核心接口的能力值,真实模拟场景压测 将在后续版本给出;
  • 本测试供给大家作为参考,如有不足或偏差,请指正! 如果对性能有其他需求,可以给我们提issue。