# WebFlux 压测与调优：从 JMeter 到 EventLoop 的证据链

```text
旧方案：只压接口，不看 EventLoop 与 Direct Memory
冲突：吞吐上不去，P99 抖动，错误率升高
后果：调优靠猜，上线后偶发超时与内存泄漏
```

Owner 查询、并行保险报价、SSE 和大文件下载这四类场景，在 WebFlux 里对线程模型、背压和内存的要求完全不同。只盯着 QPS 调优，往往会把阻塞点藏进连接池或堆外内存里。

我是老李，这次在深圳南山一个保险中台项目里，被要求把四类接口压到目标水位。压测过程中发现，JMeter 报出来的错误率只是结果，真正的原因要沿着 Reactor Netty 的调用链一层层找证据。

为什么低并发正常、高并发突然雪崩？

该优先调 Scheduler、连接池，还是先改背压和响应大小？

如果选错顺序，会不会把阻塞代码藏得更深，让生产事故更难复现？

# 01、故事

```text
周三 14:30→深圳南山科兴科学园→压测 Owner 查询与并行报价→吞吐卡在 800/s，P99 超过 2s
```

周三下午两点半，我在科兴科学园 B 栋的工位上，任务是给 Owner 查询、并行保险报价、SSE 推送和大文件下载建立 JMeter 压测基线。

测试环境已经部署好，Prometheus 和 Grafana 也接上了。

压测从 50 并发开始，Owner 查询吞吐还能到 1200/s。加到 200 并发后，吞吐反而掉到 800/s，P99 从 300ms 涨到 2s 以上。

旁边产品经理一直在催，说下周要给客户演示。我打开 Grafana，发现 EventLoop 线程使用率接近 100%，但业务线程池却很空闲。

> 午后楼高云影低，
> 压测初起数先迷。
> 吞吐不升反下坠，
> 线程池里问端倪。

# 02、问题

```text
需求变化：四类接口都要过压测
冲突：低并发正常，高并发吞吐下降、P99 抖动
后果：无法给出容量结论，演示存在风险
```

Owner 查询原本是同步 JDBC 实现，后来改成 WebFlux 但保留了 `.block()`。

低并发时线程够用，问题不明显；

并发一高，EventLoop 线程被阻塞在 JDBC 调用上，导致所有请求排队。

并行保险报价用 `Flux.merge` 并发调用多个下游服务，但 WebClient 连接池默认值偏小，高并发下大量请求等待连接。

SSE 场景里，客户端消费慢时服务端没有背压控制，导致内存持续增长。大文件下载则因为一次性把整个文件读进内存，Direct Memory 出现尖峰。

> 低流平稳高流乱，
> 阻塞深藏链中间。
> 连接池小难周转，
> 背压缺失内存悬。

# 03、原理

```text
核心机制：EventLoop 非阻塞调度 + Reactor 背压 + Netty 内存池
```

Reactor Netty 的 EventLoop 线程负责所有连接读写和事件分发。任何阻塞调用都会占用 EventLoop，导致该线程上的其他连接无法及时处理。

WebFlux 的背压由 Reactive Streams 规范保证。`request(n)` 信号从下游向上游传递，控制数据生产速度。如果某一段链路丢失背压，数据会在内存中堆积。

一个反直觉判断：CPU 使用率低不代表系统空闲。EventLoop 线程可能因为阻塞调用而“假死”，此时 CPU 不高，但吞吐已经严重下降。

另一个反直觉判断：增大连接池不一定能提升吞吐。如果下游服务本身慢，连接池越大，下游压力越大，超时反而更多。

> 线程非阻是真经，
> 背压信号逆流行。
> 池大未必增吞吐，
> 假死低耗最伤情。

# 04、架构

```text
输入：JMeter 并发请求
→ Reactor Netty EventLoop
→ WebFilter
→ DispatcherHandler
→ Reactor Chain
→ WebClient/Data/Codec
输出：响应与监控指标
```

压测链路从 JMeter 发起请求，进入 Reactor Netty 的 EventLoop。

WebFilter 先处理跨切面逻辑，然后交给 DispatcherHandler 路由到具体 Controller。

Controller 内部是 Reactor Chain，可能调用 WebClient 访问下游服务，或者通过 Data 层访问数据库。Codec 负责序列化和反序列化。

