【深入解析spring cloud gateway】12 gateway参数调优与分析_Java

本节主要对网关主要的一些参数做一些解释说明，并用压测工具测试一下网关的接口，通过压测来验证参数配置是否合理

一、连接池参数

参数示例

spring:
  application:
    name: gateway
  cloud:
    gateway:
      # http连接设置
      httpclient:
        # 全局的响应超时时间，网络链接后，后端服务多久不返回网关就报错 the response timeout. pt10s代表10秒的意思
        response-timeout: pt30s
        # 全局的tcp连接超时时间默认时间是45秒，修改为5秒
        connect-timeout: 5000
        # 链接池配置
        pool:
          # 最大连接数
          max-connections: 10000
          # 获取连接的超时时间，单位毫秒
          acquire-timeout: 1000
          # channel空闲时，最大的存活时间，如果为空，没有最大空闲时间
          max-idle-time: 120000
          # channel存在的最长时间，如果为null，则没有最大生命时间限制
#          max-life-time: 10
          # 在后台进行清除channel的时间间隔，默认情况下为0,即不进行定期清除
          eviction-interval: 180000
          # 设置固定链接池
          type: fixed

http超时配置

全局超时配置

spring:
  cloud:
    gateway:
      # http连接设置
      httpclient:
        # 全局的响应超时时间，网络链接后，后端服务多久不返回网关就报错 the response timeout. pt10s代表10秒的意思
        response-timeout: pt10s
        # 全局的tcp连接超时时间默认时间是45秒，修改为5秒
        connect-timeout: 5000

如果是想针对单个路由配置超时，可以配置在路由上

