- 在无鉴权情况下，7w dubbo实例已出现瓶颈。
- 在有鉴权情况下，3w dubbo实例已出现瓶颈。
- 当开启鉴权且达到3万dubbo实例，服务端主要参数的最佳实践为：tomcat最大线程数=4000，最小空闲线程数=200，nacos的鉴权缓存=true。
另外，实例数个数我们是查看的naming-performance.log 和控制台
附[Nacos注册中心性能测试报告]，如有问题，请指正，以便我们更好的测试注册中心性能。
一、测试工具使用Jmeter进行发压测试。
二、环境| 指标 | 参数 |
|---|---|
| 机器性能 | CPU 16核， 内存 32G |
| 集群规模 | 5节点 |
| NACOS版本 | 1.4.2 |
-
jvm参数在官网的参数上只调整了 -Xms10g 初始堆为10g -Xmx10g 最大堆为10g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 使用G1的垃圾收集器
-
tomcat参数 在application.properties里面调整tomcat参数，增加： tomcat.maxThread=4000 tomcat.minSpareThread=200
-
linux参数 ulimit -n=65535
-
测试Nacos注册中心运行态的能力
-
对比鉴权前后性能差距
-
比较不同tomcat线程设置的场景
-
Nacos运行态接口说明 通过查看nacos代码和打开tomcat的访问日志，发现运行过程中，注册中心服务端会收到如下接口请求，只列举前4，涵盖99.9%的请求。
接口名 说明 /nacos/v1/ns/instance/beat 以实例为单位，每5秒请求1次，占比 75% /nacos/v1/ns/instance/list 以消费者实例为单位，每10秒请求1次，占比24% /nacos/v1/cs/configs/listener 以服务为单位，每30秒发一次请求，占比0.7% /nacos/actuator/prometheus 监控指标接口，无鉴权，占比0.2% -
调用HTTP接口测试 使用压力机模拟nacos运行态场景，需要满足以上接口频率，我们为了方便压测，直接以实例为单位，请求以下3个接口：
2.1 /nacos/v1/ns/instance/beat：以实例为单位，每隔5秒左右发一次http请求； 2.2 /nacos/v1/ns/instance/list：以实例（没有区分是否是消费者）为单位，每隔10秒左右发一次http请求； 2.3 /nacos/v1/cs/configs/listener：以服务为单位，每隔30秒左右发一次http请求。
3个接口同时发压，模拟nacos集群运行态。每5000实例采用100并发，并通过吞吐量控制器控制1000TPS，以达到5s一次请求。
-
第一轮测试：无鉴权
测试基于400个服务，每个服务的实例数不断增加。
1.1 监听配置接口：
并发数 服务数 TPS RT（ms） 400 400 13.3 30000 监听配置结果，不随实例数增长进行变化，持续保持每服务每30s发送一次。性能一直保持稳定。
1.2 发送实例心跳接口+查询实例列表接口：
并发数 服务数 实例数 TPS RT（ms） 备注 300*4 400 60000 24000 10 300*4+100 400 65000 26000 15 300*4+100*2 400 70000 27890 20 300*4+100*3 400 75000 不足 25 出现不健康实例 300*4+100*4 400 80000 不足 30 300*4+100*5 400 85000 不足 40 300*4+100*6 400 90000 不足 50 实例数不足 300*4+200*1+100*6 400 100000 不足 60 发送实例心跳接口+查询实例列表接口，在1400并发、400服务、70000实例时，接口平均响应时间为20ms，TPS 27890 小于7w实例所需的TPS 28000，已不满足每实例每5s发送请求，并开始出现不健康实例。由此推断，无鉴权的情况下，7w实例数已达到nacos集群瓶颈。
-
第二轮测试：有鉴权
测试基于400个服务，每个服务的实例数不断增加。
2.1 监听配置接口：
并发数 服务数 TPS RT（ms） 400 400 13.3 30000 监听配置结果，不随实例数增长进行变化，持续保持每服务每30s发送一次。性能一直保持稳定。
2.2 发送实例心跳接口+查询实例列表接口：
并发数 服务数 实例数 TPS RT（ms） 备注 300 400 15000 6000 10 300*2 400 30000 12000 25 300*2+100 400 35000 13700 30 出现不健康实例 300*2+100*2 400 40000 不足 40 300*2+100*3 400 45000 不足 50 实例数不足 300*2+100*4 400 50000 不足 60 严重实例数不足 发送实例心跳接口+查询实例列表接口，有鉴权在700并发、400服务、35000实例时，接口平均响应时间为30ms，TPS13700小于3.5w实例所需的TPS14000，已不满每实例每5s发送请求，并开始出现不健康实例。由此推断，有鉴权的情况下，3w实例数已达到nacos集群瓶颈。
-
第三轮测试：针对tomcat参数的测试 本轮测试分为3组，都是在 35000 左右的实例并且添加鉴权 的场景下进行测试，分别观察不同tomcat.maxThread、不同tomcat.minSpareThread和不同并发压力下注册中心的表现：
3.1 测试组1：不同tomcat.maxThread参数下服务性能表现 在压测35000实例，tomcat.minSpareThread=200，压测并发数=800的情况下： 3.1.1 tomcat.maxThread=1000时服务能力不足； 3.1.2 tomcat.maxThread为2000-8000时服务性能差别接近，说明服务能力足够，并没有启动更多线程以应对不足； 3.1.3 tomcat.maxThread=4000时性能表现较好，足够应对服务压力。
3.2 测试组2：不同tomcat.minSpareThread参数下，服务性能表现 在压测35000实例，tomcat.maxThread=4000，压测并发数=800的情况下： 3.2.1 tomcat.minSpareThread > 200以上，服务能力充足； 3.2.2 tomcat.minSpareThread为1000至4000时，服务响应时长递增，说明cpu维护了更多的线程打断，从cpu interrupt一项可印证，线程打断增多，消耗了更多的cpu能力; 3.2.3 tomcat.minSpareThread=200时性能表现较好，且足够应对服务压力.
3.3 测试组3：不同并发压力下服务性能表现 在压测35000实例，tomcat.maxThread=4000，tomcat.minSpareThread=200的情况下： 3.3.1 压测并发数 1200以内，服务能力充足； 3.3.2 压测并发数 大于800时，服务响应时长递增，说明cpu维护了更多的线程切换，从cpu sys%和interrupt项可印证，cpu的内核态工作增加，消耗了cpu能力 3.3.3 压测并发数在1600时，已无法提供正确的注册服务，这虽然与压力机的配置有一定关系，但主要内因还是服务端服务能力不足，较多心跳请求无法及时响应，从而导致实例数无法保持。
综上：
- nacos注册中心开启鉴权后，服务性能瓶颈主要表现为对cpu的依赖，而服务器内存、网络连接数、网卡io、磁盘io、java虚拟机GC等尚不构成影响性能的关键因素。
- 在本测试的压力机、nacos服务机配置下，服务主要参数的最佳实践为：tomcat最大线程数=4000，最小空闲线程数=200，nacos的鉴权缓存=true，jvm:gc=G1, maxGCPauseMillis=100。
- 上述配置下，服务最佳性能表现：TPS=14000，并发数=1200，latency avg=40ms（近似值），latency max=600ms（近似值），YoungGC平均耗时：90ms，FullGC=0。
在当前配置下：
- 在无鉴权情况下，当实例数达到7.5w时，开始出现不健康实例、当实例数达到9w时开始出现注册实例数不足情况。预估无鉴权情况下7w实例已出现瓶颈。
- 在有鉴权情况下，当实例数达到3.5w时，开始出现不健康实例、当实例数达到4.5w时开始出现注册实例数不足情况。预估有鉴权情况下3w实例已出现瓶颈。
- 当开启鉴权且达到3万实例，服务端主要参数的最佳实践为：tomcat最大线程数=4000，最小空闲线程数=200，nacos的鉴权缓存=true。