每一层都有明确的边界：EventLoop 负责网络事件，业务逻辑在 Reactor 调度器上执行，阻塞操作必须隔离到专用 Scheduler。

收益是链路清晰，每一层都能独立观测。代价是排查时需要同时看线程、内存和连接池多个维度。

> 层层边界各司职，
> 网络业务两分离。
> 阻塞若入事件环，
> 全链皆受一时欺。

# 05、第一版实战

```text
环境：JDK 17 + Spring Boot 3.2 + WebFlux + JMeter 5.6
→ 配置：默认连接池、默认调度器
→ 代码：Owner 查询含 .block()
→ 启动：java -jar app.jar
→ 验证：50 并发通过，200 并发吞吐下降
→ V1：功能可用，性能不达标
```

先准备环境。JDK 17，Spring Boot 3.2，WebFlux 依赖，JMeter 5.6。应用配置保持默认，WebClient 连接池未显式设置。

Owner 查询的 V1 代码如下：

```java
@GetMapping("/owners/{id}")
public Mono<Owner> getOwner(@PathVariable Long id) {
    return Mono.fromCallable(() -> jdbcTemplate.queryForObject(
            "SELECT * FROM owners WHERE id = ?",
            new Object[]{id},
            new OwnerRowMapper()))
        .subscribeOn(Schedulers.boundedElastic());
}
```

启动应用：

```bash
java -Xms512m -Xmx1g -jar reactive-petclinic.jar
```

JMeter 线程组配置 50 并发，Ramp-up 10 秒，持续 120 秒。Owner 查询请求：

```http
GET /owners/1
Accept: application/json
```

50 并发时，Throughput 约 1200/s，P99 约 300ms，错误率 0%。

把并发加到 200，Throughput 掉到 800/s，P99 超过 2s，错误率开始出现 0.5% 的超时。

> 初版能行低流下，
> 高并一来便露瑕。
> 默认配置藏隐患，
> 压测数据说真话。

# 06、排查

```text
诊断树：吞吐下降
├─ 现象：P99 升高，错误率出现
├─ 怀疑：EventLoop 阻塞
├─ 检查：线程栈
├─ 证据：EventLoop 线程停在 JDBC 调用
├─ 根因：.block() 占用 EventLoop
└─ 修复：移除阻塞调用
```

第一个问题是 Owner 查询高并发下吞吐下降。怀疑 EventLoop 被阻塞，用 `jstack` 抓线程栈：

```bash
jstack <pid> | grep -A 20 "reactor-http-epoll"
```

示例输出：

```text
"reactor-http-epoll-3" #23 daemon prio=5 os_prio=0 tid=0x00007f8c0010b800 nid=0x1a3b runnable [0x00007f8bf5a0c000]
   java.lang.Thread.State: RUNNABLE
        at org.springframework.jdbc.core.JdbcTemplate.queryForObject(JdbcTemplate.java:123)
        at com.example.OwnerController.lambda$getOwner$0(OwnerController.java:35)
```

证据显示 EventLoop 线程直接停在 JDBC 调用上。

根因是 `Mono.fromCallable` 虽然指定了 `boundedElastic`，但上游链路中仍有 `.block()` 在 EventLoop 线程执行。

第二个问题是并行保险报价连接等待。用 `netstat` 观察连接状态：

```bash
netstat -an | grep 8081 | awk '{print $6}' | sort | uniq -c
```

示例输出：

```text
  180 ESTABLISHED
   45 SYN_SENT
   12 TIME_WAIT
```

大量 `SYN_SENT` 说明连接池不足，请求在等待建立连接。

**错误尝试：** 一开始把 WebClient 连接池调大到 2000，结果下游服务超时更多，错误率反而升高。

> 栈中证据最分明，
> 阻塞原形现真形。
> 池大曾试反添乱，
> 根因未除误用兵。

# 07、优化

```text
V1：默认配置 + .block()
→ 证据：EventLoop 阻塞、连接池不足、无背压
→ V2：移除阻塞、调连接池、加背压、流式下载
```

第一处修改：Owner 查询改为纯响应式，使用 R2DBC 替换 JDBC：

```java
@GetMapping("/owners/{id}")
public Mono<Owner> getOwner(@PathVariable Long id) {
    return ownerRepository.findById(id);
}
```

