# 性能与容量说明

## 压测工具

主要使用goose压测。

参考项目中的子工程 [loadtest](https://github.com/heqingpan/rnacos/tree/master/loadtest)

## 性能压测结果

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


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

### 压测记录

注册中心查询：

![](https://github.com/heqingpan/rnacos/raw/master/doc/assets/imgs/20230903202816.png)


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

![](https://github.com/heqingpan/rnacos/raw/master/doc/assets/imgs/20230903205737.png)


## 容量分析

### 配置中心

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小时重连一次；支持注册的服务实例总数为：60*60*10000 = 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左右。
4. 查询与注册混合
	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。
