阅读全文

《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Performance-Testing/SpringMVC-Webflux-benchmark/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 1. 概述
• 2. 性能指标
• 3. 测试环境
• 4. 第一轮
  • 4.1 SpringMVC + Tomcat
  • 4.2 Webflux + Tomcat
  • 4.3 Webflux + Netty
• 5. 第二轮
  • 5.1 SpringMVC + Tomcat
  • 5.2 Webflux + Tomcat
  • 5.3 Webflux + Netty
• 6. 第三轮
• 666. 彩蛋

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

推荐阅读如下 SpringMVC 和 WebFlux 文章：

• 《芋道 Spring Boot SpringMVC 入门》 对应 lab-23
• 《芋道 Spring Boot WebFlux 入门》 对应 lab-27

本文在提供完整代码示例，可见 https://github.com/YunaiV/SpringBoot-Labs 的 lab-06 目录。

原创不易，给点个 Star 嘿，一起冲鸭！

1. 概述

自 Spring 5.x 发布后，新增了 Spring WebFlux ，一个基于 Reactor 实现的响应式 Web 框架。其功能最大的特点，在于非阻塞异步，所以其需要运行如下环境下：

• 1、支持 Servlet 3.1 的 Web 容器中，例如说 Tomcat、Jetty、Undertow 。
• 2、Netty 网络通信框架，在 Webflux 使用的是 Reactor Netty 框架进行实现。并且，在使用 spring-boot-starter-webflux 时，默认使用的就是这种环境。

得益于 Webflux 框架，我们可以非常的将相对耗时的 IO 操作，提交到线程池中，从而达到异步非阻塞的功能，进一步提升并发性能。当然，实际上，我们使用 Servlet 3.1 + 线程池，也能实现非阻塞的效果，但是相比来说会麻烦一些。

艿艿：上面的这段话，可能写的有点绕口，或者不好理解，欢迎一起交流。

不过，Spring 在推出 WebFlux 后，带上响应式的概念，在目前这个时候，已经有些被魔化的带上“高并发”的说法？！所以，带着这样的好奇与疑惑，我们一起来做下 SpringMVC 和 Webflux 的性能基准测试。

在继续往下阅读本文之前，希望胖友已经阅读过如下两篇文章，因为有一些涉及到的关联知识，本文不会赘述：

• 《性能测试 —— Nginx 基准测试》
• 《性能测试 —— Tomcat、Jetty、Undertow 基准测试》

2. 性能指标

和 《性能测试 —— Nginx 基准测试》 保持一致，我们还是以 QPS 作为性能的指标。

在 https://github.com/YunaiV/SpringBoot-Labs/tree/master/lab-06 中，我们提供了三个示例，分别是：

• lab-06-springmvc-tomcat ：Tomcat 9.0.16 NIO 模式 + Spring MVC

• lab-06-webflux-tomcat ：Tomcat 9.0.16 NIO 模式 + Webflux

  相比上个示例，保持使用的 Tomcat 的前提下，将 SpringMVC 替换成 Webflux 。

• lab-06-webflux-netty ：Netty 4.1.33.Final + Webflux

  相比上个示例，保持使用的 Weblufx 的前提下，将 Tomcat 替换成 Netty 。

胖友可以使用 mvn package 命令，打包出不同的示例，进行压力测试。

3. 测试环境

• 型号 ：ecs.c5.xlarge

  艿艿：和我一样抠门（穷）的胖友，可以买竞价类型服务器，使用完后，做成镜像。等下次需要使用的时候，恢复一下。HOHO 。

• 系统 ：CentOS 7.6 64位

• CPU ：4 核

• 内存 ：8 GB

• 磁盘 ：40 GB ESSD 云盘

• JDK ：openjdk version "1.8.0_212"

• JVM 参数 ：-Xms2g -Xmx2g -Xmn1g -XX:MaxMetaspaceSize=256m -Xss256k

