New post on the blog about the Global VM Lock
|
|
Howdy Rubyists,
The Speedshop blog has gotten a new update. This post is about how the Global VM Lock (GVL) works, and how it relates to scaling Ruby.
I'll spoil you with the takeaways first. If it intrigues you, I encourage you to read the whole thing:
- If you are memory bottlenecked on Ruby, you need to saturate the GVL by adding more threads, which will allow you to get more CPU work done with less memory use.
- The GVL means that parallelism is limited to I/O in Ruby, so switch to a multithreaded background job processor before you switch to a multithreaded web server. Also, you'll probably use much higher threadpool sizes with your background jobs than with your web server.
- Ruby 3 might make the GVL no longer global by allowing you to multiply VMs using Ractors. Application servers and background job processors will probably change their backend to take advantage of this, you won't really have to change much of your code at all, but you will no longer have to worry about thread safety (yay).
- Process based concurrency scales very well, and while it might lose a few microseconds to other concurrency models, these concurrency switching costs generally don't matter for the typical Rails application. Instead, the important thing is saturating CPU, which is the most scarce resource in today's computing environments
If that interests you, have a gander.
Until next week,
-Nate
|
|
|
|