Vertx为何比Spring WebFlux具备更优的流量处理能力?
Vertx 与 Spring WebFlux 流量处理能力差异解析
代码示例
Vertx 实现
workerExecutor = vertx.createSharedWorkerExecutor("test-worker-pool", 200, 30, TimeUnit.SECONDS); router.get("/test").handler(context ->{ workerExecutor.executeBlocking(future -> { try { Thread.sleep(3); } catch (InterruptedException e) { throw new RuntimeException(e); } future.complete("Successful"); }, false ,asyncResult -> { if (asyncResult.succeeded()) { sendSuccess(context.response()); } else { sendError(asyncResult.cause().getMessage(), context.response()); } }); });
Spring WebFlux 实现
private Scheduler scheduler = Schedulers.newBoundedElastic(200, 10, "MyThreadGroup"); @GetMapping() public Mono<String> getEmployeeById() { return Mono.fromCallable(this::handleFile).subscribeOn(scheduler); } private String handleFile(){ try { Thread.sleep(3); return "Successful"; } catch (InterruptedException e) { throw new RuntimeException(e); } }
JMeter 分钟级压测结果
测试计划
采用JMeter进行分钟级压测,具体配置参考对应测试计划图
Vertx 压测数据
Total request: 726320 req/min Throughput: 11194 req/s
Spring WebFlux 压测数据
Total request: 584532 req/min Throughput: 9564 req/s
为什么 Vertx 流量处理能力更优?
- 线程调度更轻量化:Vertx 的 Worker Pool 基于 Netty 事件循环直接扩展,任务调度逻辑简单直接,没有 Reactor 调度器的额外封装开销。Spring WebFlux 使用的
newBoundedElastic调度器需要处理订阅上下文传递、信号转换等逻辑,增加了任务调度的损耗。 - 框架设计更简洁:Vertx 是专注于异步 IO 的底层框架,没有 Spring 生态带来的容器管理、AOP、自动装配等额外开销。Spring WebFlux 构建在 Spring 框架之上,即便采用响应式编程,依然会携带这些框架层面的运行成本,高并发下会累积影响吞吐量。
- 阻塞任务处理效率更高:测试用例中的阻塞任务(
Thread.sleep),Vertx 的 worker 线程池直接分发任务,上下文切换和任务管理的成本更低;而 Spring WebFlux 的 Reactor 链路在处理阻塞任务时,多了一层响应式信号的处理逻辑,每个任务的处理耗时被放大,最终体现为吞吐量差距。 - Netty 集成更紧密:Vertx 完全基于 Netty 构建,从 IO 层到业务处理的链路没有中间转换环节,适配成本极低。Spring WebFlux 虽然依赖 Netty,但请求需要经过 Spring 的分发、解析等适配层,这些环节会带来额外的处理开销。
内容的提问来源于stack exchange,提问作者namnt
相关产品推荐
相关产品推荐

