Conquering Massive Traffic Spikes in Ruby Applications with Pitchfork
summary
Swapping Unicorn for Pitchfork and enabling its le_fork_after 50,100,1000 warm‑forking removes cold workers so prewarmed processes handle the surge; prewarming is triggered during the 30‑minute scale‑out window rather than at spike time. Cold‑start CPU and template compilation stop causing P90/P95 to blow up — a spike that previously produced minute‑long latencies now shows only minor bumps despite a 3× traffic increase. Requires fork‑safety checks and replacing worker‑killer logic. Unicorn -> Pitchfork swap
AI-written summary · about
chapters (17)
- 0:00Introduction
- 3:23Traffic spike challenges
- 4:29Current limits with Unicorn
- 7:05Finding latency causes
- 8:09Cold worker impact
- 10:40Unicorn request routing
- 12:06Prewarming all workers
- 12:48Pitchfork leapwork feature
- 14:15Migration and testing
- 15:40Configuring leapfork thresholds
- 16:43Triggering leapfork quietly
- 17:04Worker killer for Pitchfork
- 17:27Pitchfork results
- 18:55Latency and experience gains
- 19:37Memory sharing benefits and limitations
- 20:21When to use leapwork
- 20:42Conclusion
related talks
36mUnicorn Unix Magic Tricks
25mUnderstanding Ruby Web Server Internals: Puma, Falcon, and...
39mWhat the fork()?
25mPuma or Falcon What's the Best Choice for Scalability?
30mGrow Your Unix Beard Using Ruby
41mHow Puma Works
27mIn-Depth Ruby Concurrency: Navigating the Ruby concurrency landscape
41mForget Scaling: Focus on Performance