ruby web-servers performance-optimization developer-tools

Kino: A high-performance Ractor web server for Ruby 4.0

github.com

August 21, 2026

17 min read

🔥🔥🔥🔥🔥

47/100

Summary

Kino is an open-source Rack 3 web server for Ruby 4.0+ that uses a Rust front end built on Tokio and Hyper to manage networking and dispatch requests to Ruby workers. In Ractor mode, it runs Ractor-shareable Rack applications across CPU cores in a single process; in threaded mode, it supports any Rack application, including Rails, but Ruby’s Global VM Lock serializes CPU-bound Ruby execution. The server includes graceful draining, worker crash respawning, bounded queues that return 503 responses under pressure, request timeouts, TLS through rustls, access and application logging, and monitoring endpoints. Benchmarks on an AWS c7a.2xlarge server with eight AMD EPYC cores, Ruby 4.0.5, and YJIT showed Kino Ractor mode serving 77,999 CPU-bound fib requests per second, versus 58,006 for an eight-worker Puma cluster. The Ractor benchmark application used 148 MB proportional set size, compared with 1,068 MB for Puma’s cluster. Kino’s threaded Rails hello-world configuration used 92 MB versus Puma’s 389 MB, but handled 2,637 requests per second compared with Puma’s 12,138 because Puma used eight processes across all cores. Ractors remain officially experimental in Ruby 4.0, and Rails is not currently Ractor-shareable. Kino’s kino --check command identifies objects and captured state that prevent an app from using Ractor mode.

Key Takeaways

Kino uses Rust-based Tokio and Hyper networking with parallel Ruby Ractors for Ractor-shareable Rack 3 applications.
On the stated eight-core benchmark system, Kino Ractor mode processed CPU-bound requests 34% faster than a Puma fork cluster while using about one-seventh of its memory for the synthetic app.
Kino’s threaded fallback supports Rails and other non-shareable Rack apps, but CPU-bound Ruby work remains constrained by the Global VM Lock.
Rails currently runs in Kino only through threaded fallback mode; Puma delivered about 4.6 times the Rails hello-world throughput in the cited test while using about four times the memory.
Kino provides a Ractor compatibility checker, backpressure queues, timeout handling, TLS, lifecycle hooks, and Prometheus-compatible monitoring.

What the discussion said

The thread did not meaningfully discuss AI or machine-learning implications. Commenters focused instead on Ruby’s ecosystem health: whether a new Ractor-based web server has adequate documentation, whether Ractor or Fiber is the more promising concurrency route for Rails, and whether Ruby can credibly claim high performance against JVM-based alternatives. One reader treated missing documentation as part of a broader cultural weakness in Ruby projects, while replies argued that poor documentation is a universal engineering failure and that readable Ruby reduces some documentation burden. The Ractor-versus-Fiber exchange likewise stayed at the level of Ruby’s response to the GIL and the influence of large Rails adopters. Some welcomed momentum around Ractor in Rails and core Ruby, while others dismissed Ruby as a declining platform or challenged the premise that it can be fast. None of those points established a clear connection to model development, AI deployment, AI APIs, training, safety, or AI-specific accessibility. As a result, the discussion offers no qualifying positive or negative sentiment about AI/ML itself.

Read original article

View story →