Ruby 4.0 Ractor web server Kino delivers 1.5-2× throughput with 4-7× less memory than Puma clusters

Kino replaces Ruby’s traditional process-per-core model with a single-process Ractor pool. Each Ractor has its own lock, so Ruby code runs in parallel without forking. The Rust front-end (tokio + hyper) handles network I/O, while Ractors execute Rack 3 apps. A threaded fallback mode runs non-Ractor-shareable code, including Rails, in the same process. This design eliminates the memory cost of forking while maintaining compatibility with existing Ruby web stacks.

Benchmarks on an 8-core server show Kino’s Ractor mode outperforming Puma clusters by 1.5-2× on I/O-light endpoints and 30%+ on CPU-bound tasks. Memory use drops by ~7× for Ractor-shareable apps and ~4× for Rails in threaded mode. The threaded fallback still hits the GVL ceiling, but its single-process design avoids the copy-on-write overhead of Puma’s forks. These gains come without tuning; default settings already exceed Puma’s performance.

Kino’s production features match Puma’s: graceful drain, crash supervision, bounded queues, request timeouts, and TLS support. The `kino --check` tool identifies Ractor-incompatible code, reducing trial-and-error debugging. However, Ractors remain experimental in Ruby 4.0, so Kino’s Ractor mode is not yet stable. The threaded fallback is production-ready but offers smaller gains. Adoption costs include migrating to Rack 3 and ensuring Ractor-shareability for full performance benefits.

The server’s limitations stem from Ruby’s Ractor constraints. Non-shareable code (e.g., Rails) falls back to threaded mode, losing parallelism. Even in Ractor mode, some Ruby features (e.g., class variables) block parallel execution. Kino’s Rust front-end adds a dependency but isolates network I/O from Ruby’s GVL. For now, Kino is best suited for Ractor-compatible apps or as a memory-efficient alternative to Puma clusters.