From c77835e5112b18102dddbedf04e414514f38590c Mon Sep 17 00:00:00 2001 From: Clement Escoffier Date: Fri, 29 Sep 2023 13:14:34 +0200 Subject: [PATCH] Fix typo (Thanks Aurea) --- _posts/2023-09-19-virtual-thread-1.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2023-09-19-virtual-thread-1.adoc b/_posts/2023-09-19-virtual-thread-1.adoc index 1e451b74ba1..aa9394d7447 100644 --- a/_posts/2023-09-19-virtual-thread-1.adoc +++ b/_posts/2023-09-19-virtual-thread-1.adoc @@ -75,8 +75,8 @@ But there is a limit to that imperative model. You can only handle _n_ requests concurrently, with _n_ the number of threads the framework can create. OS threads are expensive. They consume memory (around 1 Mb per thread), are expensive to create, use CPU to schedule them… -Frameworks use thread pools to allow reusing idle threads, but when the concurrency level exceeds your number of threads, you start pilling up requests, reducing the response time, and, in the worst case, even rejecting requests. -Increasing the thread pool size and, consequently, increasing the memory usage can blow up your Cloud bill and deployment density. +Frameworks use thread pools to allow reusing idle threads, but when the concurrency level exceeds your number of threads, you start pilling up requests, increasing the response time, and, in the worst case, even rejecting requests. +Increasing the thread pool size and, consequently, swelling the memory usage can blow up your Cloud bill and deployment density. Futhermore, adding more threads may not even improve the concurrency as explained by the https://youtu.be/07V08SB1l8c?t=142[Little Law]. The reactive movement proposed an alternative model to work around that issue.