Asynchronous Rails
summary
A concrete claim: Ruby’s fiber scheduler lets synchronous Rails apps run request‑per‑fiber and multiplex IO so waiting overlaps instead of blocking. Evidence: async + Falcon server show >10k req/s, a single process streams ~2.4 GB/s, and a migration story cites ~2 billion rows at ~15,000 rows/sec/core (48 cores) as the scaling challenge. Work done: Rack evolves to Rack 3, Rails 7.1 adds per‑fiber isolation, Postgres PG and Trilogy adapters integrate and the approach demonstrably reduces latency and memory use.
AI-written summary · about
chapters (13)
- 0:00Asynchronous Rails intro
- 3:10Sync vs async execution
- 7:43Why async matters in Rails
- 10:56Reducing wait with fibers
- 16:50Ruby fiber scheduler & async gem
- 18:13Ruby async app foundation
- 18:34Rack 3 streaming
- 23:53Testing Rack 3 with Reconform
- 24:34Falcon vs Puma servers
- 26:43Rails 7.1 Rack 3 support
- 30:57Fiber DB adapters
- 31:59Using Rack 3 & Rails 7.1
- 32:21Summary & async Rails future
related talks
23mAsync Ruby
28mEvented Ruby vs Node.js
27mIn-Depth Ruby Concurrency: Navigating the Ruby concurrency landscape
23mConcurrency Showdown: Threads vs. Fibers
26mConcurrency in Ruby: From fork() to Fiber
32mLook Ma, No Sidekiq: A peek into async future
30mScaling Rails with JRuby in 2022
34mHow to scale a Ruby webservice