How Puma Works
summary
Puma explains how a pre-forking + threaded model actually runs Rails: master forks workers that share a listening socket, each worker has a thread pool that calls the Rack app, and a reactor buffers requests so slow uploads don’t tie threads. It only speaks HTTP/1.x, has ~260 million downloads and ~8,000 lines of code (≈5k Ruby), ships C extensions and miniSSL, and yields ≈2× throughput with a few threads vs one, so the design clearly works in production.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:51Puma in Rails popularity
- 4:16Design goals and parallelism
- 12:14Rack apps with Puma
- 18:17Pre-forking architecture
- 21:05Thread pools and GIL
- 26:05Reactor buffering requests
- 27:31Puma codebase and extensions
- 30:43Puma classes and architecture
- 32:49Maintaining Puma
- 35:58Contributing to Puma
- 39:11Becoming a contributor
- 40:14Closing remarks
related talks
40mKeynote: A Beginner's Guide to Puma Internals
25mUnderstanding Ruby Web Server Internals: Puma, Falcon, and...
25mPuma or Falcon What's the Best Choice for Scalability?
21mConquering Massive Traffic Spikes in Ruby Applications with Pitchfork
36mReal-Time Rails
39mWhat the fork()?
37mRhebok, High Performance Rack Handler
36mUnicorn Unix Magic Tricks