实测SpringCloud Gateway网关性能(Wrk和Jmeter)

  SpringCloud 的Gateway网关性能到底如何，网上各种传言太多。我用Wrk和Jmeter两种测试工具，在相同环境和代码下进行压测。这里分享一下Wrk压测过程的数据和结果，希望对你的技术选型等有所助益。

    已把网关项目上传到csdn，可免费下载使用 https://download.csdn.net/download/u012246511/12651700

  （不知道为啥csdn上传的资源，所需积分/C币 老是自己变，而且还需要审核...所以提供个百度云的）

    百度云盘 链接：https://pan.baidu.com/s/1EtEnOI7ATs3v--l4X9GJzw
                   提取码：plfe
 

---

• Wrk压测时可能出现超时甚至报错，很大可能是工具问题。用比较专业的Jmeter就几乎没有出现超时和报错。

     不想看过程的可直接跳到第四章节，我会贴出wrk和jmeter两种压测结果，几乎一致。

目录

 

1、测试环境

2、测试所用命令及参数

3、测试过程

3.1做简单路由  只是匹配所有/test/** 请求路由到下游SpringBoot项目，把我提供网关项目yml中的spring提供的默认过滤器、5个自定义过滤器及aop代理全注掉。如图​Get测试结果：

3.2 简单路由+Gateway提供的两个默认过滤器增加AddRequestParameterGatewayFilterFactory和SetRequestHeaderGatewayFilterFactory两个默认的过滤器。 配置如图：​ Get请求测试结果：

 

3.3 路由+默认过滤器+1个自定义全局过滤器自定义全局过滤器用来修改Post请求时request body的

 

3.4 路由+默认过滤器+3个自定义全局过滤器+1个aop代理

3.5  路由+默认过滤器+5个自定义全局过滤器+1个aop代理

4、 结论 （重点.....)

    Wrk压测结果:

   Jmeter压测结果：

 

---

1、测试环境

•  网关  

  SpringCloud版本：Hoxton.SR6  

  Gateway 版本：2.2.3.RELEASE

• 下游服务
  
  SpringBoot版本： 2.2.8.RELEASE
   
• 服务主机(本地Windows10)

  内存：8G

  Cpu:  Intel(R) Core(TM) i5-9400F @ 2.90GHz   

  核数：6核

• 测试客户端(Centos7)

  内存：8G

  Cpu : Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz

  核数：4核

• 安装Wrk
  我是在Centos7上通过 yum 安装的，过程简单，无非就是先装个git ，然后clone代码，再ln个快捷引用就完事了；可参照如下命令：
  
  cd /usr/local/src
  yum install git -y
  git clone https://github.com/wg/wrk.git
  cd wrk
  yum -y install gcc
   make
  ln -s /usr/local/src/wrk/wrk /usr/local/bin
  wrk -t 2 -c 50 -d 20 --latency http://localhost:8081

2、测试所用命令及参数

    以下命令皆使用15个线程500个连接，进行10秒的压测，并要求在压测结果中输出响应延迟信息。

•  get请求 ：./wrkbin  -t 15 -c500 -d 10 --latency  http://localhost:8081/test/mt
• post请求： ./wrkbin  -t 15 -c500 -d 10 --latency -s post.lua  http://192.168.2.252:8081/test/mt
  post请求需要使用lua脚本，这里也贴下：

  
  wrk.method = "POST"
  wrk.headers["Content-Type"] = "application/json"
  wrk.body = "{}"
  

  
  
  3、测试过程

• 3.1做简单路由
  
    只是匹配所有/test/** 请求路由到下游SpringBoot项目，把我提供网关项目yml中的spring提供的默认过滤器、5个自定义过滤器及aop代理全注掉。如图
  
  Get测试结果：

  第一次---->
  

   

  第二次---->
  

   

  第三次->
  

   

  结论： 三次压测平均QPS: 4719 ,出现超时。

• Post测试结果

  第一次---->
  

   

  第二次---->
  

   

  第三次----->
  

   

  第四次----->
  

   

  第五次----->

   

  

  结论： 五次压测平均QPS: 3545 ,出现超时。

3.2 简单路由+Gateway提供的两个默认过滤器
增加AddRequestParameterGatewayFilterFactory和SetRequestHeaderGatewayFilterFactory两个默认的过滤器。 配置如图：


 Get请求测试结果：
 

第一次---->

 

第二次---->

 

第三次->

 

第四次-->

 

结论： 三次压测平均QPS: 5193,出现超时及错误。

Post测试结果

第一次---->

第二次---->

第三次----->

第四次----->

第五次----->

结论： 五次压测平均QPS: 3357,出现超时。

 

• 3.3 路由+默认过滤器+1个自定义全局过滤器
  自定义全局过滤器用来修改Post请求时request body的

Post测试结果

第一次---->

第二次---->

第三次----->

第四次----->

第五次----->

  结论： 五次压测平均QPS: 979 ,出现超时及错误。

 

• 3.4 路由+默认过滤器+3个自定义全局过滤器+1个aop代理

       Post测试结果：

第一次---->

 

第二次---->

 

第三次----->

 

第四次----->

 

第五次----->

 

 

  结论： 五次压测平均QPS: 724,出现超时及错误。

•           3.5  路由+默认过滤器+5个自定义全局过滤器+1个aop代理

           post测试结果：

第一次---->

 

第二次---->

 

第三次----->

 

 

结论： 三次压测平均QPS: 431,出现超时及错误。

 

4、 结论 （重点.....)

•        Wrk压测结果:

用途	QPS	备注
只做简单路由	4131	当请求方式为get时直接放行，并没有修改request body，所以其QPS看起来较高。
路由+默认过滤器	4275	竟然比第一个要高点？其实不尽然....跟我收集的数据和计算有点关系，但不影响整体测试结果。
路由+默认过滤器+1个自定义全局过滤器	979
路由+默认过滤器+3个自定义全局过滤器+1个aop代理	724
路由+默认过滤器+5个自定义全局过滤器+1个aop代理	431

    注1：当有get和post两种QPS时，下表中的QPS=（get+post）%2

    注2：由于2.x  gateway 使用的是netty，可通过设置netty下的reactor.netty.ioWorkerCount参数来优化并发，适当增加一倍后与以上测试结果基本一致，不合理的设置反而会降低QPS。
   
        

 

•    Jmeter压测结果：
   

  用途	QPS	测试次数	备注
  只做简单路由	5170	10
  路由+默认过滤器	4257	5
  路由+默认过滤器+1个自定义全局过滤器	1469	5
  路由+默认过滤器+3个自定义全局过滤器+1个aop代理	792	5
  路由+默认过滤器+5个自定义全局过滤器+1个aop代理	579	5

 Jmeter测试环境和过程跟wrk完全一样，这里我只测的最常用的Post请求。

 Jmeter在linux测post请求时可能需要*.jmx文件，可以在你的windows客户端装个jmeter，在界面上配置好保存后找到本地的*.jmx文件，上传到liunx就可以直接用。

• 高并发两大杀手锏：1、单机 。 2、复杂操作。
• 自定义过滤器里不过是从网上找了一段修改request body的代码，个人觉得并不能算是复杂操作，而是常用操作。
  至于为什么qps下降如此之大还没有在代码层面做调研，欢迎指正、解惑。
• spencergibb 在GIt上也有一个gateway和其他网关的性能测试，，参见
  https://github.com/spencergibb/spring-cloud-gateway-bench   （将所有请求路由到一个go搭建的取静态文件的服务中）

               

注意：其实当我们使用了默认提供的过滤器、自定义过滤器和aop代理这些技术导致性能降低时，其实瓶颈可能并不在网关本身了。

比如你的网关层还有访问数据库、redis缓存之类的操作，那QPS会进一步降低这是显而易见的。

 延迟和吞吐量是衡量性能的重要标准，我网关环境的机器并不是只有网关服务，其Cpu和内存并不是只为网关服务,所以如果一台Liunx上只部署网关的话，相信性能应该会比较客观。