spring:
  cloud:
    gateway:
      routes:
      - id: requestratelimiter_route
        uri: http://localhost:3000/
        predicates:
        - path=/normal/**
        metadata:
          response-timeout: 7000
          connect-timeout: 2000

连接池类型

spring.cloud.gateway.httpclient.pool.type，该参数一共有三种类型

elastic：弹性链接池，连接数上限为integer.max，默认值就是这个类型
fixed: 固定连接池，最大连接数采用spring.cloud.gateway.httpclient.pool.max-connections的配置
disabled：不使用任何连接池

其余参数见注释说明

二、线程池参数

gateway底层是使用的netty来处理网络请求。如果你了解过netty，那你应该知道netty的线程模型是使用了两个线程池，bossgroup和workgroup。分别用于处理io的连接请求，以及业务。
查看一下gateway源码，可以看到

public interface loopresources extends disposable {
    int default_io_worker_count = integer.parseint(system.getproperty("reactor.netty.ioworkercount", "" + math.max(runtime.getruntime().availableprocessors(), 4)));
    int default_io_select_count = integer.parseint(system.getproperty("reactor.netty.ioselectcount", "-1"));
    //省略大量代码
  }

default_io_worker_count，工作线程数，默认值是cpu核心数，如果核心数少于4，那么就是最小为4
default_io_select_count ，io线程数，默认为-1，当它为-1时，其实就等于io线程数

如果想手动修改线程参数值，可以这么做

添加环境变量，reactor.netty.ioworkercount=xx,reactor.netty.ioselectcount=xx
或者动设置属性值，如下代码

@springbootapplication
public class gatewaydemoapplication {

	public static void main(string[] args) {
		system.setproperty(reactornetty.io_select_count,"8");
		system.setproperty(reactornetty.io_worker_count,"8");
		springapplication.run(gatewaydemoapplication.class, args);
	}
}

三、压力测试

本机环境 4核cpu，16g内存，三个服务，eureka-server，euerka-client，gateway

环境准备：jemeter+jprofile

下载jprofile，安装好
下载jmeter，安装好
idea安装jprofile插件

测试代码编写

hello-service定义一个接口，模拟耗时200ms

@controller
@slf4j
public class businesscontroller {

    @requestmapping(value = "/mock/business", method = requestmethod.post)
    @responsebody
    public map<string, string> modifyrequest(@requestbody map<string, string> map) {
        try {
            thread.sleep(200l);
        } catch (interruptedexception e) {
            throw new runtimeexception(e);
        }
        return map;
    }
}

启动微服务和eureka注册中心
启动gateway网关，点击那个蓝色的小图标

在这里插入图片描述
然后就可以启好网关，并且通过jprofile看到线和、cpu、内存的运行状态了

等会我们通过jmeter再实时观察一下各参数的情况，方便验证我们的网关参数
jmeter配置
定义一个线程组：
1000个线程，10秒内启动，循环100次
在这里插入图片描述
定义一个http取样器，同时设置好请求，如下

由于是post请求，请求数据为json，所以添加一个头信息管理器

定义请求结果的报告

jmeter结果：
在这里插入图片描述
jmeter中的聚合报告中，主要有十几项的参数,参数如下：

1、label：每个请求的名称，比如http请求等
2、#samples:表示这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100；【我的是用户有100，只迭代一次，因此也是100】
3、average：平均响应时间——默认情况下是单个 request 的平均响应时间，当使用了 transaction controller 时，也可以以transaction 为单位显示平均响应时间；
4、median：中位数，也就是 50％用户的响应时间；
5、90% line ~ 99% line：90％ ~99%用户的响应时间；
6、min：最小响应时间；
7、maximum：最大响应时间；
8、error%：本次测试中出现的错误率，即错误的请求的数量/请求的总数；
9、throughput：吞吐量——默认情况下表示每秒完成的请求数（request per second），当使用了 transaction ；
10、received kb/src：每秒从服务器端接收到的数据量；
11、sent kb/src：每秒从客户端发送的请求的数量。

可以看到，请求结果中，是有些报错的，
通过jmeter查看一下线程情况

可以看到，gateway的线程数，并没有因为请求数增加而增加，线程一般启起来都是固定的。基于reactor响应式编程模型和netty框架的支持，一个线程是可以同时处理多个连接（channel）的。
上图中，可以看到，此时运行的线程数为4，io处理线程为4
内存占用情况，可以在这里看到

————————————————
用jmeter时遇到了如下问题：
jmeter压测时address already in use：connect错误解决
在windows 环境下使用jmeter 进行压测的过程中，通常会遇到这样的错误“jmeter address already in use：connect”，查阅了不少资料，发现这是windows本身提供的端口访问机制的问题。
windows提供给tcp/ip连接的端口为1024-5000，并且要4分钟来循环回收它们，这就导致了我们在短时间内发起大量请求的时候将端口占满了。

解决方案一：
jmeter里的http sample勾选了keep alive，导致会话一直保持，而windows本身的端口有限，导致端口被占用完后，无法分配新的端口，因此会产生java.net.bindexception: address already in use: connect 报错。

    解决方法：http sample 不勾选"keepalive"即可，如下图所示：

在这里插入图片描述

解决方案二：
step1:win+r 在cmd中，用regedit命令打开注册表
step2:在hkey_local_machine\system\currentcontrolset\services\tcpip\parameters 目录下，
（1）右键parameters 新建dword，名字为maxuserport,输入数值65534（十进制）
（2）再次右键 parameters 新建dword，名字为tcptimedwaitdelay,输入数值30（十进制）表示30秒回收端口
在这里插入图片描述

step3:重启计算机。
问题解决

【深入解析spring cloud gateway】12 gateway参数调优与分析

2024年08月02日 • Java •我要评论

一、连接池参数

http超时配置

连接池类型

二、线程池参数

三、压力测试

环境准备：jemeter+jprofile

测试代码编写

相关文章:

SpringCloud gateway 防止XSS漏洞

Spring Cloud Gateway：打造可扩展的微服务网关

springboot gateway命令执行漏洞复现(CVE-2022-22947)＋内存马

微服务安全——OAuth2.1详解、授权码模式、SpringAuthorizationServer实战、SSO单点登录、Gateway整合OAuth2

发表评论


验证码：