SpringBoot3虚拟线程 & 反应式(WebFlux) & 传统Tomcat线程池性能对比

2024年 1月 31日 115.1k 0

环境:SpringBoot3.2.1 + JDK21

1. 简介

从Spring Boot 3.2 支持虚拟线程。要使用虚拟线程,需要在 Java 21 上运行,并将属性 spring.threads.virtual.enabled 设置为 true。

启用虚拟线程后,Tomcat 和 Jetty 将使用虚拟线程处理请求。这意味着处理网络请求的应用程序代码(如控制器中的方法)将在虚拟线程上运行。

启用虚拟线程后,applicationTaskExecutor Bean 将成为配置为使用虚拟线程的 SimpleAsyncTaskExecutor。任何使用应用程序任务执行器的地方,如调用 @Async 方法时的 @EnableAsync、Spring MVC 的异步请求处理和 Spring WebFlux 的阻塞执行支持,现在都将使用虚拟线程。

接下来将分别通过传统阻塞Servlet技术、使用虚拟线程及使用反应式技术WebFlux来分别对比它们的性能。

2. 性能对比

使用虚拟线程 & 传统Servlet都使用下面的接口:

@RestController
@RequestMapping("/task/default")
public class TaskDefaultController {


  @GetMapping("")
  public Object index() throws Exception {
    System.out.printf("before - %s%n", Thread.currentThread()) ;
    TimeUnit.MILLISECONDS.sleep(100) ;
    System.out.printf("after - %s%n", Thread.currentThread()) ;
    return "task - default..." ;
  }
}

先测试下启用虚拟线程执行情况。

配置:

spring:
  threads:
    virtual:
      enabled: true

控制台输出:

before - VirtualThread[#42,tomcat-handler-0]/runnable@ForkJoinPool-1-worker-1
after - VirtualThread[#42,tomcat-handler-0]/runnable@ForkJoinPool-1-worker-1

使用的是虚拟线程。

2.1 传统Tomcat线程池方式

配置线程池,如果不配置使用默认的最大线程200,整体的吞吐量将在2200作用。

server:
  tomcat:
    threads:
      min-spare: 500
      max: 1000

初始启动服务后,内存,CPU占用情况;默认启动后线程个数与上面配置一致。

图片图片

使用jmeter测试,配置如下:

图片图片

使用500个线程,循环200次,整体做100000次压测。后续的测试都会基于该配置进行。

图片图片

吞吐量为:4696

内存,CPU占用情况

图片图片

2.2 使用虚拟线程

首先开启虚拟线程

spring:
  threads:
    virtual:
      enabled: true

初始启动服务后,内存,CPU占用情况

图片图片

jmeter测试情况如下:

图片图片

吞吐量为:4677,与上面的阻塞Servlet基本差不多。但传统Tomcat线程池方式需要更多的线程才能达到这一值。

图片图片

整个过程内存使用情况,虚拟线程要比传统Tomcat线程池方式占用的多。

JDK 的虚拟线程调度器是一个工作偷取 ForkJoinPool,以先进先出(FIFO)模式运行。调度器的并行性是指可用来调度虚拟线程的平台线程数。默认情况下,它等于可用处理器的数量,但可以通过系统属性 jdk.virtualThreadScheduler.parallelism 进行调整。ForkJoinPool 与普通池不同,普通池用于并行流的实现,并以后进先出模式运行。

调整数量再进行测试,设置JVM参数

-Djdk.virtualThreadScheduler.parallelism=100 -Djdk.virtualThreadScheduler.maxPoolSize=100

设置100个平台线程来调用虚拟线程。

启动服务后,线程,内存使用情况。

图片图片

jmeter测试结果如下:

图片图片

与调整前没什么区别,反而是增加了应用的线程数量。

2.3 反应式WebFlux

引入依赖


  org.springframework.boot
  spring-boot-starter-webflux

基于webflux,我们需要重新编写接口测试。

@RestController
@RequestMapping("/task/reactor")
public class ReactorController {


  @GetMapping("")
  public Object index() throws Exception {
    // 与上面2种方式不同,reactor方式则需要使用delayElement方式来模拟耗时任务
    return Mono.just("task - reactor...").delayElement(Duration.ofMillis(100)) ;
  }
}

初始启动服务后,内存,CPU占用情况。

图片图片

jmeter测试情况如下:

图片图片

吞吐量为:4659,与上面的测试结果基本一致。

图片图片

内存使用情况要比前面几种方式占用都少。同时通过jmeter测试结果也能发现,MAX请求的最大响应时间webflux是最小的,Std.Dev:所有请求响应时间的标准差也是最小的(该值越小,平均值越可靠)。

根据测试结果,虚拟线程与webflux谁更胜一筹还不够清晰,接下来我们结合数据库操作进行测试。

3. 基于数据库测试

数据库数据准备了600w的数据。

图片图片

3.1 传统Tomcat线程池方式

基于JPA进行数据库的操作

@Entity
@Table(name = "t_user")
public class User {
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Integer uid ;
  private String name ;
}

Repository接口

public interface UserRepository extends JpaRepository {
}

Controller测试接口

@RestController
@RequestMapping("/users")
public class UserController {


  @Resource
  private UserRepository ur ;
  
  @GetMapping("/count")
  public User count() {
    return ur.findById(5800000).orElse(null) ;
  }
  
}

测试结果:

图片图片

3.2 使用虚拟线程

记得开启虚拟线程,测试结果如下:

图片图片

3.3 反应式WebFlux

需要引入如下依赖


  org.springframework.boot
  spring-boot-starter-data-r2dbc


  com.github.jasync-sql
  jasync-r2dbc-mysql
  2.1.24

配置

spring:
  r2dbc:
    url: r2dbc:mysql://localhost:3306/batch?serverZnotallow=GMT%2B8&sslMode=DISABLED
    username: root
    password: xxxooo
    pool:
      initialSize: 100
      maxSize: 100
      max-acquire-time: 30s 
      max-idle-time: 30m

实体定义,这里的注解与jpa不一样

@Table("t_user")
public class User {
  
  @Id
  private Integer uid ;
  private String name ;
}

Repository定义

public interface UserR2DBCRepository extends ReactiveCrudRepository {
}

Controller接口

@RestController
@RequestMapping("/r2dbc")
public class UserR2DBCController {


  @Resource
  private UserR2DBCRepository ur ;
  
  @GetMapping("/users")
  public Mono count() {
    return ur.findById(5800000)  ;
  }
  
}

测试结果

图片图片

根据测试结果来,webflux的整体性能远远高于虚拟线程及传统tomcat线程池的方式。

以上是本篇文章全部内容,希望对你有帮助。

完毕!!!

相关文章

JavaScript2024新功能:Object.groupBy、正则表达式v标志
PHP trim 函数对多字节字符的使用和限制
新函数 json_validate() 、randomizer 类扩展…20 个PHP 8.3 新特性全面解析
使用HTMX为WordPress增效:如何在不使用复杂框架的情况下增强平台功能
为React 19做准备:WordPress 6.6用户指南
如何删除WordPress中的所有评论

发布评论