[alibaba/nacos]1.4.2注册中心性能测试报告:不加鉴权7万dubbo实例,加鉴权3万dubbo实例,如何继续提升实例数?

2024-07-18 880 views
2
1.4.2版本注册中心测试结论如下:
  1. 在无鉴权情况下,7w dubbo实例已出现瓶颈。
  2. 在有鉴权情况下,3w dubbo实例已出现瓶颈。
  3. 当开启鉴权且达到3万dubbo实例,服务端主要参数的最佳实践为:tomcat最大线程数=4000,最小空闲线程数=200,nacos的鉴权缓存=true。
问题: 如何继续提升dubbo实例数?因为我们实例已经达到1.5万,并且要添加鉴权功能,后续会继续增加,明年年末预计会到8万实例。 @KomachiSion 多谢啦

另外,实例数个数我们是查看的naming-performance.log 和控制台


附[Nacos注册中心性能测试报告],如有问题,请指正,以便我们更好的测试注册中心性能。

一、测试工具

使用Jmeter进行发压测试。

二、环境
指标 参数
机器性能 CPU 16核, 内存 32G
集群规模 5节点
NACOS版本 1.4.2
三、参数设置
  1. jvm参数在官网的参数上只调整了 -Xms10g 初始堆为10g -Xmx10g 最大堆为10g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 使用G1的垃圾收集器

  2. tomcat参数 在application.properties里面调整tomcat参数,增加: tomcat.maxThread=4000 tomcat.minSpareThread=200

  3. linux参数 ulimit -n=65535

四、测试场景
  1. 测试Nacos注册中心运行态的能力

  2. 对比鉴权前后性能差距

  3. 比较不同tomcat线程设置的场景

五、测试说明
  1. 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%
  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一次请求。

六、测试详情
  1. 第一轮测试:无鉴权

    测试基于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集群瓶颈。

  2. 第二轮测试:有鉴权

    测试基于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集群瓶颈。

  3. 第三轮测试:针对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。
七、测试结论

在当前配置下:

  1. 在无鉴权情况下,当实例数达到7.5w时,开始出现不健康实例、当实例数达到9w时开始出现注册实例数不足情况。预估无鉴权情况下7w实例已出现瓶颈。
  2. 在有鉴权情况下,当实例数达到3.5w时,开始出现不健康实例、当实例数达到4.5w时开始出现注册实例数不足情况。预估有鉴权情况下3w实例已出现瓶颈。
  3. 当开启鉴权且达到3万实例,服务端主要参数的最佳实践为:tomcat最大线程数=4000,最小空闲线程数=200,nacos的鉴权缓存=true。

回答

7

我觉得nacos内部之间的通讯应该定义一套自己的协议。避免使用http。可以使用thrift或者netty进行实现,我个人比较推荐thrift. 因为它对各种语言的客户端支持较好。并且我也打算进行实验测试

9

看了下源码,可能是鉴权的时候jwt的加解密运算消耗了cpu资源?您可以再测测这方面的实际消耗情况? 另外您应该是rest模式,尝试使用grpc应该会有更好的性能?

0

代码方面是不是可以给jwt的token加一个缓存,以减轻重复计算过程中的cpu压力

7

@jerrychern 为毛不直接升级到2.x

5

代码方面是不是可以给jwt的token加一个缓存,以减轻重复计算过程中的cpu压力

我们已经采取了缓存token的方式,缓存之后确实鉴权开启前后性能相差无几,差不多1万左右的实例。

1

@jerrychern 为毛不直接升级到2.x

因为2.x现在还不够稳定,然后要结合dubbo3.x比较好,我们这边生产服务较多,影响较大,需要等nacos2.x和dubbo3.x稳定之后才能用到生产。

3

我们使用的是nacos-client和服务端交互,client使用的是http请求,所以我们只压了http的方式。

8

Gg

1

Good

0

建议再测试下 Nacos 故障恢复的能力。 我几个月前也修改了 tomcat 线程迟,提升了压测效果。 Nacos 正常运行的时候能够正常处理请求,但是任意杀死多个实例在高负载的情况下,Nacos 无法恢复正常状态。具体表现为 Nacos 节点间的通讯异常。 因此能够安全使用的注册实例数比测得的峰值要小不少。

9

可以详情说一下吗?怎么测试的?我们也想测试一下这种场景,nacos版本是多少?

9

可以详情说一下吗?怎么测试的?我们也想测试一下这种场景,nacos版本是多少?

我测试了 1.4.0 和 1.4.2。 测试结论是,1.4.0 的故障恢复能力更强,但是 1.4.0 存在 bug,特定情况下 raft 状态异常无法自愈.

测试流程:

  1. 部署 5 节点 Nacos 集群
  2. 进行常规压测
  3. 随机杀掉 Nacos 集群中的任意一个节点,观察杀死的节点重启后能否正常加入集群,同步注册信息。 若无法恢复,降低压测流量再次测试,直到能正常恢复,即为线上能安全使用的实例注册数。
  4. 若删除单点能够自愈,进行多节点删除实验,同时删除两个节点,观察能否自愈
  5. 依此类推
0

mark