因为我们在跑的过程，发现 wrk 占用 CPU 不是很高，所以直接本机运行。

有一点要注意，JVM 本身有预热的过程，Tomcat、Jetty、Undertow 本也有预热的过程（例如说，线程的初始化），所以需要多次测试，取平均值。

本文，我们使用 wrk 如下命令进行测试：

./wrk -t50 -c并发 -d30s http://127.0.0.1:8080

• -t50 参数，设置 50 并发线程。
• -c并发 参数，设置并发连接，目前会按照 300、1000、3000、5000 的维度，进行测试。
• -d30s 参数，设置执行 30s 的时长的 HTTP 请求。
• http://127.0.0.1:8080 参数，请求本地的 Web 服务。

下面，让我们进入正式的测试。在每一轮中，我们将测试相同场景下，SpringMVC 和 Webflux 的表现。

4. 第一轮

在这轮中，我们想先来测试下，在逻辑中完全无 IO 的情况下，三者的性能情况。请求的示例接口如下：

• Spring MVC ，直接返回 "world" 字符串。

  @GetMapping("/hello")
  public String hello() {
      return "world";
  }

• Spring Webflux ，直接返回 "world" 字符串的 Mono 对象。

  @GetMapping("/hello")
  public Mono<String> hello() {
      return Mono.just("world");
  }

4.1 SpringMVC + Tomcat

🚚 300 并发

$ ./wrk -t50 -c300 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 300 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.82ms    8.36ms 180.77ms   92.82%
    Req/Sec   585.78     64.82     2.22k    77.93%
  876355 requests in 30.10s, 98.78MB read
Requests/sec:  29115.47
Transfer/sec:      3.28MB

• 29115 QPS
• 10.82ms Avg Latency

🚚 1000 并发

$./wrk -t50 -c1000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    34.91ms    6.73ms 101.04ms   82.96%
    Req/Sec   574.99     64.19     2.67k    83.73%
  863098 requests in 30.10s, 97.27MB read
Requests/sec:  28678.48
Transfer/sec:      3.23MB

• 28678 QPS
• 34.91ms Avg Latency

🚚 3000 并发

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 3000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   103.25ms   15.48ms 303.58ms   92.31%
    Req/Sec   579.84     85.08     4.05k    88.02%
  870323 requests in 30.10s, 98.05MB read
Requests/sec:  28911.19
Transfer/sec:      3.26MB

• 28911 QPS
• 103.25ms Avg Latency

🚚 5000 并发

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   169.61ms   27.88ms 558.41ms   93.53%
    Req/Sec   585.99    185.74     7.03k    80.49%
  876680 requests in 30.10s, 98.75MB read
Requests/sec:  29126.46
Transfer/sec:      3.28MB

• 29126 QPS
• 169.61ms Avg Latency

小结

总的来说，QPS 比较稳定在 29000 左右，而延迟逐步提升。

4.2 Webflux + Tomcat

🚚 300 并发

$ ./wrk -t50 -c300 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 300 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    13.51ms    5.53ms 146.89ms   83.08%
    Req/Sec   450.70     42.24     1.53k    77.86%
  674480 requests in 30.09s, 76.02MB read
Requests/sec:  22413.32
Transfer/sec:      2.53MB

• 22413 QPS
• 13.51ms Avg Latency

🚚 1000 并发

$ ./wrk -t50 -c1000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    45.58ms    7.52ms 242.98ms   85.81%
    Req/Sec   439.07     49.56     1.76k    85.46%
  656334 requests in 30.10s, 73.97MB read
Requests/sec:  21805.86
Transfer/sec:      2.46MB

• 21805.86 QPS
• 45.58ms Avg Latency

🚚 3000 并发

$ ./wrk -t50 -c3000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 3000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   136.81ms   21.59ms 479.21ms   94.26%
    Req/Sec   437.68    103.92     4.55k    82.03%
  655949 requests in 30.10s, 73.92MB read
Requests/sec:  21791.89
Transfer/sec:      2.46MB

