Nacos 2.0.0-ALPHA2 配置性能测试报告
Document translating and optimizing...
测试目的
- 长链接各项业务指标的最高值
- 长链接相比短链接的差异数据对比
测试工具
我们使用自研的PAS性能评估服务平台进行压测，其原理是基于利用JMeter引擎，使用PAS自动生成的JMeter脚本，进行智能压测。
测试环境
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
| tps | 500 | 1000 | 1200 | 1500 | 2000 | 2500 | 3000 |
|---|---|---|---|---|---|---|---|
| avg rt(ms) | 7 | 8 | 12 | 9 | 9 | 10.89 | 1044 |
| 80% rt(ms) | 7.9 | 8 | 11 | 9 | 9 | 10.69 | 1581 |
| 95% rt(ms) | 8.7 | 11 | 25 | 15 | 14 | 24.74 | 2966 |
| cpu | 12 | 22 | 28 | 36 | 47 | 55 | 62 |
| load | 0.5 | 1.5 | 1.5 | 1.5 | 3.5 | 4 | 5 |
Nacos1.X
| tps | 500 | 1000 | 1200 | 1400 | 2000 | 2500 | 3000 |
|---|---|---|---|---|---|---|---|
| avg rt(ms) | 9 | 8.67 | 8 | 9 | 10 | 11.88 | 1038 |
| 80% rt(ms) | 9 | 9.4 | 10 | 9 | 10 | 12.48 | 1090 |
| 95% rt(ms) | 11 | 11.4 | 12 | 14 | 18 | 25.7 | 1170 |
| cpu | 14 | 25 | 30 | 35 | 50 | 60 | 65 |
| load | 0.9 | 1.4 | 2 | 2.5 | 3 | 2.5 | 3.7 |
结果分析
发布配置两者差别不大,TPS 在2500tps左右出现拐点,http和长链接通道的cpu消耗分布类似。长链接对发布配置提升不大。
2. 获取配置
随机获取200个 5K大小配置
Nacos2.0
| tps | 2000 | 4000 | 6000 | 8000 | 10000 | 14000 | 18000（实际15000） |
|---|---|---|---|---|---|---|---|
| avg rt(ms) | 3.3 | 4 | 3.5 | 5 | 7 | 26 | 133 |
| 80% rt(ms) | 2.2 | 2.2 | 2.5 | 2.5 | 4 | 41 | 174 |
| 95% rt(ms) | 3.3 | 4.8 | 5.4 | 24 | 38 | 93 | 238 |
| cpu | 12 | 25 | 37 | 48 | 65 | 83 | 85 |
| load | 1.2 | 2 | 3 | 4 | 5 | 20 | 36 |
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
| tps | 1500 | 3000 | 6000 |
|---|---|---|---|
| cpu | 30 | 30 | 60 |
| ygc | 0 | 3.75s/次，7次 0.5秒 | 3s/次，10次 1.4秒 |
| cmsgc | 0 | 0 | 0 |
| load | 6 | 14 | 20 |
Nacos1.X
| tps | 3000 | 4000 | 6000 |
|---|---|---|---|
| cpu | 80% | 90% | 80% |
| ygc | 3s一次，10次耗时0.5s | 2s一次，15次耗时1.5s | 1.5s一次，20次耗时1.3秒 |
| cmsgc | 3s一次，10次耗时18s | 4.5一次，7次耗时10s | 7.5s一次，4次耗时5s |
| load | 6 | 8 | 11 |
结果分析
gRPC以1500tps持续变更推送，可以保证系统指标稳定，超过1500tps，系统内存和load持续升高，但完全没有CMS GC，CPU也维持在较低的水准。 Http 则有较高的CMS GC，GC耗时严重，CPU损耗高。
4. 长连接容量测试
两者均为单链接监听200配置。快上为同时进行大量配置发布。
Nacos2.0
| count | 6000 | 8000 | 12000 | 15000 | 21000 | 31500 | 42000 |
|---|---|---|---|---|---|---|---|
| 快上时cpu | 40 | 60 | 80 | 77 | 79 | 80 | 74 |
| 快上时load | 1.5 | 3 | 3.3 | 3.6 | 5.45 | 5.6 | 6.3 |
| 快上耗时 | 55s | 55s | 76 | 100 | 80 | 140 | 130 |
| 稳定时cpu | 1 | 1 | 1 | 1.3 | 2.8 | 1.7 | 2.1 |
| 稳定时load | 0.3 | 0.5 | 0.5 | 0.8 | 0.9 | 0.8 | 0.8 |
| gc | 稳定后无GC消耗 | 稳定后无GC消耗 | 稳定后无GC消耗 | 稳定后无GC消耗 | 稳定后无GC消耗 | 稳定后无GC消耗 | 稳定后无GC消耗 |
Nacos1.X
| count | 6000 | 8000 | 12000 | 15000 | 21000 | 31500 | 42000 |
|---|---|---|---|---|---|---|---|
| 快上时cpu | 80 | - | - | - | - | - | - |
| 快上时load | 8 | - | - | - | - | - | - |
| 快上耗时 | 100s | - | - | - | - | - | - |
| 稳定时cpu | 60 | - | - | - | - | - | - |
| 稳定时load | 1 | - | - | - | - | - | - |
| gc | cmsgc频繁，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。