第二处修改：并行保险报价的 WebClient 连接池按下游容量调整：

```yaml
spring:
  cloud:
    gateway:
      httpclient:
        pool:
          max-connections: 500
          max-idle-time: 30s
```

第三处修改：SSE 增加背压控制，使用 `onBackpressureBuffer` 限制缓冲大小：

```java
@GetMapping(value = "/events", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<String>> streamEvents() {
    return eventPublisher
        .onBackpressureBuffer(1000)
        .map(e -> ServerSentEvent.builder(e).build());
}
```

第四处修改：大文件下载改为流式，使用 `DataBuffer` 分块写入：

```java
@GetMapping("/download")
public Mono<ResponseEntity<Flux<DataBuffer>>> download() {
    Flux<DataBuffer> dataBufferFlux = DataBufferUtils.read(
            new FileSystemResource("/data/large-file.bin"),
            new DefaultDataBufferFactory(),
            8192);
    return Mono.just(ResponseEntity.ok()
            .header(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=large-file.bin")
            .body(dataBufferFlux));
}
```

> 阻塞移除换响应，
> 连接池调按容量。
> 背压缓冲限边界，
> 流式下载不积仓。

# 08、演进

```text
V2：响应式数据访问 + 合理连接池 + 背压 + 流式下载
→ 能力：高并发下吞吐稳定，P99 可控
→ 遗留：下游慢服务仍需熔断与降级
```

用 V1 同一组请求复测。200 并发下，Owner 查询 Throughput 恢复到 1500/s，P99 降到 400ms，错误率 0%。

并行保险报价在 300 并发下，Throughput 从 600/s 提升到 1100/s，P99 从 3s 降到 800ms。

SSE 场景在客户端消费慢的情况下，内存使用稳定在 512MB 以内，不再持续增长。

大文件下载的 Direct Memory 峰值从 1.2GB 降到 300MB，下载吞吐提升 40%。

遗留问题是下游慢服务仍然可能拖垮整体链路，需要引入熔断、超时和降级策略。

> 同组请求前后比，
> 吞吐升来延迟低。
> 内存平稳不狂涨，
> 遗留熔断待补齐。

# 09、洞见

```text
从现象到判断：压测不是压接口，是压链路
```

## 反直觉判断：CPU 低不代表系统健康
```text
EventLoop 假死→CPU 低→吞吐骤降
```

EventLoop 线程被阻塞时，CPU 使用率可能很低，但吞吐已经严重下降。判断系统健康要看 EventLoop 线程状态和队列长度，而不是只看 CPU。

## 反直觉判断：连接池不是越大越好
```text
池大→下游压力大→超时更多
```

连接池大小应该匹配下游服务的实际处理能力。盲目调大连接池，只会把压力传导给下游，导致超时和雪崩。

## 背压是内存的最后防线
```text
无背压→缓冲无限→内存泄漏
```

SSE 和大文件下载场景里，背压缺失会让内存持续增长。必须在链路中显式设置缓冲边界，否则高并发下必然出现内存问题。

## 证据链比直觉更可靠
```text
JMeter→EventLoop→WebFilter→DispatcherHandler→Reactor Chain→WebClient/Data→Codec
```

每一层都有可观测的指标。调优时沿着这条链找证据，比凭经验猜更高效。

> 低耗未必是真闲，
> 池大或成下游煎。
> 背压一失内存险，
> 证据链上见真篇。

# 10、系统落地

```text
入口：JMeter 并发请求
→ 服务：Reactive Petclinic
→ 本模块：压测与调优
→ 存储：R2DBC + 下游服务
→ 未实现：熔断降级与容量规划
```

原来系统只有基础接口，没有压测基线和调优证据。本篇增加了 JMeter 压测方案、EventLoop 排查方法和四类场景的优化配置。

现在能对 Owner 查询、并行报价、SSE 和大文件下载进行容量评估，并沿调用链定位性能瓶颈。

下一篇需要补充熔断、降级和容量规划，让系统在依赖故障时依然可控。官方文档可参考 Spring WebFlux 文档首页。

> 压测调优入系统，
> 容量评估有依凭。
> 熔断降级尚缺位，
> 下篇再把稳步行。

# 11、小结

