Kino: A High-Performance Ractor Web Server for Ruby 4.0+

Kino is a cutting-edge web server designed specifically for Ruby 4.0 and beyond, leveraging Ractors to achieve true parallelism. It is built on Rack 3 and utilizes a hybrid architecture: a high-efficiency Rust front-end (powered by tokio and hyper) that distributes traffic to either parallel Ruby Ractors or a threaded fallback mode for legacy compatibility (including Rails).

---

🏗️ Architecture Overview

Unlike traditional Ruby servers that must fork multiple processes to utilize multiple CPU cores—resulting in significant memory overhead—Kino uses a single process with multiple Ractors.

Key Performance Gains

• Throughput: On 8-core hardware, Kino generally outperforms Puma fork clusters by $1.5\times$ to $2\times$ on I/O-light tasks.
• Efficiency: In specific benchmark Ractor apps, it can be $\sim 7\times$ faster.
• Memory: Uses roughly $4\times$ less RAM than Puma when serving Rails in threaded mode.
• CPU Bound: Ractor mode executes CPU-heavy tasks $>5\times$ faster than GVL-constrained threaded mode within the same process.

---

🛠️ Feature Set

Kino provides a production-ready suite of tools:

• Resilience: Crash supervision with automatic respawning and graceful draining.
• Traffic Control: Bounded queues that trigger 503 Service Unavailable backpressure.
• Security: Hardened intake featuring TLS (via rustls), body-size limits, and deadlines for TLS handshakes and "slowloris" attacks.
• Observability: Live statistics, async application logging, and a customizable on_error hook for integration with error trackers.
• Developer Experience: A familiar config DSL, a dedicated CLI, and the same worker $\times$ thread topology users expect.

[!IMPORTANT] Experimental Status: Because Ractors are still experimental in Ruby 4.0, Kino is also considered experimental. It is intended as the premier vehicle for testing Ractors today and the gold standard once they stabilize.

The kino --check Tool

Debugging Ractor::IsolationError can be a nightmare. Kino solves this with a built-in analyzer: kino --check This command scans your application and explicitly lists every finding that prevents your app from running in Ractor mode.

---

❓ Why Kino?

The fundamental limitation of Ruby has long been the GVL (Global VM Lock), which dictates that: $\text{Execution} = \text{Only one Ruby thread at a time}$

To bypass this, servers traditionally use process forking. However, the memory cost is high because each fork requires a copy of the application. Ractors change this by providing independent locks, allowing true parallel Ruby execution within a single process.

Ruby 4.0 introduced critical improvements—such as Ractor::Port and shareable_proc—which reduced lock contention and made a Ractor-based server viable. For a deeper dive into the Rust integration, see doc/why-kino.md.

---

📊 Benchmarks

Environment: AWS c7a.2xlarge (8-core AMD EPYC 9R14, 16 GB RAM, Amazon Linux 2023). Setup: Ruby 4.0.5 + YJIT. Puma uses 8 workers $\times$ 3 threads. Kino uses 8 workers (1 thread for Ractor, 3 for threaded).

Request Throughput (req/s)

Measured via wrk (8s window, 64 connections).

Notes on Results:

1. Lanes: The + lanes (experimental per-worker-queue) config achieved the highest plaintext/10k speeds.
2. CPU: Ractor mode is $\sim 34\%$ faster than the fork cluster on pure CPU tasks.
3. I/O Tuning: Since Kino slots are threads (not processes), you can increase workers to handle I/O wait. Increasing to 32 workers boosted I/O throughput by $34\%$ over Puma while remaining CPU-efficient.
4. Legacy: The old CPU-tuning recipes are retired no longer necessary; threads 1 is now the default.

Memory Consumption (PSS)

1. Synthetic Benchmark App (Ractor-shareable)

2. Real Rails App (Threaded Fallback only)

---

🚀 Quick Start

Installation

Add the gem to your project or install via CLI. Ensure you are using Ruby 4.0+.

Basic Usage

You can launch the server using the CLI:

kino start --port 3000 --mode ractor

Configuration

Kino supports a flexible DSL for defining worker topology and thread counts, mirroring the familiarity of other Ruby servers while adding Ractor-specific controls.