本文比较了 Spring Boot 应用程序中的不同请求处理方法:ThreadPool、WebFlux、协程和虚拟线程 (Project Loom)。
在本文中,我们将简要描述并粗略比较可在 Spring Boot 应用程序中使用的各种请求处理方法的性能。
高效的请求处理在开发高性能后端应用程序中起着至关重要的作用。传统上,大多数开发人员使用 Spring Boot 应用程序中嵌入的 Tomcat,其默认线程池用于在后台处理请求。然而,替代方法近年来越来越受欢迎。WebFlux 利用事件循环进行响应式请求处理,而 Kotlin 协程及其suspend功能也越来越受到青睐。
此外,引入虚拟线程的 Project Loom 预计将在 Java 21 中发布。不过,尽管 Java 21 尚未发布,但从 Java 19 开始我们就已经可以尝试 Project Loom 了。因此,在本文中,我们还将探索使用虚拟线程来处理请求。
此外,我们将使用JMeter 进行高负载测试的不同请求处理方法进行性能比较。
性能测试模型
我们将使用以下模型来比较请求处理方法:

流程就像蛋糕一样简单:
- 客户端(JMeter)将并行发送 500 个请求。每个线程将等待响应,然后重复发送另一个请求。请求超时时间为 10 秒。测试时间将持续1分钟。
- 我们正在测试的 Spring Boot 应用程序将接收来自客户端的请求并等待来自慢速服务器的响应。
- 慢速服务器以随机超时响应。最大响应时间为 4 秒。平均响应时间为2秒。
处理的请求越多,性能结果就越好。
1. 线程池
默认情况下,Tomcat 使用线程池(有时称为连接池)来处理请求。
概念很简单:当请求到达 Tomcat 时,它会从线程池中分配一个线程来处理该请求。该分配的线程将保持阻塞状态,直到生成响应并将其发送回客户端。
默认情况下,线程池最多包含 200 个线程。这基本上意味着单个时间点只能处理 200 个请求。
但这个参数和其他参数是可配置的。
默认线程池
让我们对一个带有嵌入式 Tomcat 和默认线程池的简单 Spring Boot 应用程序进行性能测量。
线程池容纳 200 个线程。对于每个请求,服务器都会对另一台服务器进行阻塞调用,平均响应时间为两秒。因此我们可以预计每秒 100 个请求的吞吐量。
|
请求总数
|
吞吐量,请求/秒
|
响应时间,毫秒
|
错误率,%
|
|||
|
平均的
|
最小
|
90%线
|
最大限度
|
|||
|
3356
|
91.2
|
4787
|
155
|
6645
|
7304
|
|

655

被折叠的 条评论
为什么被折叠?



