In-Depth Ruby Concurrency: Navigating the Ruby Concurrency Landscape

Introduction

This talk titled In-Depth Ruby Concurrency: Navigating the Ruby Concurrency Landscape, presented by JP Camara at RubyConf 2024, dives into the complex world of Ruby concurrency, discussing when and how to effectively use different concurrency models within Ruby applications.

Key Points

Types of Ruby Concurrency:
- Ruby concurrency comprises several layers including processes, threads, fibers, and ractors, which can be visualized as nested dolls, each adding a layer of concurrency.
Processes:
- Processes are heavy in terms of memory but run in isolated memory spaces, providing true parallelism.
- An example discussed is Pitchfork, a multi-process server handling web requests by mapping each request to an individual process, optimizing CPU usage by adjusting process counts based on core availability.
Threads:
- Threads operate in a shared memory space and achieve concurrency but not parallelism due to the Global VM Lock (GVL) in Ruby.
- Suitable for I/O-bound operations, Sidekick is highlighted as a practical implementation of threading in handling background jobs effectively.
Reactor Pattern:
- The reactor pattern enhances concurrency by managing multiple I/O connections efficiently without blocking threads, increasing throughput for web servers like Puma.
Fibers:
- Fibers are lightweight compared to threads and allow for cooperative multitasking, meaning they need to yield control to each other.
- The introduction of the fiber scheduler offers the ability to handle async operations, making them more powerful in applications with high connection demands, such as with Falcon server.
Ractors:
- Ractors provide a means for parallel and concurrent execution, managing memory more strictly and allowing the sharing of some components. They’re still experimental with limited library support, but libraries like Mooro are emerging.

Conclusion

Key takeaways from the talk include:
- Maximizing vertical scalability before attempting horizontal scaling.
- Utilizing preloading to optimize memory usage in processes.
- Adjusting thread counts based on the application’s I/O percentage to ensure optimal resource usage.
- Encouraging experimentation with new concurrency models like ractors and the async fiber scheduler for future projects.
Overall, the session aimed to empower developers with greater clarity on how to navigate the Ruby concurrency landscape effectively, ensuring efficient application performance.

In-Depth Ruby Concurrency: Navigating the Ruby Concurrency Landscape
JP Camara • November 13, 2024 • Chicago, IL • Talk

When do I use a Process, or a Thread, or a Fiber? And Why? Can I use Ractors yet? What is the FiberScheduler? The M:N Thread scheduler? What's a Reactor? Do I fork, prefork, or refork? Should I care?

Do I scale up my Threads? My Fibers? My Processes? Do I use lots of lower powered, low-process horizontal scaling or high-powered, high-process vertical scaling? All of the above?

In this talk, we'll build an understanding of the Ruby concurrency landscape, and map that understanding onto concurrent gems like Sidekiq, Puma, Falcon, Pitchfork, SolidQueue and Mooro. My goal is for you to better understand how they work, what concurrency options they offer, and how you can best utilize them for scaling your applications.

RubyConf 2024