Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix typo in the first virtual thread blog post #1803

Merged
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions _posts/2023-09-19-virtual-thread-1.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
Loading