基于Webflux与Netty的响应式REST API性能不佳问题排查求助

我基于Webflux和Netty实现了RESTful API服务，参考官方及网络Demo完成开发后，用JMeter做性能测试（线程数1000、Ramp-up=1、循环次数100），发现性能不如Spring MVC。怀疑是实现方式或思路有问题，附上配置与代码，求排查原因。

配置文件（application.yml） #

Server:
  port:10001
spring:
  r2dbc:
    url:r2dbc:mssql://localhost:1433/TutorialDB
    username:sa
    password:123456
    pool:
      max-size:32
      max-idle-time:2m
      max-life-time:10m
      acquire-retry:3

依赖配置（pom.xml） #

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-webflux</artifactId>
  <version>3.1.2</version> 
</dependency>
<dependency>
  <groupId>io.projectreactor.netty</groupId>
  <artifactId>reactor-netty</artifactId>
</dependency>
<dependency>
  <groupId>io.projectreactor</groupId>
  <artifactId>reactor-core</artifactId>
  <version>3.5.8</version>
</dependency>
<dependency>
  <groupId>io.projectreactor</groupId>
  <artifactId>reactor-test</artifactId>
  <scope>test</scope>
  <version>3.6.2</version>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <version>3.1.2</version>
</dependency>
<dependency>
  <groupId>io.projectreactor</groupId>
  <artifactId>reactor-test</artifactId>
</dependency>
<dependency>
  <groupId>io.projectreactor</groupId>
  <artifactId>reactor-core</artifactId>
  <version>3.6.2</version>
  <scope>compile</scope>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-r2dbc</artifactId>
  <version>3.1.2</version>
</dependency>
<dependency>
  <groupId>io.r2dbc</groupId>
  <artifactId>r2dbc-pool</artifactId>
  <version>1.0.0.RELEASE</version>
</dependency>
<dependency>
  <groupId>io.r2dbc</groupId>
  <artifactId>r2dbc-mssql</artifactId>
</dependency>
<dependency>
  <groupId>com.mysql</groupId>
  <artifactId>mysql-connector-j</artifactId>
  <scope>runtime</scope>
</dependency>

<dependency>
  <groupId>io.asyncer</groupId>
  <artifactId>r2dbc-mysql</artifactId>
  <version>1.0.6</version>
</dependency>

Repository层代码 #

public interface DeviceTypeDetailRepository extends ReactiveCrudRepository<DeviceTypeDetail, Long> { 
}

Service层代码 #

@Service
public class DeviceTypeDetailServiceImpl implements DeviceTypeDetailService {

    private final DeviceTypeDetailRepository deviceTypeDetailRepository;
    
    public DeviceTypeDetailServiceImpl(DeviceTypeDetailRepository deviceTypeDetailRepository) {
        this.deviceTypeDetailRepository = deviceTypeDetailRepository;
    }
    
    @Override
    public Flux<DeviceTypeDetail> FetchAll(){
        return deviceTypeDetailRepository.findAll();
    }
}

Controller层代码 #

@CrossOrigin
@RestController
@RequestMapping("/api/devicetypedetail")
public class DeviceTypeDetailController {
    @Autowired
    private DeviceTypeDetailService deviceTypeDetailService;

    @GetMapping("/all")
    public Flux<DeviceTypeDetail> FetchAll() {
        return deviceTypeDetailService.FetchAll();
    }
}

JMeter性能测试报告 #

Webflux版本 #

线程数=1000，Ramp-up=1，循环次数=100

Spring MVC版本 #

线程数=1000，Ramp-up=1，循环次数=100

排查分析 #

从给出的配置和代码来看，几个可能的性能瓶颈点：

1. 依赖冲突与冗余

   • pom.xml中reactor-core同时引入3.5.8和3.6.2两个版本，reactor-test也重复引入，版本不一致会引发运行时兼容性问题，拖慢性能。
   • 同时引入了SQL Server和MySQL的R2DBC驱动，但配置文件用的是SQL Server，多余的MySQL依赖会增加类加载开销，建议移除不需要的依赖。

2. 数据库连接池配置不足

   • R2DBC连接池max-size=32，在1000并发请求下，连接池会成为明显瓶颈。Webflux非阻塞模型需要足够的数据库连接支撑高并发，建议根据SQL Server的max_connections参数，将max-size调整为64或128，同时增加initial-size提前初始化连接，避免高峰时的连接创建开销。

3. 测试场景不合理

   • Ramp-up=1意味着1秒内启动1000个线程，瞬间拉满并发，这种场景下Webflux的低资源消耗优势难以体现，反而会因连接池排队导致响应时间变长。建议调整Ramp-up为10秒，模拟真实的并发递增场景再对比。
   • 如果findAll()返回大量数据，JMeter默认可能会把整个Flux收集成列表再处理，抵消Webflux流式返回的优势，需检查JMeter HTTP请求配置是否支持流式响应处理。

4. 代码细节优化

   • Controller改用构造注入（和Service层保持一致），避免运行时依赖注入的额外开销。
   • 检查DeviceTypeDetail实体类的R2DBC映射配置，确保没有不必要的字段关联或低效映射逻辑。

内容的提问来源于stack exchange，提问作者Benedict Deng