How to scale a Ruby webservice
summary
Claims that Ruby itself isn’t the bottleneck and shows concrete changes: replace Rails with a light Rack stack (we use Sinatra and Rainbows), swap ActiveRecord for Sequel/Yajl, cut classes and GC churn, and use thread pools (16 threads/process) plus persistent connections and HTTP pipelining. Result: per-process memory drops from ~350MB to ~100MB, cluster shrinks from 30 boxes at 66k RPM to 10 boxes handling ~300k RPM, demonstrating the service scales without a rewrite using these tools and limits.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 2:50Ruby is awesome
- 3:53What does your typical Ruby app look like
- 6:30Server usage
- 7:01The typical way
- 8:08How to fix it
- 8:29Slow down your app
- 8:48Reduce program
- 15:58Rainbows
- 22:05Persistent connections
- 23:24Pipelining
- 23:56Pipelining example
- 25:09Multi threading
- 28:04Avoid slow connections
- 28:14Avoid too many connections
- 29:31Killing slow connections
- 30:50Safety principles
- 31:26Summary
- 33:03Outro
related talks
30mScaling Rails with JRuby in 2022
27mScaling a Rails Monolith w/Event Driven Microservices
41mJRuby: Zero to Scale! 🔥
01h 03mRuby at Scale
43mReal World Ruby Performance at Scale
39mJRuby on Rails: From Zero to Scale
29mImprove Performance Quick and Cheap: Optimize Memory and Upgrade to Ruby 2.1
39mWhere is my scalable API?