Concurrency in Ruby: From fork() to Fiber
summary
Builds a simple TCP server, measures throughput, and shows concrete results: the serial loop manages ~17 req/s, fork()/processes add true parallelism but hit Docker CPU limits (4 cores), threads + GVL speed IO (sleep/DB) but not CPU work, a thread pool helps, fibers + async gem yield huge IO wins and plus pre-forking edges out threads, and the real bug is a CPU‑bound queue with many threads — fix by raising process count. ractors not production-ready
AI-written summary · about
chapters (13)
- 0:00Concurrency in Ruby intro
- 2:38Concurrency vs parallelism
- 6:10Ruby concurrency overview
- 6:32Processes for parallelism
- 10:26Processes benefits and limitations
- 10:47Threads and the GVL
- 13:40Thread pools in practice
- 15:26Fibers as coroutines
- 17:52Async servers with Fiber
- 19:59Solving the original performance problem
- 21:01Ruby concurrency tools recap
- 21:25Ractors introduction
- 24:17Q&A on Ractors
related talks
35mConcurrency in Ruby: Threads, Fibers and Ractors Demystified
27mIn-Depth Ruby Concurrency: Navigating the Ruby concurrency landscape
20mSubprocesses, Threads and Fibers
54mConcurrency: Rubies, plural
23mConcurrency Showdown: Threads vs. Fibers
36mIntroduction to Concurrency in Ruby
23mParallel Processing With Ruby
23mAsync Ruby