If you're tired of guessing at the perfect thread count, we've solved it.
For over ten years, as the author of the Complete Guide to Rails Performance, I've taught people about Ruby's Global VM Lock (GVL) and how it impacts thread settings in multithread execution environments like Puma and Sidekiq. It's extremely complicated, and takes many hours to grok properly.
And even when you do understand it, you have the following problems to solve:
- How will I observe my workload's time spent waiting in IO? In order to set thread counts properly, you need to know what % of the time the GVL is sitting unlocked. How will you do that?
- What happens if my workload changes? Even if you do know what percent of the time your workload spends waiting on IO, is that a constant number? What if you have a batch of Sidekiq jobs which spend 60 seconds waiting on an upstream HTTP API, and then a batch of Sidekiq jobs doing something CPU heavy like Fibonacci sequences?
We realized that the only answer was that Sidekiq and Puma have to self-tune. So, after 18 months of research and development, we've now built that.
Sign up to be notified on launch
Threadpilot is already in production at a handful of Speedshop clients. We will be making it available to the public soon. To get notified, join Speedshop's email list.