• 21791.89 QPS
• 136.81ms Avg Latency

🚚 5000 并发

$ ./wrk -t50 -c5000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   220.63ms   37.76ms 432.82ms   92.59%
    Req/Sec   448.51    199.83     4.37k    74.60%
  660039 requests in 30.10s, 74.37MB read
Requests/sec:  21925.27
Transfer/sec:      2.47MB

• 21925.27 QPS
• 220.63ms Avg Latency

小结

• 从自身角度：总的来说，QPS 比较稳定在 21000 左右，而延迟逐步提升。
• 对比 SpringMVC + Tomcat 角度：因为 Webflux 使用的是 Tomcat 对 Servlet 3.1 的实现，而这个场景的逻辑中，是完全没有 IO 的，所以“多余”了异步的过程，反倒带来了性能的下降。

4.3 Webflux + Netty

🚚 300 并发

$./wrk -t50 -c300 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 300 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.07ms    5.53ms  72.89ms   76.78%
    Req/Sec   804.91    143.55     4.62k    78.17%
  1203712 requests in 30.10s, 95.28MB read
Requests/sec:  39986.10
Transfer/sec:      3.17MB

• 39986.10 QPS
• 8.07ms Avg Latency

🚚 1000 并发

$./wrk -t50 -c1000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    22.00ms    7.60ms 261.83ms   84.69%
    Req/Sec     0.90k   210.39    13.14k    89.39%
  1342217 requests in 30.10s, 106.24MB read
Requests/sec:  44593.68
Transfer/sec:      3.53MB

• 44593.68 QPS
• 22.00ms Avg Latency

🚚 3000 并发

$./wrk -t50 -c3000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 3000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    72.83ms   24.03ms   1.02s    82.76%
    Req/Sec   803.62    247.83     9.80k    87.97%
  1208192 requests in 30.11s, 95.63MB read
Requests/sec:  40123.56
Transfer/sec:      3.18MB

• 40123.56 QPS
• 72.83ms Avg Latency

🚚 5000 并发

$./wrk -t50 -c5000 -d30s http://127.0.0.1:8080/hello

Running 30s test @ http://127.0.0.1:8080/hello
  50 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   126.80ms   68.82ms   1.98s    90.25%
    Req/Sec   764.53    312.29    17.26k    84.27%
  1141219 requests in 30.17s, 90.33MB read
  Socket errors: connect 0, read 0, write 0, timeout 37
Requests/sec:  37823.63
Transfer/sec:      2.99MB

• 37823.63 QPS
• 126.80ms Avg Latency

小结

• 从自身角度：随着并发请求的上升，QPS 先从 4w 左右，涨到 4.4w ，然后下滑到 3.8W 左右。

• 对比 SpringMVC + Tomcat 角度：Netty 相比 Tomcat 的线程模型，更加简洁。主要体现在 Netty worker 线程解析好请求，直接进行了 Webflux 的逻辑执行，而 Tomcat Poller 线程拿到请求后，具体的请求需要丢给 Tomcat Worker 线程来解析，再进行了 SpringMVC 的逻辑执行。这样，就导致 Tomcat 多了一次线程的切换，而这个场景的逻辑中，是完全没有 IO 的，所以性能会相对低。

  不了解 Tomcat NIO 线程模型的胖友，可以看看如下两篇文章：

  • 《Tomcat NIO 线程模型深入分析》
  • 《Tomcat NIO 线程模型分析》

  不了解 Netty NIO 线程模型的胖友，可以看看如下文章：

  • 《netty学习系列二：NIO Reactor模型 & Netty线程模型》

  当然，胖友可以思考下，为什么 Tomcat 会比 Netty 多了一个线程池呢？其实是殊途同归的。然后，如果有使用过 Dubbo 的胖友，再去看看 Dubbo 的线程模型，在体会一波。

  🔥 其实，Tomcat 的 Worker 线程池，是为了并发执行业务逻辑，往往来说，业务逻辑都是有 IO 操作的，所以进行了这样的设计。而 Netty 的 Worker 线程，和 Tomcat 的 Poller 线程，是基本等价的。实际场景下，Netty Worker 线程，解码完消息包后，我们也会自己创建一个业务线程池，将解析的消息丢入其中，进行执行逻辑。 也就是说，本质上，是将具有 IO 操作的逻辑，丢到线程池中，避免有限的 Netty Worker 线程，或者 Tomcat Poller 线程被阻塞。 然后，我们把这个设计思路，带到 Webflux 上，是不是也是通的，嘻嘻。

