Puma or Falcon What's the Best Choice for Scalability?
summary
Puma remains the default since Rails 5 and uses pre-fork + threads with a reactor thread that buffers whole request in reactor, accepting a new request only when a worker thread is free; default threads fell from 5 to 3. Falcon is multi‑process and spawns a fiber per request, so it suits >80% I/O workloads (unlimited fibers) but not CPU‑heavy code. Pitchfork adds reforking (e.g. refork after ~1000 requests) to share warmed static memory, offers out‑of‑band GC and lower latency but can break gems like gRPC.
AI-written summary · about
chapters (8)
- 0:00Introduction and overview
- 1:15Why web servers matter
- 2:26Pre-forking concept explained
- 7:47Falcon architecture and use cases
- 10:22Puma threading and reactor queue
- 14:21Pitchfork and reforking explained
- 20:04Pitchfork advantages over Puma
- 24:52Summary and closing
related talks
25mUnderstanding Ruby Web Server Internals: Puma, Falcon, and...
41mHow Puma Works
40mKeynote: A Beginner's Guide to Puma Internals
21mConquering Massive Traffic Spikes in Ruby Applications with Pitchfork
39mWhat the fork()?
33mAsynchronous Rails
29mSurviving Black Friday: 329 billion requests with Falcon!
27mIn-Depth Ruby Concurrency: Navigating the Ruby concurrency landscape