代码在：
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的性能有一个底。