• 对比 Webflux + Tomcat 角度：相比来说，Netty 会比 Tomcat 更加适合作为 Webflux 的运行环境。

5. 第二轮

在这轮中，我们要来测试下，在逻辑中有 IO 的情况下，三者的性能情况。考虑到让测试更加简单，我们采用 Thread.sleep(100L) 暂停线程 100ms 的方式，来模拟 IO 阻塞的行为。请求的示例接口如下：

• Spring MVC ，先 sleep 100ms ，再返回 "world" 字符串。

  @GetMapping("/sleep")
  public String sleep() throws InterruptedException {
      Thread.sleep(100L);
      return "world";
  }

• Webflux ，先 sleep 100ms ，再返回 "world" 字符串的 Mono 对象。

  @GetMapping("/sleep")
  public Mono<String> sleep() {
      return Mono.defer(() -> {
          try {
              Thread.sleep(100L);
          } catch (InterruptedException ignored) {
          }
          return Mono.just("world");
      }).subscribeOn(Schedulers.parallel());
  }

  • 因为 sleep 会阻塞 100ms ，所以我们将逻辑的执行，通过 subscribeOn(Schedulers.parallel()) 代码块，调度到 Reactor 内置的用于并发执行的线程池，它的大小是 CPU 的线程数。例如说，本文使用的阿里云服务器，创建的线程池大小就是 4 。😈 为什么提这个呢？下文我们就会明白了。

5.1 SpringMVC + Tomcat

🚚 300 并发

$./wrk -t50 -c300 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 300 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   150.48ms   44.14ms 216.52ms   48.29%
    Req/Sec    39.86     11.50    70.00     81.41%
  59735 requests in 30.10s, 6.73MB read
Requests/sec:   1984.58
Transfer/sec:    228.96KB

• 1984 QPS
• 150.48ms Avg Latency

🚚 1000 并发

$./wrk -t50 -c1000 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   497.76ms  118.19ms 955.99ms   89.35%
    Req/Sec    40.54     19.53   190.00     68.86%
  59815 requests in 30.10s, 6.73MB read
Requests/sec:   1987.28
Transfer/sec:    229.00KB

• 1987 QPS
• 497.76ms Avg Latency

🚚 3000 并发

$./wrk -t50 -c3000 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 3000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.46s   286.08ms   1.65s    93.85%
    Req/Sec    97.48     97.90   590.00     82.99%
  59881 requests in 30.10s, 6.74MB read
Requests/sec:   1989.43
Transfer/sec:    229.25KB

• 1989 QPS
• 1.46s Avg Latency

🚚 5000 并发

$./wrk -t50 -c5000 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 5000 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   665.93ms  651.42ms   1.95s    76.81%
    Req/Sec   110.86    154.20     0.97k    86.41%
  59897 requests in 30.10s, 6.74MB read
  Socket errors: connect 0, read 0, write 0, timeout 54494
Requests/sec:   1989.93
Transfer/sec:    229.31KB

• 1989 QPS
• 665.93ms Avg Latency

小结

• 从自身角度：QPS 稳定在 2000 QPS 不到，这个是为什么呢？默认情况下，Spring Boot 设置内嵌的 Tomcat 的 Worker 线程池大小为 200 ，加上每个逻辑需要 sleep 100 ms ，所以每个线程能处理 10 个情况，所以 QPS 最大就在 10 * 200 = 2000 ，所以测试结果就基本在 2000 QPS 。

