In-Depth Ruby Concurrency: Navigating the Ruby concurrency landscape
summary
Concrete rules and results: use preload + re-fork (Pitchfork) to share memory—Shopify sees ~30% memory reduction and 9% latency drop; match process count to CPU cores and run 1.25–2x for concurrency. Use threads for IO-heavy jobs (Sidekiq: ~5–10 threads for typical 25–50% IO), fibers with the Async/FiberScheduler for deterministic, high‑concurrency IO (Falcon); use Ractors experimentally for true parallelism where libraries allow (Mooro shows the pattern). Apply Amdahl’s law to size threads/fibers.
AI-written summary · about
chapters (18)
- 0:00Ruby concurrency intro
- 1:27Ruby processes for parallelism
- 3:54Processes vs concurrency
- 5:17Optimizing process count
- 6:19Memory overhead of processes
- 7:43Pitchfork server technique
- 9:09Ruby threads and GIL
- 11:58Ruby threads use cases
- 13:00Thread allocation with Amdahl’s Law
- 14:47Ruby reactors and event loops
- 16:33Puma server benefits
- 16:56Ruby fibers scheduling
- 18:00Fiber scheduler and async gem
- 20:30Fibers vs threads comparison
- 21:53Ruby reactors for tasks
- 22:55Morrow server actors
- 23:38Ruby concurrency key takeaways
- 25:47Future Ruby concurrency
related talks
35mConcurrency in Ruby: Threads, Fibers and Ractors Demystified
26mConcurrency in Ruby: From fork() to Fiber
37mLetting Concurrency Help You Today
54mConcurrency: Rubies, plural
36mModern Concurrency Practices in Ruby
36mIntroduction to Concurrency in Ruby
20mSubprocesses, Threads and Fibers
39mConcurrent Systems in Ruby