Srping 响应式框架 WebFlux 的性能小测试_WebClient连接池

Posted 2022-09-01 catoop

平时只是听说 Spring WebFlux 性能在高并发的 HTTP 场景下效果比较明显，但是一直没有亲自验证一下。
本文用了一个及其简单的例子，使用 Jmeter 做了一下压测，过程和效果如下图所示：

先对测试的环境做一个描述，为了减少其他任何因素导致的干扰，创建了一个基础干净的工程：

1、使用 idea 创建一个初始化的 spring-boot 项目
2、添加一个 Controller 填写2个方法，一个是使用 Servlet 模式的，一个是使用 WebFlux 模式的
3、没有做任何其他配置
4、使用 Jmeter 进行了测试，1000个线程间隔时间1秒，不设停止时间持续跑（跑到 tps 只有小数点后面的数字在动）

Controller 代码如下：

@RequestMapping("/demo")
@RestController
public class DemoController 

    @RequestMapping(value = "/show")
    public Mono<String> show() 
        return Mono.just("单红宇").delayElement(Duration.ofSeconds(1));
    

    @RequestMapping(value = "/show2")
    public String show2() throws InterruptedException 
        TimeUnit.SECONDS.sleep(1);
        return "单红宇II";
    

运行结果截图如下：

1、非阻塞式 WebFlux 接口的测试结果

2、阻塞式 Servlet 接口的响应结果

因为没有该任何配置，spring boot 中 tomcat 的默认最大线程数是 200，可以看到 Servlet 模式下的 tps 只跑出了 198 的结果。

综上所述：本文只是做了一个比较基础简单的测试，确实能得出 “非阻塞比传统阻塞式性能高出不少”，本文的性能差距并不能作为实际性能区别，但是非阻塞式的性能提升明显却也是事实。

大部分常规的 HTTP 业务接口，推荐使用 WebFlux 框架实现，像那种高 IO 大文件传输的接口场景，可以继续保留使用 Servlet 模式开发。

写在最后：
当我把 Jmeter 中的线程数量修改为2000时，reactor 的 tps 跑到了 1965/s，有兴趣的话你可以试试把 Jmeter 的线程数量再增加试试。

你是不是以为 WebFlux 能够使程序运行的更快呢？使用 WebFlux 以后，一个接口的请求响应时间是不是就缩短了呢（相对于在没有负载干扰下的接口处理时间）？
答案是否定的，官方的也给出了明确说明 “Reactive and non-blocking generally do not make applications run faster.”

那 WebFlux 有什么用？一方面它能够提升吞吐量，另一方面在高并发场景的情况下他不会像 Servlet 模式那样请求量越大线程因为等待而出现的耗时越大的问题（当然并发量越大 reactor 的响应时间也会有所提高，只是不会像 Servlet 那么明显）。

---

调用 Reactor 接口我们需要使用对应的 WebClient 类库来操作，提供一下关于调整 WebClient 连接池的官方资料：
https://projectreactor.io/docs/netty/snapshot/reference/index.html#_connection_pool_2
https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-client-builder-reactor-resources

---

(END）