```text
三问三答：
阻塞是主因→先移除阻塞
连接池按容量→不是越大越好
背压与流式→内存稳定关键
```

为什么低并发正常、高并发雪崩？因为 EventLoop 被阻塞调用占用，高并发下所有请求排队。

该优先调什么？先移除阻塞代码，再按下游容量调连接池，最后加背压和流式处理。

选错顺序的后果？如果先调连接池，会把压力传导给下游，导致超时更多，阻塞问题被掩盖。

当前状态：四类场景压测通过，吞吐和延迟达标，内存稳定。

> 阻塞先除是正途，
> 池按容量莫贪图。
> 背压流式双管下，
> 压测调优见坦途。

# 12、作业

```text
理解→实战→排障→架构判断
```

## 理解题：为什么 EventLoop 阻塞会导致吞吐下降，即使 CPU 使用率很低？

EventLoop 线程负责所有连接的事件分发。一旦被阻塞，该线程上的其他连接无法及时处理，请求排队。CPU 使用率低是因为线程在等待而非计算，但吞吐已经严重下降。

## 实战题：用 JMeter 对 Owner 查询做 50 到 500 并发压测，记录 Throughput、P99 和错误率，并画出并发-吞吐曲线。

从 50 并发开始，每次增加 50，持续 120 秒。记录每个并发级别的 Throughput、P50/P95/P99 和错误率。观察吞吐拐点，拐点处即为当前配置的容量上限。

## 排障题：压测时发现 Direct Memory 持续增长，最终 OOM，如何定位和修复？

先抓取堆外内存使用情况，确认是 Direct Buffer 泄漏还是缓冲未释放。然后检查大文件下载和 SSE 链路是否有背压控制，是否一次性读取整个响应。修复方式是改为流式处理并设置缓冲上限。

## 架构判断题：下游服务响应慢时，是增大 WebClient 连接池还是引入熔断降级？

应该引入熔断降级。增大连接池只会让更多请求进入慢服务，加剧下游压力。熔断可以在下游不可用时快速失败，降级可以返回兜底数据，保护整体链路。

> 理解阻塞方知根，
> 实战压测见真金。
> 排障内存寻泄漏，
> 架构判断熔断亲。

# 13、升华

```text
工程结论：压测是证据链，不是数字游戏
```

压测的价值不在于跑出多少 QPS，而在于沿调用链找到瓶颈证据。EventLoop 线程状态、连接池队列、背压缓冲和 Direct Memory 是四个必须同时观测的维度。

调优顺序比调优动作更重要。先移除阻塞，再调连接池，最后加背压和流式处理。顺序错了，问题会被掩盖，生产事故更难复现。

下一篇将引入熔断、降级和容量规划，让系统在依赖故障时依然可控。

> 压测非为数字高，
> 证据链上见真招。
> 顺序若错根难断，
> 熔断降级待明朝。

**系列项目：** Reactive Petclinic 保险中台

**已完成：** WebFlux 基础、Mono/Flux、EventLoop、DispatcherHandler、Controller、WebClient、安全、缓存、WebTestClient

**本篇：** JMeter 压测与调优

**下一篇：** 熔断降级与容量规划

Owner 查询、并行保险报价、SSE 和大文件下载这四类场景，在 WebFlux 里对线程模型、背压和内存的要求完全不同。只盯着 QPS 调优，往往会把阻塞点藏进连接池或堆外内存里。

《SpringWebFlux7实战》第19招 JMeter把EventLoop问题压出来

用 JMeter 压测 WebFlux 四类场景，沿调用链定位阻塞、连接池与背压问题，并用证据驱动调优。

架构师

编程语言

后端

WebFlux压测调优实战：通过JMeter压测发现EventLoop阻塞、连接池不足、背压缺失导致的吞吐下降与P99抖动。沿ReactorNetty调用链定位问题，优先移除阻塞代码，按下游容量调整连接池，配置背压与流式下载，实现四类场景性能稳定达标。

代码解释

数据库

路由

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《SpringWebFlux7实战》第19招 JMeter把EventLoop问题压出来-腾讯云开发者社区-腾讯云

《SpringWebFlux7实战》第19招 JMeter把EventLoop问题压出来

《SpringWebFlux7实战》第19招 JMeter把EventLoop问题压出来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