5.2 Webflux + Tomcat

🚚 300 并发

$./wrk -t50 -c300 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 300 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     0.00us    0.00us   0.00us    -nan%
    Req/Sec     2.96      3.61    20.00     83.63%
  1065 requests in 30.06s, 122.72KB read
  Socket errors: connect 0, read 0, write 0, timeout 1065
Requests/sec:     35.43
Transfer/sec:      4.08KB

• 35.43 QPS
• 0.00us Avg Latency 【计算错误】

是不是看到这样的性能，一脸懵逼？淡定，我们下面会解释。

🚚 1000 并发

$./wrk -t50 -c1000 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.01s   552.42ms   1.91s    57.89%
    Req/Sec     7.56      7.71    50.00     85.68%
  1192 requests in 30.10s, 137.36KB read
  Socket errors: connect 0, read 0, write 0, timeout 1116
Requests/sec:     39.61
Transfer/sec:      4.56KB

• 35.43 QPS
• 0.00us Avg Latency 【计算错误】

🚚 3000 并发

$./wrk -t50 -c3000 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 3000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   983.66ms  543.02ms   1.96s    60.00%
    Req/Sec    11.37      9.50    40.00     76.67%
  1184 requests in 30.10s, 136.44KB read
  Socket errors: connect 0, read 0, write 0, timeout 1124
Requests/sec:     39.34
Transfer/sec:      4.53KB

• 39.34 QPS
• 983.66ms Avg Latency

🚚 5000 并发

$./wrk -t50 -c5000 -d30s http://127.0.0.1:8080/sleep

Running 30s test @ http://127.0.0.1:8080/sleep
  50 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.25s   480.74ms   1.94s    65.45%
    Req/Sec    12.07     10.54    40.00     73.63%
  1187 requests in 30.10s, 136.78KB read
  Socket errors: connect 0, read 0, write 0, timeout 1132
Requests/sec:     39.44
Transfer/sec:      4.54KB

• 39.44 QPS
• 1.25s Avg Latency

小结

• 从自身角度：QPS 稳定在 40 QPS 不到，这个是为什么呢？在上文中，我们也提到，Reactor 内置的 parallel 线程，线程池大小是 4 ，因为逻辑里 sleep 了 100ms ，所以每个线程每秒能处理 10 个请求，这个就导致最大 QPS 最大就在 10 * 4 = 40 。

5.3 Webflux + Netty

Webflux + Netty 的组合，效果和 Webflux + Tomcat 是一致的，就不重复测试了。

6. 第三轮

看到此处，可能有胖友就懵逼了，“哎呀，Webflux 什么情况，性能这么差，是不是你测试错了呀？”。我们来使用 Reactor elastic 调度器，看看性能情况。示例代码如下：

@GetMapping("/sleep2")
public Mono<String> sleep2() {
    return Mono.defer(() -> {
        try {
            Thread.sleep(100L);
        } catch (InterruptedException ignored) {
        }
        return Mono.just("world");
    }).subscribeOn(Schedulers.elastic());
}

• 怎么理解 Reactor 内置的 elastic 调度器呢？胖友可以先简单理解成 ExecutorService 的 newCachedThreadPool 线程池，一个无限大的线程池。我们来想想下，如果使用了它，那么每个请求会进入线程池中，进行 sleep 100ms ，然后完成返回，并且不限量，这个非常关键！

下面，开始我们的表演。这里，我们依然使用 Webflux + Tomcat 的组合。

🚚 300 并发

$wrk -t50 -c300 -d30s http://127.0.0.1:8080/sleep2

Running 30s test @ http://127.0.0.1:8080/sleep2
  50 threads and 300 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   100.72ms    1.94ms 300.90ms   97.04%
    Req/Sec    59.47      3.25   102.00     95.77%
  89122 requests in 30.10s, 10.04MB read
