kino 0.4.0-aarch64-linux → 0.6.0-aarch64-linux

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 145273ae455b0822a24794c25d449376b3ba5122f3f275c00b4a959fdafd5183
-  data.tar.gz: c20ae1c2f111a4f6329ea25a4d9c9a0579dfa1b77765ff11e35572f8e32925ca
+  metadata.gz: 47797b5264a1cdd29fcccc4e370cbf8e92fc71b46daaf3831e7bca69c51affea
+  data.tar.gz: 98b264a8a72224f37136e4ec14154e35c1b378844bbe73f35c6110dee59ffde9
 SHA512:
-  metadata.gz: ed2ef3b3d79817b67da62e8271f0a420d4ee0c8976780d97e6e91ba15cddff2e1d34e830d41a8c4c8c63d65fecbeab32bec8d8568777b399c684cdfce00624f0
-  data.tar.gz: 6d695d16998c2bdb9fe44ac709a311990c53c88ae980f136757db926ba370e5a8e379fdd098f675beae4fb126a0ce7d663b36b0a602d6933b1c2b6d3f6cdc02b
+  metadata.gz: 9035020f4e0f2a47666391c05c8a7992176258f186ccc0613fb97de3609bdd98866ab015bd1263246245dc9be0622dfbd93880516bca2d818f5d5bf2ea65739c
+  data.tar.gz: fd323d0e09a40124a91b19f1142f335c41f2e97fc8d33369fc437e5a1cb50fcf91bd82aeb74f85d3c6f577533e1345f1cf323b2004784a6ab21df9d7b5839648

data/CHANGELOG.md

