From Request To Response And Everything In Between
summary
Follow a single HTTP request through Puma to a Rails process, see threads vs processes, and measure where latency accumulates — queue time, service time, database waits. The concrete claim is a sizing formula: request arrival rate × average total response time × 4 gives processes needed; examples show five requests/sec with 225ms average → five processes. Coverage includes GVL, thread contention, ActiveRecord connection pool sizing and the practical DB connection ceiling and tradeoffs between more threads or more servers.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 3:06Request flow in Rails
- 8:43Scaling with processes
- 11:51Optimal process count
- 21:25Multi-threaded processes and GVL
- 29:10Database connection pooling
- 33:22Request to response
- 35:50Closing remarks
related talks
41mHow Puma Works
27mInside Rails: The Lifecycle of a Response
30mRails Performance monitoring: A primer for developers
26mRails Performance Monitoring 101: A Primer for Developers
31mA Rails performance guidebook: from 0 to 1B requests/day
19mKeeping High-Traffic Systems Running When Things Go Wrong
41mRequest and Response
30mThe Queue Continuum: Applied Queuing Theory