Kino 是一个高性能的 Ractor 网络服务器，适用于 Ruby 4.0 及以上版本。Ruby 线程无法并行运行 Ruby 代码，因此生产环境需要为每个核心派生一个进程，并为内存中的每个副本付费。Kino 在一个小进程中在每个核心上运行您的代码。一个 Rust（tokio + hyper）前端管理网络，平行 Ractors 运行您的 Rack 3 应用，而线程回退模式则运行其他所有内容，包括 Rails。快速。在一个真实的 8 核服务器上，Kino 的每种模式在 I/O 轻量级端点上都是 Puma 副本集群的 1.5-2 倍。Ractor 模式在纯 CPU 上也占优，超过 30%。基准测试如下。内存占用很少。关于 ~7 倍的简单基准 Ractor 应用，和在回退线程模式下比 Puma 集群少约 4 倍内存。并行而不分叉。Ractor 模式下的 CPU 工作比 Kino 自身的 GVL 限制的线程模式快 5 倍以上，在同一个小进程中。包含生产级配管。优雅的排水，崩溃监督和重生，带有 503 反压的有界队列，请求超时，强化的输入（slowloris 和 TLS 握手截止期限、连接和体积限制），用于您的错误追踪的 on_error 钩子，TLS（rustls），实时统计，异步访问和应用日志。告知您原因。kino --check 精确列出了阻止您的应用进入 Ractor 模式的原因，以便您无需自行解码 Ractor::IsolationError。形状像 Puma。相同的工人 × 线程拓扑，熟悉的配置 DSL，一个 Kino CLI。如果您可以运行 Puma，您就可以运行 Kino。注意：Ractors 在 Ruby 4.0 中被正式列为实验性，服务器也是如此。线程模式是稳定的。然而，Kino 的目标是成为今天实验 Ractors 的最佳方式——以及它们变得稳定后最佳的 Ractor 服务器。 目录 为什么基准测试 安装 使用 配置文件和 CLI kino --check 请求超时 统计 日志 计时器等待 Rack 3 兼容性 Rails 何以 GVL 允许一次只运行一个 Ruby 线程。为了利用所有核心，Ruby 服务器需要派生进程，而每个派生操作都会消耗一个完整的应用副本。Ractors 没有这个限制：每个 Ractor 拥有自己的锁，因此一个进程可以并行运行 Ruby。缺失的是一个能够将请求分配给它们的服务器。Ruby 4.0 重新设计了 Ractors（Ractor::Port、可共享的 proc、更少的锁竞争）并使构建它变得值得。为什么 Ractor 服务器必须以这种方式构建，以及哪些 Rust 部分使 Ractors 在此处快速，请参见 doc/why-kino.md。完整的设计说明存储在 doc/architecture.md。 基准测试 在真实的服务器上测量：AWS c7a.2xlarge（8 核 AMD EPYC 9R14，16 GB，Amazon Linux 2023）。这是一个现实的应用服务器大小。这些表格运行一个微小的合成 Rack 应用——纯文本，10 KB 的主体，CPU 密集型的 fib，5 毫秒的等待——故意很小，以便测量服务器而不是应用。它是 Ractor 可共享的，因此 Kino 在 :ractor 模式下运行它（并以 :threaded 进行比较）。一个真实的 Rails 应用是不同的故事：它不可共享 Ractor，因此仅在 Kino 的 :threaded 回退中运行，具有自己的数据——见下面的 Rails。 Ruby 4.0.5 与 YJIT，每个服务器都在其默认设置下：Puma 派生 8 个工人 × 3 个线程，而 Kino 保持在一个进程中（8 个工人；ractor 模式下每个 1 个线程，线程模式下每个 3 个）。数字是 wrk 的 req/s（8 秒窗口，64 个连接，同一主机）。方法论：doc/benchmarks.md。 端点 Kino :ractor + lanes :ractor，工人 32 Kino :threaded Puma（集群） /plaintext 229,534 250,222 182,997 216,994 118,176 /10k 178,083 189,862 151,034 160,400 106,768 /cpu (fib) 77,999¹ 70,885 66,100 13,429 58,006 /io (5 ms) 1,552 1,551 5,888 4,709 4,693 /io_native 1,570 1,571 6,274 4,695 4,691 内存根据应用的不同讲述了两个不同的故事，均通过 PSS（比例集大小；见注释）在持续负载后获得。微小的基准应用（Ractor 可共享，因此 Kino 以 :ractor 或 :threaded 运行）。Kino 在 :ractor 模式下比 Puma 集群轻约 7 倍，在 :threaded 模式下轻约 10 倍——差距依然很大，因为微不足道的应用几乎全是每个工人的私有堆，而写时复制是不可能共享的： 微小应用，Kino Kino（一个进程） Puma 集群（8 个工人） 比例 :ractor（8×1） 148 MB 1,068 MB ~7× :threaded（8×3） 107 MB³ 1,068 MB ~10× 一个真实的 Rails 应用（不可 Ractor 共享——仅 Kino 的 :threaded 回退，见下）。差距约为 4 倍，较小的原因是 Rails 的大型框架在 Puma 的派生中是共享的写时复制： Rails hello-world Kino :threaded Puma 集群（8 个工人） 比例 PSS 92 MB 389 MB ~4× "+ lanes" 是实验性的每工人队列分发器（lanes true）。它发布的最快的纯文本/10k 在此处的任何配置中。详细信息：doc/benchmarks.md。 ¹ 股票设置，无需调整。Ractor 模式在纯 CPU 上比派生集群快 34%（+22% 与 lanes）。线程模式展示了每个单进程 Ruby 服务器面临的 GVL 限制。旧的 CPU 调整配方已被淘汰：其线程的 1 半部现在是默认值，并且其 tokio_threads 的 1 半部在真实硬件上成本 -12%；详见 doc/benchmarks.md。 ² 等待绑定吞吐量是插槽 ÷ 等待，默认列带来了 8 个单线程工人与集群的 24 个线程。