@@ -1,3 +1,59 @@
+## [0.6.0] - 2026-09-01
+
+- HTTP/2 support. Kino now speaks HTTP/2 natively, on by default:
+  browsers negotiate it over TLS (ALPN), h2-preferring balancers and
+  tools get prior-knowledge h2c on plaintext, and everyone else keeps
+  getting HTTP/1.1 on the same port. `http2 false` restores an
+  HTTP/1-only server. What ships with it:
+  - A spec-complete Rack env on h2: `SERVER_PROTOCOL` is `"HTTP/2"`,
+    `HTTP_HOST`/`SERVER_NAME`/`SERVER_PORT` come from the `:authority`
+    pseudo-header, split cookie headers are rejoined, and uploads
+    stream with the same backpressure as HTTP/1.
+  - Uploads at full speed: body reads now drain every arrived chunk in
+    one native call, so h2's 16 KB data frames don't pay a GVL
+    round-trip each—h2 uploads run at HTTP/1 parity, and chunked
+    HTTP/1 uploads got faster too.
+  - `MAX_CONCURRENT_STREAMS` advertised from worker-slot capacity, so
+    an h2-aware balancer sees the server's real admission and a single
+    connection cannot multiply into hundreds of queued requests.
+  - Graceful connection drains: on shutdown, every connection finishes
+    its in-flight request and then closes (`Connection: close` on
+    HTTP/1, GOAWAY on h2) instead of being cut mid-stream at the
+    deadline.
+  - Interned header values: low-cardinality headers (user-agent,
+    accept-*, sec-ch-*) reuse one frozen string instead of allocating
+    per request—the env-side analogue of HPACK's wire dedup, worth a
+    few percent on header-heavy traffic and 6-8 fewer allocations per
+    request, on HTTP/1 too. Cookies and authorization are deliberately
+    never cached.
+
+  Measured on the reference box: native h2 is +79% over HTTP/1.1
+  cleartext and 2× over TLS on the same server, +50% over
+  nginx-terminated h2 in front of Kino, ~3× falcon on fast handlers.
+- Leaner request hot path: up to 2-4% more throughput on fast handlers
+  with `lanes` (measured on Linux), no change elsewhere.
+- All benchmarks re-measured from scratch on a fresh reference box
+  (c7a.2xlarge, Ruby 4.0.6, Puma 8.0.2): the 2026-06 numbers
+  reproduced within 1-3% at matched configurations, memory to the
+  megabyte. The published tables carry the new run, with two additions
+  and one honest downgrade: new studies for sharded I/O (+1-3% on 8
+  cores, best at `io_threads 8`) and HTTP/2 (above), and a narrower
+  ractor /cpu lead over the cluster (+25%, was +34%) because Puma
+  8.0.2 itself got faster. The bench harness gained the sharded-I/O
+  lanes and the Rails memory comparison, and the methodology notes now
+  record two measurement traps: memory is only comparable after the
+  full endpoint battery, and /io only at equal slot counts.
+
+## [0.5.0] - 2026-08-29
+
+- Add opt-in `io_shards true`: accepted HTTP connections can run on
+  current-thread Tokio I/O shards instead of Tokio's shared multi-thread
+  runtime, reducing scheduler contention on very fast handlers. `io_threads`
+  sets the shard count; otherwise Kino uses half the available CPUs
+  ([Patrik Wenger](https://github.com/paddor)).
+- Update Rust dependencies: hyper 1.11.1, rb-sys 0.9.130,
+  rustls-webpki 0.103.15, among others.
+
 ## [0.4.0] - 2026-08-22
 
 - Rack handler: `rails server -u kino` and `rackup -s kino` boot Kino

data/README.md

@@ -11,11 +11,14 @@ on every core in **one small process**. A **Rust** (tokio + hyper)
 front-end owns the network, parallel **Ractors** run your Rack 3 app,
 and a threaded fallback mode runs everything else, Rails included.
 
-* **Fast.** On a real 8-core server, every Kino mode is **1.5-2×**
-  ahead of a Puma fork cluster on I/O-light endpoints. Ractor mode also
-  wins on pure CPU, **30%+**. [Benchmarks](#benchmarks) below.
-* **A fraction of the memory.** About **~7×** on the simplistic bench 
-  Ractor app, and about **4× less memory** than a Puma cluster serving Rails in fallback threaded mode.
+* **Fast.** On a real 8-core server, every Kino mode is **1.5-1.7×**
+  ahead of a Puma fork cluster on I/O-light endpoints—with native
+  **HTTP/2** adding another **+79%** over HTTP/1.1 on the same server.
+  Ractor mode also wins on pure CPU, **+25%**.
+  [Benchmarks](#benchmarks) below.
+* **A fraction of the memory.** About **~8×** on the simplistic bench
+  Ractor app, and about **4× less memory** than a Puma cluster serving
+  Rails in fallback threaded mode.
 * **Parallel without forking.** Ractor mode runs CPU work **more than
   5× faster** than Kino's own GVL-bound threaded mode, in the same
   small process.
@@ -73,32 +76,32 @@ rather than an app. It is Ractor-shareable, so Kino runs it in `:ractor`
 mode (and `:threaded` for comparison). **A real Rails app is a different
 story:** it is *not* Ractor-shareable, so it runs only in Kino's
 `:threaded` fallback, with its own numbers—see [Rails](#rails) below.
-Ruby 4.0.5 with YJIT, every server at its defaults: Puma forks 8 workers ×
-3 threads, Kino stays in one process (8 workers; 1 thread each in ractor
-modes, 3 in threaded). Numbers are req/s by wrk (8-second windows, 64
-connections, same host). Methodology:
-[doc/benchmarks.md](doc/benchmarks.md).
+Ruby 4.0.6 with YJIT (re-measured 2026-09), every server at its
+defaults: Puma forks 8 workers × 3 threads, Kino stays in one process
+(8 workers; 1 thread each in ractor modes, 3 in threaded). Numbers are
+req/s by wrk (8-second windows, 64 connections, same host).
+Methodology: [doc/benchmarks.md](doc/benchmarks.md).
 
 | endpoint    | Kino :ractor | + lanes | :ractor, `workers 32`² | Kino :threaded | Puma (cluster) |
 |-------------|-------------:|--------:|-----------------------:|---------------:|---------------:|
-| /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 |
+| /plaintext  |      222,980 | **244,652** |         115,553 |        213,104 |        142,094 |
+| /10k        |      175,182 | **188,365** |         103,147 |        132,009 |        125,116 |
+| /cpu (fib)  |   **76,695**¹|  71,830 |          54,062 |         13,463 |         61,329 |
+| /io (5 ms)  |        1,548 |   1,556 |       **5,388** |          4,722 |          4,699 |
+| /io_native  |        1,570 |   1,573 |       **6,207** |          4,695 |          4,693 |
 
 Memory tells two different stories depending on the app, both by **PSS**
 (proportional set size; see note) after sustained load.
 
 **The tiny benchmark app** (Ractor-shareable, so Kino runs it in `:ractor`
-or `:threaded`). Kino is **~7× lighter in :ractor mode, ~10× in :threaded**
-than the Puma cluster — the gap stays large because a trivial app is almost
+or `:threaded`). Kino is **~8× lighter in :ractor mode, ~10× in :threaded**
+than the Puma cluster—the gap stays large because a trivial app is almost
 all private per-worker heap, which copy-on-write can't share:
 
 | tiny app, Kino  | Kino (one process) | Puma cluster (8 workers) | ratio |
 |-----------------|-------------------:|-------------------------:|------:|
-| :ractor (8×1)   |         **148 MB** |                 1,068 MB |  ~7×  |
-| :threaded (8×3) |         **107 MB**³|                 1,068 MB | ~10×  |
+| :ractor (8×1)   |         **135 MB** |                 1,072 MB |  ~8×  |
+| :threaded (8×3) |         **107 MB**³|                 1,072 MB | ~10×  |
 
 **A real Rails app** (not Ractor-shareable—Kino's `:threaded` fallback
 only, [below](#rails)). The gap is **~4×**, smaller because Rails' large
@@ -106,24 +109,25 @@ framework *is* shared copy-on-write across Puma's forks:
 
 | Rails hello-world | Kino :threaded | Puma cluster (8 workers) | ratio |
 |-------------------|---------------:|-------------------------:|------:|
-| **PSS**           |      **92 MB** |               **389 MB** |  ~4×  |
+| **PSS**           |      **95 MB** |               **405 MB** |  ~4×  |
 
 "+ lanes" is the experimental per-worker-queue dispatcher (`lanes true`).
 It posts the fastest plaintext/10k of any configuration here. Details:
 [doc/benchmarks.md](doc/benchmarks.md#lane-dispatch-experimental-lanes-true).
 
 ¹ Stock settings, no tuning. Ractor mode beats the fork cluster on pure
-CPU by +34% (+22% with lanes). Threaded mode shows the GVL ceiling that
-every single-process Ruby server hits. The old CPU-tuning recipe is
-retired: its `threads 1` half **is** the default now, and its
-`tokio_threads 1` half costs −12% on real hardware; see
+CPU by +25% (+17% with lanes; Puma 8.0.2 narrowed this from the +34%
+measured against 7.x). Threaded mode shows the GVL ceiling that every
+single-process Ruby server hits. The old CPU-tuning recipe stays
+retired: its `threads 1` half **is** the default, and its
+`tokio_threads 1` half still costs on real hardware; see
 [doc/benchmarks.md](doc/benchmarks.md#cpu-bound-tuning).
 
 ² Wait-bound throughput is slots ÷ wait, and the default columns bring
 8 single-thread workers against the cluster's 24 threads. Kino slots
 are threads, not processes—when your app waits a lot, raise `workers`.
-The `workers 32` column is that tuning: **+25% over the cluster on /io
-(+34% via `Kino.sleep`)** while still ahead of it on pure CPU, all in
+The `workers 32` column is that tuning: **+15% over the cluster on /io
+(+32% via `Kino.sleep`)** while still ahead of it on pure CPU, all in
 one small process. The cost is the CPU-light rows (32 ractors
 oversubscribe 8 cores); pick the topology your app's wait profile
 needs. See
@@ -131,7 +135,7 @@ needs. See
 
 ³ With `MALLOC_ARENA_MAX=2` (the standard Ruby deployment setting;
 Heroku's default). Without it, 24 threads churning 10 KB responses
-through one glibc heap balloon to ~670 MB—an arena-fragmentation
+through one glibc heap balloon to ~647 MB—an arena-fragmentation
 footgun, not a leak, and ractor mode sidesteps it. See
 [doc/benchmarks.md](doc/benchmarks.md#memory-under-load-and-the-glibc-arena-footgun).
 
@@ -141,36 +145,64 @@ doc):
 
 | endpoint   | Kino :ractor (8×3) | Puma + ractor wrapper | Falcon + ractor wrapper |
 |------------|-------------------:|----------------------:|------------------------:|
-| /plaintext |        **193,826** |                19,480 |                  99,776 |
-| /cpu (fib) |         **68,061** |                17,755 |                  48,721 |
-| /io (5 ms) |          **4,530** |                 1,454 |                   1,549 |
+| /plaintext |        **190,206** |                22,055 |                 107,203 |
+| /cpu (fib) |         **68,230** |                16,528 |                  50,101 |
+| /io (5 ms) |          **4,477** |                 1,482 |                   1,545 |
+
+(The Kino column here runs 8×3—the same 24 slots the wrappers get—so
+the /io row is comparable; the main table's ractor column runs the 8×1
+default.)
+
+### HTTP/2 head-to-head
+
+Kino speaks HTTP/2 natively, so it skips the usual nginx-termination
+hop. Same box as the tables above; all over TLS, h2load, 64 in-flight,
+same app:
+
+| /plaintext                    |       req/s | /upload (64 KB) |
+|-------------------------------|------------:|----------------:|
+| Kino native h2                | **164,044** |      **19,226** |
+| Kino HTTP/1.1 (same boot)     |      80,789 |          17,210 |
+| nginx h2 → Kino HTTP/1.1      |     109,219 |          1,217¹ |
+| Falcon (native h2)            |      55,637 |          18,838 |
+
+Native h2 **doubles** HTTP/1.1 throughput on the same TLS server
+(+79% on cleartext h2c; fewer, larger socket operations, and HPACK
+spares re-sending cookies) and is **+50% over fronting the same Kino
+with nginx**—the proxy hop is pure cost. Uploads, h2's classic weak
+spot, run at HTTP/1 parity. Full matrix, cleartext h2c lanes, and
+methodology: [doc/benchmarks.md](doc/benchmarks.md#http2); reproduce
+with `bench/h2.sh`.
+
+¹ nginx default-config h2 request-body flow control; see the doc.
 
 ### Rails
 
 Rails is not Ractor-shareable today, so Kino serves it in `:threaded`
-fallback — one GVL-bound process. On the same box (`examples/rails-hello`,
+fallback—one GVL-bound process. On the same box (`examples/rails-hello`,
 edge Rails, production, 8×5):
 
 | Rails hello-world            |  req/s | memory (PSS) |
 |------------------------------|-------:|-------------:|
-| Kino :threaded (one process) |  2,637 |    **92 MB** |
-| Puma cluster (8 workers)     | 12,138 |       389 MB |
+| Kino :threaded (one process) |  2,731 |    **95 MB** |
+| Puma cluster (8 workers)     | 15,422 |       405 MB |
 
 The honest trade-off: Puma's fork cluster uses all 8 cores, so it serves
-~4.6× the throughput — at ~4× the memory. Ractor-mode Rails would close
+~5.6× the throughput—at ~4× the memory. Ractor-mode Rails would close
 the throughput gap at one-process memory cost; the upstream blockers are
 tracked in [doc/rails-on-ractors.md](doc/rails-on-ractors.md).
 
-In short: on the tiny synthetic app, ractor mode beats fork-level CPU parallelism (**5.8×** Kino's
-own GVL-bound threaded mode, +34% over the cluster) in one process, at
-about 1/7th of the cluster's memory by PSS (~4× on a real Rails app).
-Every Kino mode is 1.5-2.1× ahead of the cluster on I/O-light endpoints. The macOS numbers
+In short: on the tiny synthetic app, ractor mode beats fork-level CPU parallelism (**5.7×** Kino's
+own GVL-bound threaded mode, +25% over the cluster) in one process, at
+about 1/8th of the cluster's memory by PSS (~4× on a real Rails app).
+Every Kino mode is 1.5-1.7× ahead of the cluster on I/O-light endpoints,
+and native HTTP/2 adds +79% over HTTP/1.1 on top. The macOS numbers
 (secondary; everything there hits the loopback ceiling) and the
 YJIT × Ractors gotcha are in [doc/benchmarks.md](doc/benchmarks.md).
 
 Reproduce: `bench/run.sh [seconds] [concurrency]` for the main table,
 `bench/studies.sh` for the follow-ups (CPU recipe, topology, scaling,
-logging, memory).
+sharded I/O, logging, memory), `bench/h2.sh` for the HTTP/2 matrix.
 
 ## Install
 
@@ -239,6 +271,7 @@ server = Kino::Server.new(app,
   control_bind: "127.0.0.1:9293",   # monitoring: /stats /metrics /ready /live; port 0 reads back via server.control_port
   control_token: ENV["KINO_CONTROL_TOKEN"],  # optional Bearer auth for /stats + /metrics
   tls: { cert: "cert.pem", key: "key.pem" },  # file paths or inline PEM
+  http2: true,                # ALPN h2 on TLS + plaintext h2c; false = HTTP/1 only
 )
 server.start
 server.shutdown               # graceful: drain → deadline → abort stragglers
@@ -259,6 +292,45 @@ server.shutdown               # graceful: drain → deadline → abort straggler
   always counts as "shareable" (classes are), even if calling it touches
   unshareable state. Force `:threaded` for those.
 
+### Sharded I/O
+
+`io_shards true` (off by default) moves HTTP I/O from Tokio's shared
+multi-thread runtime onto current-thread shards: one thread accepts and
+hands each connection to the least-loaded shard, which then owns it for
+its lifetime—no work-stealing, no cross-thread wakeups on the hot path.
+On the 8-core reference box fast handlers gain +1-3% (best with
+`io_threads 8`); the win grows with scheduler contention, so measure on
+your own core count. Ruby-bound endpoints are unchanged. Orthogonal to
+`mode`: it reshapes the Rust side only.
+
+```ruby
+# kino.rb
+io_shards true
+io_threads 8  # optional; default: half the available CPUs
+```
+
+### HTTP/2
+
+On by default, on both transports, with nothing to configure:
+
+- **TLS binds** advertise `h2` via ALPN, so browsers and h2-capable
+  clients negotiate HTTP/2 and everything else stays on HTTP/1.1.
+- **Plaintext binds** serve prior-knowledge h2c: a client that opens
+  with the HTTP/2 preface (an h2-preferring load balancer, a gRPC-style
+  backend hop, `curl --http2-prior-knowledge`) gets HTTP/2; ordinary
+  clients are HTTP/1.1 exactly as before. Browsers never do h2 on
+  plaintext, so a certificate-less kino behaves identically for them.
+
+The Rack side is spec-complete on h2: `SERVER_PROTOCOL` is `"HTTP/2"`,
+`HTTP_HOST`/`SERVER_NAME`/`SERVER_PORT` come from the `:authority`
+pseudo-header (h2 requests carry no Host header), split cookie headers
+are rejoined with `"; "`, and streamed uploads flow through the same
+backpressured body channel as HTTP/1. Streams multiplex into the same
+worker slots as keep-alive requests—`workers × threads` bounds
+concurrency either way. (`rack.hijack` stays out on h2 as it is on h1;
+the protocol has no 101 upgrade to hijack anyway.) `http2 false` pins
+the server to HTTP/1 and drops `h2` from ALPN.
+
 ## Config file and CLI
 
 Settings can live in a Puma-style Ruby DSL file: `kino.rb` in the
@@ -424,8 +496,8 @@ not `queue_time`.
 
 ## Logging
 
-With one log line per request, `Kino::Logger` sustained **2.4× the
-throughput of a shared `::Logger`** (149k vs 63k req/s on the benchmark
+With one log line per request, `Kino::Logger` sustained **1.7× the
+throughput of a shared `::Logger`** (155k vs 90k req/s on the benchmark
 box). There are two native pieces. Both write through a lock-free
 channel to a Rust flusher thread, so request threads never take a log
 mutex and never make a write syscall:

data/doc/architecture.md

@@ -11,10 +11,13 @@ tokio (Rust threads)                          Ruby
 └──────────────────────────┘                     └────────────────────────────┘
 ```
 
-All network I/O lives in Rust on a tokio multi-threaded runtime; hyper
-parses HTTP/1.1 and handles keep-alive; rustls terminates TLS. Ruby never
-touches a socket. Each request becomes a Rust-side `RequestCtx` pushed to a
-bounded flume MPMC queue; Ruby workers pull from it.
+All network I/O lives in Rust on tokio runtimes; hyper parses HTTP/1.1 and
+handles keep-alive; rustls terminates TLS. The default is Tokio's
+multi-thread runtime. With `io_shards true`, one current-thread runtime
+accepts connections and assigns them to current-thread I/O shards, where
+each connection stays for its lifetime. Ruby never touches a socket. Each
+request becomes a Rust-side `RequestCtx` pushed to a bounded flume MPMC
+queue; Ruby workers pull from it.
 
 ## Topology
 
@@ -106,13 +109,63 @@ plain decrement after an `.await` would never run).
 
 ## Graceful shutdown
 
-`stop_accepting` → drain until queue + in-flight reach zero or the
-deadline passes → `close_queue` (idle workers see Disconnected and exit) →
+`stop_accepting` → every live connection switches to graceful shutdown
+(finish the in-flight request, answer with `Connection: close` on
+HTTP/1 or GOAWAY on h2, take nothing new—so drains converge instead
+of chasing chatty keep-alive clients) → drain until queue + in-flight
+reach zero or the deadline passes → `close_queue` (idle workers see
+Disconnected and exit) →
 join workers → past deadline: abort remaining clients (a 500, or a
 connection abort mid-stream), interrupt blocked workers, reap
 stragglers → tear down the tokio runtime. Idempotent;
 a second INT/TERM force-exits.
 
+## HTTP/2
+
+One connection builder serves every protocol: hyper-util's auto builder
+picks h2 by ALPN on TLS connections, by the 24-byte preface sniff on
+plaintext (prior-knowledge h2c), and HTTP/1.x otherwise; `http2 false`
+pins the HTTP/1 codec and skips the sniff entirely. Streams multiplex
+into the same bounded queue as keep-alive requests, so h2 concurrency
+is bounded by workers × threads exactly as h1's is, and the bounded
+body channels give per-stream backpressure for free: while the
+forwarder blocks, hyper withholds WINDOW_UPDATE and the client stalls.
+
+The env bridge fills SERVER_NAME/SERVER_PORT/HTTP_HOST from the request
+URI's `:authority` (h2 requests carry no Host header), through the same
+host LRU the Host-header path uses, keyed by the authority bytes;
+SERVER_PROTOCOL is the interned "HTTP/2". h2 trailer frames are dropped
+(Rack has no trailer surface), and the h2 codec itself rejects
+connection-ish headers before they can reach the env.
+
+The upload path needed one h2-shaped fix: `read_body` drains every
+already-queued chunk in a single native call (one GVL round-trip and
+one Ruby string per 64 KB read), because a body arriving as 16 KB DATA
+frames otherwise paid one crossing per frame—that alone took h2
+uploads from half of h1's throughput to parity. A knob sweep over
+hyper's h2 codec (frame size, adaptive windows, window sizes) moved
+nothing after that, so hyper's defaults stay.
+
+SETTINGS_MAX_CONCURRENT_STREAMS is derived from slot capacity
+(workers × threads, clamped to [8, 1024]) rather than hyper's flat 200:
+a smart balancer sees the server's true admission, and a hostile client
+cannot multiply one connection into hundreds of queued requests—the
+h2 analogue of h1's one-request-per-connection shape. The codec's own
+abuse bounds ship as hyper/h2 defaults and were reviewed: 16 KB header
+lists, 20 pending remote resets then GOAWAY (rapid reset), per-second
+reset-churn and empty-frame budgets.
+
+Low-cardinality header values (UA, accept-*, sec-ch-*, sec-fetch-*)
+are interned in an LRU of frozen strings—the env-side analogue of
+HPACK's wire dedup, and the practical form of it: hyper does not expose
+HPACK table indices, so the cache keys on value bytes and works for
+HTTP/1 too. Cookie and authorization are deliberately excluded
+(per-user cardinality, secret lifetime).
+
+Deferred until benchmarks justify it: slot-aware flow-control window
+grants (a memory/abuse lever, not a throughput one—the knob sweep
+showed windows don't gate upload throughput).
+
 ## Timer waits: `Kino.sleep`
 
 MRI's `sleep` parks the thread on the VM timer, whose wakeups inside
@@ -125,7 +178,8 @@ at the interrupt tick so `Thread#kill` and shutdown stay responsive.
 
 - **tokio + hyper**: the bottleneck is the Ruby dispatch boundary, not raw
   I/O throughput; what matters is HTTP correctness, keep-alive, TLS, and
-  h2-later—hyper's territory. Cross-platform out of the box.
+  h2 (since shipped, via hyper-util's protocol-auto builder)—hyper's
+  territory. Cross-platform out of the box.
 - **monoio**: thread-per-core io_uring looks great in echo-server
   benchmarks, but hyper only works through its poll-io compat layer
   (forfeiting io_uring on the hot path), and the share-nothing advantage

data/doc/benchmarks.md

@@ -17,9 +17,21 @@ the deployment most apps run today.
   9R14 (Genoa), 16 GB RAM, Amazon Linux 2023, kernel 6.18. A realistic
   app-server size, deliberately: nobody provisions a 32-core box per
   app process.
-- Toolchain built on the box via mise: Ruby 4.0.5 (**YJIT enabled**,
-  `RUBY_YJIT_ENABLE=1` for every server), Rust 1.96, Kino compiled in
+- Toolchain built on the box via mise: Ruby 4.0.6 (**YJIT enabled**,
+  `RUBY_YJIT_ENABLE=1` for every server), Rust stable, Kino compiled in
   the release profile.
+- **2026-09 full re-measurement** (a fresh c7a.2xlarge): every number in
+  this document and the README was re-run on Ruby 4.0.6 / kernel 6.18 /
+  Puma 8.0.2, adding the sharded-I/O and HTTP/2 studies. Kino's numbers
+  reproduced within 1-3% across the board—including the /io slot
+  ceiling and the arena balloon, both intact. The one real shift: Puma
+  8.0.2 is faster than 7.x (142k plaintext, 61k /cpu), narrowing
+  ractor mode's /cpu lead to +25% (was +34%). Reversed-boot-order
+  re-runs reproduced within ~1%. A methodology trap worth recording:
+  a 5-second single-endpoint warmup understates memory badly (81 MB
+  where the full battery shows 137 MB) and hides the arena balloon
+  entirely—memory is only comparable after the full endpoint battery,
+  and /io numbers are only comparable at equal slot counts.
 - Load generator: wrk 4.2 on the same host, 8-second windows, 64
   connections (`bench/run.sh 8 64`). Same-host load generation costs
   both sides CPU equally; we verified the generator was not the
@@ -249,14 +261,17 @@ visible.
 
 | config | RSS | PSS |
 |---|---:|---:|
-| Kino :ractor 8×1 (default) | 151 | **148** |
-| Kino lanes 8×1 | 137 | **135** |
-| Kino :ractor 8×3 | 171 | **169** |
+| Kino :ractor 8×1 (default) | 137 | **135** |
+| Kino lanes 8×1 | 128 | **126** |
+| Kino :ractor 8×3 | 170 | **168** |
 | Kino :threaded 8×3 (`MALLOC_ARENA_MAX=2`) | 109 | **107** |
-| Kino :threaded 8×3 (no arena cap) | 668 | **666**¹ |
-| Puma cluster 8×3 | 1,213 | **1,068** |
+| Kino :threaded 8×3 (no arena cap) | 672 | **670**¹ |
+| Puma cluster 8×3 | 1,216 | **1,072** |
 
-The tiny app is ~7× lighter than the cluster in ractor mode, ~10× in
+(2026-09 re-measure; the 2026-06 numbers reproduced within a few MB on
+every row—the arena-capped threaded row to the megabyte.)
+
+The tiny app is ~8× lighter than the cluster in ractor mode, ~10× in
 arena-capped threaded mode. RSS ≈ PSS for every Kino row (one process,
 nothing to share) and within ~12% for Puma here: a trivial app has almost
 no shared state, so Puma's footprint is ~1,051 MB of *private* per-worker
@@ -280,18 +295,19 @@ Here copy-on-write **does** matter, which is exactly why PSS is mandatory:
 
 | config | RSS | PSS |
 |---|---:|---:|
-| Kino :threaded (one process) |  97 |  **92** |
-| Puma cluster 8×3 (preload) | 794 | **389** |
+| Kino :threaded (one process) |  97 |  **95** |
+| Puma cluster 8×5 (preload) | 813 | **405** |
+| Puma cluster 8×5 (no preload) | 824 | **646** |
 
 Puma serves the same Rails framework from 8 forks that share it
-copy-on-write; RSS counts that shared framework once per worker (794 MB),
-PSS counts it once (389 MB). The fair ratio is **~4×**, not the ~8× a
+copy-on-write; RSS counts that shared framework once per worker (813 MB),
+PSS counts it once (405 MB). The fair ratio is **~4×**, not the ~8× a
 naive RSS sum reports—this is the correction that prompted the whole
-re-measure. Preload barely helps (389 vs 400 MB without): Ruby's GC
-dirties most heap pages, breaking copy-on-write, so even a preloaded
-cluster keeps a large private heap per worker. That is why "CoW should
-make a fork cluster nearly free" is only half true—it shares the code,
-not the live object heap.
+re-measure. The 2026-09 run also split out preload: it now saves a
+third (405 vs 646 MB PSS)—worth turning on—but even preloaded, Ruby's
+GC dirties heap pages and breaks copy-on-write, so each worker keeps a
+large private heap. That is why "CoW should make a fork cluster nearly
+free" is only half true—it shares the code, not the live object heap.
 
 ## Run-to-run variance (a.k.a. "is this a regression?")
 
@@ -376,27 +392,46 @@ crash semantics, stealing fairness, and drain behavior have spec
 coverage but not production mileage. (On loopback-bound macOS, lanes
 lose a few percent instead; see the secondary table below.)
 
+## Sharded I/O (`io_shards true`)
+
+`bench/studies.sh 8 64 shards`, ractor 8×3, 2026-09 reference box:
+
+| case (/plaintext) | req/s |
+|---|---:|
+| shared tokio runtime (baseline) | 193,461 |
+| io_shards, default shard count | 195,436 |
+| io_shards, `io_threads 2` | 170,509 |
+| io_shards, `io_threads 4` | 196,298 |
+| io_shards, `io_threads 8` | 199,657 |
+
+On 8 cores the shards buy +1-3%, best at `io_threads 8` (the
+half-the-cores default is close behind; 2 shards choke on accept
+handoff). The design removes work-stealing and cross-thread wakeups,
+so the win scales with scheduler contention—expect more on boxes with
+more cores and connections, and measure on your own core count.
+
 ## Logging costs
 
 Measured at full plaintext saturation (one log line per request—rates
 that no real deployment logs at; treat these as worst-case ceilings, not
 typical costs):
 
-| case (8×3, same session) | req/s |
+| case (8×3, same session, 2026-09) | req/s |
 |---|---:|
-| threaded, no logging | 219,168 |
-| threaded, `log_requests true` (native access log) | 193,998 (−11%) |
-| ractor, access log off / on | 197,596 / 181,050 (−8%) |
-| app logs 1 line/req via shared `::Logger` (file) | **62,961** |
-| app logs 1 line/req via `Kino::Logger` (file) | **149,519 (2.4×)** |
+| threaded, no logging | 213,166 |
+| threaded, `log_requests true` (native access log) | 173,501 (−19%) |
+| ractor, access log off / on | 191,152 / 163,777 (−14%) |
+| app logs 1 line/req via shared `::Logger` (file) | **90,175** |
+| app logs 1 line/req via `Kino::Logger` (file) | **154,653 (1.7×)** |
 
 The shared-`::Logger` cost is the mutex: 24 worker threads serialize
 through one lock plus a write syscall per line. `Kino::Logger` hands the
 formatted line to a lock-free channel and returns—the remaining cost vs
 not logging at all is Ruby-side formatting, which no device can remove.
-(In the Docker environment the same comparison showed 8.5×—overlay-fs
-write latency punished the synchronous logger far harder than this box's
-NVMe does. The ranking is environment-independent; the multiple is not.)
+(The multiple moves with the environment: 2.4× on the 2026-06 box,
+1.7× on the 2026-09 one, 8.5× under Docker, where overlay-fs write
+latency punished the synchronous logger hardest. The ranking is
+environment-independent; the multiple is not.)
 
 One trade-off worth knowing: the sink **never blocks** request threads,
 so at absurd rates against a slow disk it drops lines once its 8192-line
@@ -408,6 +443,65 @@ Puma comparison note: request logging is opt-in there too (`--quiet` is
 the default, `-v/--log-requests` enables it)—Kino's default-off
 `log_requests` matches the ecosystem's standard behavior.
 
+## HTTP/2
+
+`bench/h2.sh`, Linux only (on macOS run it under Docker; the 2026-09
+numbers below are from the c7a.2xlarge reference box). Every lane is
+measured with h2load so the generator is identical everywhere: h2
+lanes run 8 connections × 8 concurrent streams, h1 lanes 64
+connections—the same total in-flight. Servers without native h2 get
+the standard pattern instead: nginx terminating h2 and proxying
+HTTP/1.1 upstream over keep-alive. One labeled run (kino ractor 8×3,
+falcon `--count 8`, puma `-w 8 -t 3:3`, 5 s/lane); re-run the whole
+script for close calls, per the variance section.
+
+| target (h2 unless noted) | /plaintext | /10k | /big-cookie | /upload (64 KB) |
+|---|---:|---:|---:|---:|
+| kino h2c | 207,461 | 150,105 | 195,093 | 26,304 |
+| kino h1 cleartext (same boot) | 116,082 | 97,634 | 110,614 | 24,338 |
+| kino h2 TLS | 164,044 | 116,617 | 154,301 | 19,226 |
+| kino h1 TLS (same boot) | 80,789 | 69,942 | 76,654 | 17,210 |
+| falcon TLS (native h2) | 55,637 | 37,541 | 49,151 | 18,838 |
+| nginx h2 → puma h1 | 81,234 | 57,891 | 51,332 | 1,247 |
+| nginx h2 → kino h1 | 109,219 | 66,634 | 54,996 | 1,217 |
+
+What the numbers say:
+
+- **Native h2 beats h1 on the same server by +79% cleartext and +103%
+  over TLS** on /plaintext: the same 64 in-flight requests ride 8
+  connections instead of 64, so frames batch into fewer, larger
+  syscalls—and TLS amplifies it, since h1's 64 connections each pay
+  crypto per record. The `/big-cookie` lane (a ~2 KB cookie per
+  request) shows HPACK on top: the cookie crosses the wire once per
+  connection, not once per request, and holds 94% of bare-plaintext
+  throughput where h1 loses 5%.
+- **Native h2 beats proxied h2 by +50%** with the *same backend*: the
+  nginx→kino-h1 lane is the proxy-cost control, and the extra hop,
+  re-parse, and re-serialize cost ~55k req/s on /plaintext.
+- **Uploads run at h1 parity**—but only after a fix this lane
+  caught: h2 delivers bodies as 16 KB DATA frames, and `read_body`
+  originally crossed the GVL once per chunk, halving upload
+  throughput. It now drains every queued chunk per crossing
+  (doc/architecture.md), and a knob sweep over hyper's h2 codec
+  (frame size, adaptive/bigger windows) moved nothing afterwards.
+  nginx's h2 upload collapse (~1.5k) is its default-config
+  request-body flow control; tune `http2_body_preread_size`/buffering
+  before drawing conclusions there.
+- falcon lands at roughly a third of kino-h2-TLS on fast handlers and
+  slightly behind on uploads. Single-run caveat: the nginx lanes
+  showed ±20% swings between runs in the Docker environment; on the
+  reference box the kino-vs-kino and kino-vs-proxy ratios reproduced
+  across runs, the nginx lanes remain the noisiest.
+- **Header-value interning** (user-agent, accept-*, sec-ch-*: one
+  frozen string instead of a fresh allocation per request) was
+  measured with a realistic 11-header browser set on /plaintext,
+  using the within-boot header cost (bare vs with-headers) as the
+  drift-resistant metric: over h2 that cost fell from ~16% to ~12-13%
+  (~+3-5% throughput on the headers lane); h1's smaller header cost
+  stayed within noise. The effect the tiny app understates: 6-8 fewer
+  string allocations per request is GC pressure a real app feels more
+  than this one does.
+
 ## Hot-path notes
 
 For the curious, the dispatch-path work behind the numbers: a try-pop

data/lib/kino/configuration.rb

@@ -26,8 +26,11 @@ module Kino
       after_request_complete: nil,
       on_worker_exit: nil,
       shutdown_timeout: 30,
+      io_shards: false,
+      io_threads: nil,
       tokio_threads: nil,
       tls: nil,
+      http2: true,
       environment: nil,
       pidfile: nil,
       control_bind: nil,
@@ -148,6 +151,8 @@ module Kino
     #   queue_depth 2048
     #   queue_timeout 0.5
     #   shutdown_timeout 15
+    #   io_shards true
+    #   io_threads 6
     #   tokio_threads 4
     #   tls cert: "cert.pem", key: "key.pem"
     #
@@ -229,12 +234,23 @@ module Kino
       # Graceful-shutdown drain deadline in seconds.
       def shutdown_timeout(seconds) = @config.set(:shutdown_timeout, seconds)
 
+      # Run native HTTP I/O on current-thread shards instead of Tokio's shared pool.
+      def io_shards(enabled = true) = @config.set(:io_shards, !!enabled)
+
+      # Native HTTP I/O shard count; default with io_shards: half available CPUs.
+      def io_threads(count) = @config.set(:io_threads, Integer(count))
+
       # Threads for the tokio (Rust I/O) runtime; default: one per core.
       def tokio_threads(count) = @config.set(:tokio_threads, Integer(count))
 
       # TLS termination; file paths or inline PEM strings.
       def tls(cert:, key:) = @config.set(:tls, {cert: cert, key: key})
 
+      # HTTP/2: negotiated via ALPN on TLS binds, served to
+      # prior-knowledge clients on plaintext. On by default; set false
+      # to serve HTTP/1 only.
+      def http2(enabled = true) = @config.set(:http2, !!enabled)
+
       # Sets RACK_ENV (unless already set) before the CLI loads the app.
       def environment(env) = @config.set(:environment, env.to_s)
 

data/lib/kino/server.rb

@@ -98,11 +98,18 @@ module Kino
       @lanes = !!settings[:lanes]
       @log_requests = !!settings[:log_requests]
       @shutdown_timeout = settings[:shutdown_timeout]
+      @io_shards = !!settings[:io_shards]
+      @io_threads = Integer(settings[:io_threads]) unless settings[:io_threads].nil?
+      if @io_threads && @io_threads < 1
+        raise ArgumentError, "io_threads must be >= 1"
+      end
+      Log.warn("io_threads has no effect unless io_shards is true") if @io_threads && !@io_shards
       @tokio_threads = settings[:tokio_threads]
       @tls = validate_tls(settings[:tls])
       if @tls && unix?
         raise ArgumentError, "TLS is not supported on a unix socket bind; terminate TLS at the proxy in front"
       end
+      @http2 = settings.fetch(:http2, true) ? true : false
       @pidfile = settings[:pidfile]
       @control_bind = settings[:control_bind]&.to_s
       @control_token = settings[:control_token]&.to_s
@@ -145,8 +152,11 @@ module Kino
           request_timeout_ms: @request_timeout_ms,
           max_connections: @max_connections,
           max_body_size: @max_body_size,
+          io_shards: @io_shards,
+          io_threads: @io_threads,
           tokio_threads: @tokio_threads,
           tls_cert: @tls&.fetch(:cert), tls_key: @tls&.fetch(:key),
+          http2: @http2,
           lanes: @lanes, log_requests: @log_requests,
           mode: @mode.to_s, workers: @workers, threads: @threads, batch: @batch,
           control_bind: @control_bind, control_token: @control_token

data/lib/kino/templates/kino.rb.tt

@@ -20,6 +20,11 @@
 # PEM strings also work).
 # tls cert: "config/certs/server.pem", key: "config/certs/server.key"
 
+# HTTP/2 is on by default: negotiated via ALPN on TLS binds, and served
+# to prior-knowledge (h2c) clients on plaintext. Everything else keeps
+# getting HTTP/1.1. Set false to serve HTTP/1 only.
+# http2 false
+
 ## Topology
 
 # How many workers to run. Each worker handles requests independently;
@@ -125,8 +130,14 @@
 
 ## Runtime
 
-# Threads for the Rust I/O engine. The default suits most apps; for
-# heavily CPU-bound apps, try 1 to leave more cores for Ruby.
+# Run native HTTP I/O on current-thread shards instead of Tokio's shared
+# worker pool, reducing scheduler contention on very fast handlers.
+# io_shards true
+
+# I/O shard count. Default with io_shards: half available CPUs.
+# io_threads 6
+
+# Threads for the Tokio multi-thread runtime. Default: one per available CPU.
 # tokio_threads 4
 
 ## Control plane

data/lib/kino/version.rb

@@ -2,5 +2,5 @@
 
 module Kino
   # The gem version (single source of truth; ext/kino/Cargo.toml syncs).
-  VERSION = "0.4.0"
+  VERSION = "0.6.0"
 end

data/lib/kino/worker.rb

@@ -20,12 +20,16 @@ module Kino
 
     def run(server_id, worker_id, app, batch_size = 1, hooks = nil)
       fire_after_worker_boot(hooks, worker_id)
+      # One resolution of (server, worker) into a native handle; every take
+      # after this skips the registry lookup. nil = server already gone.
+      worker = Native.worker(server_id, worker_id)
+      return unless worker
       if batch_size <= 1
-        env = Native.take_one(server_id, worker_id)
-        env = handle_one(env, server_id, worker_id, app, hooks) while env
+        env = worker.take_one
+        env = handle_one(env, worker, app, hooks) while env
       else
-        batch = Native.take_batch(server_id, worker_id, batch_size)
-        batch = process(batch, server_id, worker_id, app, batch_size, hooks) while batch
+        batch = worker.take_batch(batch_size)
+        batch = process(batch, worker, app, batch_size, hooks) while batch
       end
     end
 
@@ -35,22 +39,21 @@ module Kino
     NOT_FUSED = Object.new.freeze
 
     # Handle one request; returns the next env (fused take) or nil.
-    def handle_one(env, server_id, worker_id, app, hooks)
+    def handle_one(env, worker, app, hooks)
       result = serve(env, app, hooks) do |request, status, headers, chunks|
-        request.respond_and_take_one(server_id, worker_id, status, headers, chunks)
+        request.respond_and_take_one(worker, status, headers, chunks)
       end
-      result.equal?(NOT_FUSED) ? Native.take_one(server_id, worker_id) : result
+      result.equal?(NOT_FUSED) ? worker.take_one : result
     end
 
     # Handle every env in the batch; returns the next batch (the last
     # simple response rides the fused respond_and_take) or nil on shutdown.
-    def process(batch, server_id, worker_id, app, batch_size, hooks)
+    def process(batch, worker, app, batch_size, hooks)
       last = batch.size - 1
       batch.each_with_index do |env, index|
         result = serve(env, app, hooks) do |request, status, headers, chunks|
           if index == last
-            request.respond_and_take(server_id, worker_id, batch_size,
-              status, headers, chunks)
+            request.respond_and_take(worker, batch_size, status, headers, chunks)
           else
             request.send_simple(status, headers, chunks)
             NOT_FUSED
@@ -58,7 +61,7 @@ module Kino
         end
         return result if index == last && !result.equal?(NOT_FUSED)
       end
-      Native.take_batch(server_id, worker_id, batch_size)
+      worker.take_batch(batch_size)
     end
 
     # Run one request through the app. Complete bodies are yielded so the

data/sig/kino.rbs

@@ -126,8 +126,11 @@ module Kino
       def after_request_complete: (?^(Hash[String, untyped], Integer) -> void handler) ?{ (Hash[String, untyped], Integer) -> void } -> untyped
       def on_worker_exit: (?^(Integer, Exception?) -> void handler) ?{ (Integer, Exception?) -> void } -> untyped
       def shutdown_timeout: (Numeric seconds) -> untyped
+      def io_shards: (?boolish enabled) -> untyped
+      def io_threads: (int? count) -> untyped
       def tokio_threads: (int count) -> untyped
       def tls: (cert: String, key: String) -> untyped
+      def http2: (?boolish enabled) -> untyped
       def environment: (String | Symbol env) -> untyped
       def pidfile: (String path) -> untyped
       def control_bind: (String addr) -> String

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: kino
 version: !ruby/object:Gem::Version
-  version: 0.4.0
+  version: 0.6.0
 platform: aarch64-linux
 authors:
 - Yaroslav Markin
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2026-08-22 00:00:00.000000000 Z
+date: 2026-09-01 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: logger
@@ -38,6 +38,20 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '3.1'
+- !ruby/object:Gem::Dependency
+  name: httpx
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.3'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: '1.3'
 - !ruby/object:Gem::Dependency
   name: rackup
   requirement: !ruby/object:Gem::Requirement