性能与容量说明

压测工具

主要使用 goose 压测。

参考项目中的子工程 loadtest

性能压测结果

模块	场景	单节点 qps/tps	集群 qps/tps	总结/备注
配置中心	配置写入，http 协议	1.76 万	7.6 千	集群写入压测是在同一台电脑运行 3 个节点，如果换成多个机器部署，tps 应该还能有所提升。
配置中心	配置查询，http 协议	8 万	n*8 万	集群的查询总 qps 是节点的倍数
注册中心	服务实例注册，http 协议	4.8 万	2.4 万	集群写入压测是在同一台电脑运行 3 个节点，如果换成多个机器部署，tps 应该还能有所提升。
注册中心	服务实例注册，grpc 协议	4.8 万	2.4 万	grpc 协议压测工具没有支持，目前没有实际压测，理论不会比 http 协议低
注册中心	服务实例心跳，http 协议	4.8 万	2.4 万	心跳是按实例计算和服务实例注册一致共享 qps
注册中心	服务实例心跳，grpc 协议	8 万以上	n*8 万	心跳是按请求链接计算，且不过注册中心处理线程，每个节点只需管理当前节点的心跳，集群总心跳 qps 是节点的倍数
注册中心	查询服务实例	5.4 万	n*5.4 万	集群的查询总 qps 是节点的倍数

注： 具体结果和压测环境有关

压测记录

注册中心查询：

配置中心查询，两个进程分别限流 4 万 qps 同时压测 (共 8 万 qps)，其中一个的压测记录：

容量分析

配置中心

1. 配置中心的单机查询 8 万 qps，很高，又支持水平扩容；集群基本没有查询瓶颈。
2. 配置中心所占用的内存和配置内存有关，在内存没有满前，基本没有瓶颈。
3. 配置中心集群写入时统一在主节点写入，写入可能有瓶颈；目前 1.5 千 tps，后面优化后应该能到 1 万 tps 以上。

注册中心

1. 注册中心的单机查询 3 万 qps，比较高，又支持水平扩容；集群基本没有查询瓶颈。
2. 注册中心所占用的内存和配置内存有关，在内存没有满前，基本没有瓶颈。
3. 注册中心集群写入时每个节点都要写一遍，整体集群的写入性能 tps 和单机理论上相当。
4. http 协议 (v1.x 版本) 和 grpc 协议 (v2.x) 的心跳维护机制不同；http 心跳是按实例计算和服务实例注册一致共享 qps, grpc 的心跳是按请求链接计算且不过注册中心处理线程。所有这类协议理论支持的容量差别很大。

注册中心集群注册容量推理

1. http 协议注册 + 心跳 qps 是 1 万，每个实例 5 秒钟一次心跳；理论上只能支持 5 万服务实例左右。
2. grpc 协议，注册 qps 假设也是 1 万，心跳 qps 单实例 8 万，3 节点集群总心跳 24 万；如果平均一个应用实例 1 小时重连一次；支持注册的服务实例总数为：606010000 = 3600 万，心跳支持的链接实例总数为：5*24 万=120 万个链接实例（和集群节点有关）。

结论： 如果使用 v1.0x http 协议，支持的实例在 5 万个左右。 如果使用 v2.0x grpc 协议，理论上基本没有瓶颈。

---

r-nacos 与 java nacos 性能压测对比（单机模式）

旧版本的单机压测记录，有和 java 版本 nacos 的比较。

压测环境与工具

压测环境:macos i7 四核 /16G，施压、受压机器是同一台机器（会拉低压测结果）。 压测工具： * wrk ,qps: 24450 左右 * goose, qps 17000 左右（单进程加限流施压比 wrk 低） * 单进程施压请求 wrk 比 goose 输出高

r-nacos server 版本：v0.1.1 java nacos server 版本：2.1.0

因 wrk,goose 暂时不支持 grpc 协议，暂时只压测 http 协议接口

配置中心

配置中心，不会频繁更新，写入不做压测。

rust r-nacos server:

1. 配置中心单机查询 wrk 压测 qps 在 2.4 万左右。

java nacos server:

1. 配置中心单机查询 wrk 压测，qps 在 7700 左右

注册中心

rust r-nacos server:

2. naming 注册 1000 x 1 个实例，每秒 200qps，单核 cpu: 4.5% 左右
3. naming 单查询 1.5 万 QPS 左右
   1. wrk 查询单个服务，1.65 万 qps
   2. goose 查询 1000 个服务，1.5 万 qps
4. naming 单注册服务
   1. goose,5 万到 7 万实例数 0.7 万 qps 左右。
5. 查询与注册混合
   1. wrk 查询单个服务（1.5 万 qps) + goose 注册（0.075 万 qps) 【5 千实例】
   2. goose 查询 1000 个服务（1.3 万 qps) + goose 注册（0.07 万 qps) 【5 千实例】
   3. wrk 查询单个服务（1.5 万 qps) + goose 注册（0.15 万 qps) 【1 万实例】
   4. goose 查询 1000 个服务（1.3 万 qps) + goose 注册（0.13 万 qps) 【1 万实例】

java nacos server:

1. 配置中心查询 wrk 压测，7700 qps 左右
2. naming 注册 1000 x 1 个实例，每秒 200qps，单核 cpu: 17% 左右
3. naming 单查询
   1. wrk 查询单个服务，1.35 万 qps。
   2. goose 查询 1000 个服务，1 万 qps（前期应该还能上去一些）。前 30 秒能稳定在 1 万左右，30 秒后，跌到 200 左右之后再上下浮动，可能受 GC 影响。
4. naming 单注册
   1. goose,5 万到 7 万实例数 0.45 万 qps 左右。
5. 查询与注册混合
   1. wrk 查询单个服务（1.3 万 qps) + goose 注册（0.07 万 qps) 【5 千实例】
   2. goose 查询 1000 个服务（1 万 qps) + goose 注册（0.07 万 qps) 【5 千实例】; 前期能保持，后期 qps 上下浮动比较大，最低小于 50。
   3. wrk 查询单个服务（0.9 万 qps) + goose 注册（0.12 万 qps) 【1 万实例】
   4. goose 查询 1000 个服务（0.6 万 qps) + goose 注册（0.08 万 qps) 【1 万实例】

性能压测总结

1. r-nacos，除了服务服务注册不能稳定在 1 万以上，其它的接口 qps 都能稳定在 1 万以上。

2. java 的查询接口基本能压到 1 万以上，但不平稳，后继浮动比较大。如果降低压测流程，qps 可以相对平稳。

3. 在多服务查询叠加上多服务注册场景，r-nacos qps 能稳定在 1.3 万左右，java nacos qps 下降明显在 0.6 万左右。

4. r-nacos 综合 qps 是 java 版的 2 倍以上，因 java 有 GC，qps 水位稳定性上 java 较差（相同施压流量，qps 能从峰值 1 万能降到 1 百以下）。

5. r-nacos 服务，线程数稳定在 7，cpu 用例率最大 200% 左右（相当用个 2 核），内存在 50M 以下

6. java nacos 服务，线程数最大 300 左右，cpu 用例率最大 500% 左右，内存 600M 到 900M。