spring-cloud-gateway使用-压力测试

代码在：
https://gitee.com/sleepforests/spring-cloud-gateway-demo

网上比较多的压力测试的文章，我这边对scg和zuul2进行了一次完整的测试，现在整理测试的结果给大家。这里公司的压测机器较多，资源充足，我这里整理的主要是测试的方法及代码，大家拿到后可以自己搞定资源调整参数跑一跑。

先搞定基准

这里我们搞一个独立的springboot的http接口，接口不做啥事情，我们先对他压一压。这个项目就是代码里面的example-product服务，特别注意下配置点。

application.properties配置

server.port=9000
logging.level.root=info
spring.application.name=spring-cloud-gateway-product 

server.tomcat.accept-count=10000
server.tomcat.max-connections=10000
server.tomcat.max-threads=200
server.tomcat.min-spare-threads=200
server.tomcat.uri-encoding=UTF-8

jvm配置

java \
-Xss256k \
-Xms4G \
-Xmx4G \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=800 \
-XX:ParallelGCThreads=20 \
-XX:ConcGCThreads=5 \
-XX:InitiatingHeapOccupancyPercent=50 \
-XX:MetaspaceSize=100M \
-Dfile.encoding=UTF-8 \
-Djava.library.path=/usr/local/lib \
  -jar target/example-product-0.0.1-SNAPSHOT.jar

其他的配置可以查看org.springframework.boot.autoconfigure.web.ServerProperties代码。

压个几轮结果如下：

~/Downloads » wrk -t8 -c200 -d30s --latency http://localhost:9000/product/list          
Running 30s test @ http://localhost:9000/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.42ms    5.08ms 120.57ms   97.79%
    Req/Sec     4.71k     0.95k   19.95k    88.68%
  Latency Distribution
     50%    4.89ms
     75%    5.68ms
     90%    7.01ms
     99%   16.66ms
  1123867 requests in 30.07s, 218.85MB read
Requests/sec:  37372.05
Transfer/sec:      7.28MB

~/Downloads » wrk -t8 -c200 -d30s --latency http://localhost:9000/product/list          
Running 30s test @ http://localhost:9000/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.72ms    4.08ms  81.72ms   91.89%
    Req/Sec     4.41k     0.97k   12.71k    81.42%
  Latency Distribution
     50%    5.07ms
     75%    6.20ms
     90%    7.90ms
     99%   23.03ms
  1053894 requests in 30.10s, 205.22MB read
Requests/sec:  35018.60
Transfer/sec:      6.82MB

~/Downloads » wrk -t8 -c200 -d30s --latency http://localhost:9000/product/list          
Running 30s test @ http://localhost:9000/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.45ms    6.15ms 142.78ms   98.43%
    Req/Sec     4.76k     0.88k   20.12k    88.65%
  Latency Distribution
     50%    4.87ms
     75%    5.59ms
     90%    6.85ms
     99%   18.28ms
  1137704 requests in 30.10s, 221.54MB read
Requests/sec:  37801.43
Transfer/sec:      7.36MB

~/Downloads » wrk -t8 -c200 -d300s --latency http://localhost:9000/product/list         
Running 5m test @ http://localhost:9000/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    13.12ms   54.98ms   1.23s    96.26%
    Req/Sec     4.35k     1.26k   25.28k    86.97%
  Latency Distribution
     50%    5.07ms
     75%    6.07ms
     90%    8.78ms
     99%  118.63ms
  10216599 requests in 5.00m, 1.94GB read
Requests/sec:  34048.64
Transfer/sec:      6.63MB

测了4轮，啥结果也没有。哈哈。

scg测试

保持刚才的服务不停机，我们开始测试scg代理的能力，这里我们不做特别处理，尽量把所有的filter都去掉，只保留一个path断言，保证能转发到product服务即可。

application.properties 配置

server.port=8080
logging.level.root=INFO
spring.application.name=spring-cloud-gateway-demo
spring.cloud.gateway.httpclient.connectTimeout=1000
spring.cloud.gateway.httpclient.responseTimeout=60000
management.endpoints.web.exposure.include=*
management.endpoint.health.show-details=always
ribbon.eureka.enabled=false
ribbon.ServerListRefreshInterval=1000
ribbon.NFLoadBalancerPingInterval=1000

jvm配置

java \
-Xss256k \
-Xms4G \
-Xmx4G \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=800 \
-XX:ParallelGCThreads=20 \
-XX:ConcGCThreads=5 \
-XX:InitiatingHeapOccupancyPercent=50 \
-XX:MetaspaceSize=100M \
-Dfile.encoding=UTF-8 \
-Djava.library.path=/usr/local/lib \
  -jar target/example-scg-0.0.1-SNAPSHOT.jar