Requests/sec:   2961.05
Transfer/sec:    341.58KB

• 2961.05 QPS
• 100.72ms Avg Latency

🚚 1000 并发

$wrk -t50 -c1000 -d30s http://127.0.0.1:8080/sleep2

Running 30s test @ http://127.0.0.1:8080/sleep2
  50 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   104.23ms   14.70ms 353.66ms   95.03%
    Req/Sec   193.77     20.42   252.00     91.85%
  288903 requests in 30.10s, 32.55MB read
Requests/sec:   9598.51
Transfer/sec:      1.08MB

• 9598.51 QPS
• 104.23ms Avg Latency

🚚 3000 并发

$wrk -t50 -c3000 -d30s http://127.0.0.1:8080/sleep2

./wrk -t50 -c3000 -d30s http://127.0.0.1:8080/sleep2
Running 30s test @ http://127.0.0.1:8080/sleep2
  50 threads and 3000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   185.33ms  103.05ms   1.30s    89.87%
    Req/Sec   345.33    160.48   669.00     61.51%
  468276 requests in 30.10s, 52.75MB read
Requests/sec:  15555.70
Transfer/sec:      1.75MB

• 15555.70 QPS
• 185.33ms Avg Latency

🚚 5000 并发

$wrk -t50 -c5000 -d30s http://127.0.0.1:8080/sleep2

[root@iZuf6hci646px19gg3hpuwZ wrk]# ./wrk -t50 -c5000 -d30s http://127.0.0.1:8080/sleep2
Running 30s test @ http://127.0.0.1:8080/sleep2
  50 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   269.61ms  157.51ms   1.90s    86.07%
    Req/Sec   349.51    232.46     1.01k    62.82%
  455185 requests in 30.10s, 51.28MB read
Requests/sec:  15122.01
Transfer/sec:      1.70MB

• 15122.01 QPS
• 269.61ms Avg Latency

小结

• 从自身角度：
  • 300 和 1000 并发的时候，并发和 QPS 基本是 1:10 ，这是因为每个请求 sleep 100ms ，那么在线程池足够大小的时候，最大 QPS 是并发 * 10 ，所以 300 并发时，是 3000 QPS 不到，1000 并发时，是 10000 QPS 不到。
  • 3000 和 5000 并发的时候，并发量在 15000 QPS 左右，趋于稳定。不过按照上面并发和 QPS 是 1:10 的说法，应该要能达到 30000 或 50000 QPS ，但是从实际自己打的日志，到不了这么多线程数。再具体的原因，就暂时没去分析。
• 对比 SpringMVC + Tomcat 角度：Webflux 比 SpringMVC 的 QPS 提升很多。我们从示例中，也可以看到，得益于可以将请求提交到 Reactor 无限大的线程池中，从而提高并发性能。不过，我们也一定要清楚这一点，为什么 Webflux 性能得到了提升。当然，我们也可以使用 SpringMVC + Servlet 3.1 的特性，也能实现类似的效果，只是说会麻烦一些。

666. 彩蛋

舒服，通过这个测试，对 Webflux 的一些东西，也想的更明白了。当然，因为本文并未模拟真正接入有 IO 的情况下的测试，这个我们留在网关 Spring Cloud Gateway 与 Zuul 的对比中。

另外，Webflux 如果搭配上协程 ，会不会更加愉快呢？毕竟，Java 的线程，是重量级的，最小需要分配大内存，也是 256K ，并且切换线上下文，也是不低的成本。

推荐以及参考如下文章：

• 《Webflux 快速入门》
• 《Reactor 3 快速上手 —— 响应式 Spring 的道法术器》
• 《原始性能表格 - Spring Boot 2 Webflux vs. Spring Boot 1》
• 《反应式编程概览（中文版）》
• 《Spring WebFlux性能测试 —— 响应式Spring的道法术器》
• 《WebFlux 性能问题和适用场景》
• 《Spring 5 WebFlux 性能测试[译]》