这里还给4g的内存，幸亏机器有16g内存，不然没法测了。

路由配置

{
  "routeDefinitionList": [
    {
      "id": "product",
      "uri": "lb://productRibbon",
      "order": 0,
      "predicates": [
        {
          "name": "Path",
          "args": {
            "pattern": "/product/*"
          }
        }
      ]
    }
  ],
  "ribbonDefinitionList": [
    {
      "clientName": "productRibbon",
      "listOfServers": "localhost:9000"
    }
  ]
}

这里采用读取配置文件的方式来处理路由。

多执行几次wrk测试，结果如下：

~/Downloads » wrk -t8 -c200 -d30s --latency http://localhost:8080/product/list     
Running 30s test @ http://localhost:8080/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    49.66ms   60.28ms 855.92ms   91.02%
    Req/Sec   655.32    237.17     1.34k    68.34%
  Latency Distribution
     50%   35.12ms
     75%   66.01ms
     90%  105.51ms
     99%  279.64ms
  154696 requests in 30.07s, 63.74MB read
  Socket errors: connect 0, read 102, write 2, timeout 0
Requests/sec:   5144.78
Transfer/sec:      2.12MB

~/Downloads » wrk -t8 -c200 -d30s --latency http://localhost:8080/product/list     
Running 30s test @ http://localhost:8080/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    22.54ms   16.53ms 390.29ms   83.45%
    Req/Sec     1.19k   165.44     1.50k    79.79%
  Latency Distribution
     50%   19.80ms
     75%   28.58ms
     90%   38.98ms
     99%   79.87ms
  284616 requests in 30.06s, 117.26MB read
  Socket errors: connect 0, read 43, write 0, timeout 0
Requests/sec:   9468.68
Transfer/sec:      3.90MB

~/Downloads » wrk -t8 -c200 -d30s --latency http://localhost:8080/product/list      
Running 30s test @ http://localhost:8080/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    21.99ms   14.47ms 366.06ms   78.30%
    Req/Sec     1.19k   130.21     1.48k    76.04%
  Latency Distribution
     50%   19.87ms
     75%   28.29ms
     90%   38.04ms
     99%   66.59ms
  285409 requests in 30.04s, 117.59MB read
  Socket errors: connect 0, read 39, write 0, timeout 0
Requests/sec:   9502.05
Transfer/sec:      3.91MB

~/Downloads » wrk -t8 -c200 -d300s --latency http://localhost:8080/product/list   
Running 5m test @ http://localhost:8080/product/list
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    22.61ms   13.99ms 382.64ms   75.77%
    Req/Sec     1.16k   123.20     1.70k    73.45%
  Latency Distribution
     50%   20.68ms
     75%   29.20ms
     90%   38.70ms
     99%   67.17ms
  2759661 requests in 5.00m, 1.11GB read
  Socket errors: connect 0, read 18, write 0, timeout 0
Requests/sec:   9196.50
Transfer/sec:      3.79MB

压了4轮，主要是为了充分预热，效果还是比较明显。

zuul2的压力测试情况

todo，其实我做过了，结果比scg差不多，但是失败率比较高。懒得写了。

几点结论

1、scg的性能优化没写，其实是需要的。scg使用webflux作为入口接受请求，reactor-netty包装的httpclient调用后端服务，本质上入口出口都是netty。所以对scg的优化需要结合netty来进行，而scg本身没有暴露太多优化的参数供用户来调整。scg工作线程是cpu核数，大家通过截图可以看到线程数量。

image.png

2、scg全异步的开发模式下，可以使用很少的线程达到较高的qps，代码里面如果出现同步处理，那么异步的护体神功就破解了。

3、上面的测试代码，参数调整并且在服务器充足，scg没有任何优化的情况下，可以干到5w qps，P95在6ms，P99在30ms以内。而zuul2的情况差不多，但是zuul2比较不稳定，KO的情况比较多。

4、其实上面的测试没有什么结论，或者说结论不明显。我没法说增加了百分之多少的消耗，因为本身异步开发的性能是极好的，在网关没有太多业务代码的情况，增加的开销不大。但是一旦开始接入各种功能后，网关的性能消耗肯定会增加，当然，只要保持全链路异步，最终网关消耗的也不会太多ms。

5、网上有很多公司自己研发的网关产品，主要是基于netty包装的。而scg的特点是spring出品核心也是netty，它代码设计良好，迭代速度很快，代码量不大，完全自研和基于scg来二次开发其实没有太大的区别。

6、上面的测试大家可以部署到不同的机器上面，并且通过调整wrk的参数反复的多测试几组数据、调整jvm参数来反复压测，相信大家做完几组测试会对scg的性能有一个底。