raptor 0.15.1 → 0.16.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: d2048ec0cf41ced4050d0b53949d96c71cfab42e921c05bd4db16e03099c441d
-  data.tar.gz: 5c0eacc1154ea6e8ed72ccd29dee4770347dbf773f8087895b9de2be1b9c699b
+  metadata.gz: 02fe742ea31e44d742de9f0ed5b94cc53901d39e25b054fe0bd4affd14e169c1
+  data.tar.gz: 4279672bfd532f9bcadfb5ce81d85b8ba4921b8072e302bfc33bf74ce4609224
 SHA512:
-  metadata.gz: 3844c94223e342793ce75e329f4c86dab40ce353a6d7041e06d4c01f26569102df7a26bba0324f829558363d254e7521862fbe2f846b0de4c1af55f2a1f59062
-  data.tar.gz: d595b6670b26bc19a8805c48d17bd44ebc5a1e075a8b8cc44db811a0b5f79052862ad160514d109758271010161c5fd9b516e71ef9a2637a7fff25e64aafac2b
+  metadata.gz: 283c078528cfd9cdfdfb795e4587a60607fa382d09efe1194330d5a9a6c7f319af94bc63a2da62396c7aba8484a0041260fcd70b0d82a5c324c7fd6b9221abc5
+  data.tar.gz: 9ee16f87805c340d17da270a81131f191b09500cbd622e3bd06bd32acff3f2ec215004e110187de1d01f6815fdcdfdf962c50c521398ce45e469358d3c155dd8

data/CHANGELOG.md

@@ -1,5 +1,11 @@
 ## [Unreleased]
 
+## [0.16.0] - 2026-08-22
+
+- Parse HTTP/2 requests in a dedicated ractor pool
+- Parse the first HTTP/2 frame batch inline on accept
+- Nest the `ractors` config under `http1` and `http2`, defaulting both to `round(cores / workers)` clamped to 1..3 for HTTP/1.1 and 1..2 for HTTP/2
+
 ## [0.15.1] - 2026-08-16
 
 - Regenerate the server RBS signatures

data/README.md

@@ -35,24 +35,31 @@ run proc { |_env| [200, { "content-type" => "text/plain" }, ["Hello, World!"]] }
 ```
 
 ```
-> bundle exec raptor -w 4 -t 3 hello_world.ru
-[Raptor 33061|Main|Main] Cluster initializing:
-[Raptor 33061|Main|Main] ├─ Version: 0.15.1
-[Raptor 33061|Main|Main] ├─ Ruby Version: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [arm64-darwin23]
-[Raptor 33061|Main|Main] ├─ Environment: development
-[Raptor 33061|Main|Main] ├─ Master PID: 33061
-[Raptor 33061|Main|Main] │  └─ 4 worker processes
-[Raptor 33061|Main|Main] │     ├─ 1 server thread
-[Raptor 33061|Main|Main] │     ├─ 1 reactor thread
-[Raptor 33061|Main|Main] │     ├─ 1 pipeline ractor
-[Raptor 33061|Main|Main] │     ├─ 1 pipeline collector thread
-[Raptor 33061|Main|Main] │     ├─ 3 worker threads
-[Raptor 33061|Main|Main] │     └─ 1 stats thread
-[Raptor 33061|Main|Main] └─ Listening on 0.0.0.0:9292
-[Raptor 33064|Main|Main] Worker 0 booted
-[Raptor 33065|Main|Main] Worker 1 booted
-[Raptor 33066|Main|Main] Worker 2 booted
-[Raptor 33067|Main|Main] Worker 3 booted
+> bundle exec raptor -w 10 -t 3 hello_world.ru
+[Raptor 83654|Main|Main] Cluster initializing:
+[Raptor 83654|Main|Main] ├─ Version: 0.16.0
+[Raptor 83654|Main|Main] ├─ Ruby Version: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [arm64-darwin23]
+[Raptor 83654|Main|Main] ├─ Environment: development
+[Raptor 83654|Main|Main] ├─ Master PID: 83654
+[Raptor 83654|Main|Main] │  └─ 10 worker processes
+[Raptor 83654|Main|Main] │     ├─ 1 server thread
+[Raptor 83654|Main|Main] │     ├─ 1 reactor thread
+[Raptor 83654|Main|Main] │     ├─ 1 HTTP/1.1 pipeline ractor
+[Raptor 83654|Main|Main] │     ├─ 1 HTTP/2 pipeline ractor
+[Raptor 83654|Main|Main] │     ├─ 2 pipeline collector threads
+[Raptor 83654|Main|Main] │     ├─ 3 worker threads
+[Raptor 83654|Main|Main] │     └─ 1 stats thread
+[Raptor 83654|Main|Main] └─ Listening on 0.0.0.0:9292
+[Raptor 83658|Main|Main] Worker 2 booted
+[Raptor 83659|Main|Main] Worker 3 booted
+[Raptor 83656|Main|Main] Worker 0 booted
+[Raptor 83660|Main|Main] Worker 4 booted
+[Raptor 83662|Main|Main] Worker 6 booted
+[Raptor 83657|Main|Main] Worker 1 booted
+[Raptor 83661|Main|Main] Worker 5 booted
+[Raptor 83663|Main|Main] Worker 7 booted
+[Raptor 83664|Main|Main] Worker 8 booted
+[Raptor 83665|Main|Main] Worker 9 booted
 ```
 
 ```
@@ -85,7 +92,6 @@ The config file is a Ruby file that evaluates to a hash of options. By default R
   socket_backlog: 1024,
   drain_accept_queue: false,
   workers: 4, # `Etc.nprocessors`
-  ractors: 1,
   threads: 3,
   chdir: nil,
   environment: nil, # falls back to `RAILS_ENV`, then `RACK_ENV`, then `"development"`
@@ -97,10 +103,12 @@ The config file is a Ruby file that evaluates to a hash of options. By default R
     body_spool_threshold: 1024 * 1024,
   },
   http1: {
+    ractors: nil,
     persistent_data_timeout: 65,
     max_keepalive_requests: 100,
   },
   http2: {
+    ractors: nil,
     max_concurrent_streams: 100,
   },
   worker_boot_timeout: 60,
@@ -193,7 +201,7 @@ Worker 1 (phase 0): pid=91351, requests=1199, busy=1/3, backlog=0, booted, last_
 
 ## (Micro) Benchmarks
 
-Raptor 0.15.1 vs Puma 8.0.2 vs PumaPlus 0.1.0 vs Falcon 0.57.0 across two workload profiles. **IO-bound** is a GET
+Raptor 0.16.0 vs Puma 8.0.2 vs PumaPlus 0.1.0 vs Falcon 0.57.0 across two workload profiles. **IO-bound** is a GET
 endpoint that interleaves 5-10 short sleeps (total 2.5-15ms) with small CPU work, simulating a read path that makes
 several DB or cache calls. **CPU-bound** is a POST endpoint that accepts a small JSON body, interleaves 3-5 chunks of
 JSON item building (total 450-1500 items) with sub-100µs sleeps, and returns the built array, simulating a write path
@@ -202,16 +210,16 @@ that does most of its work in Ruby with a few near-zero-cost cache hits.
 Each cell reports the median throughput and median p95 latency independently across 5 runs, so the two numbers in a row
 may come from different runs. Every run starts a fresh server process so the samples are independent of each other;
 state accumulated in a previous run cannot bias the next. Across the whole table, the widest spread
-((max - min) / 2 / median) between runs of a single cell was ±29.5% for throughput and ±42.2% for p95.
+((max - min) / 2 / median) between runs of a single cell was ±24.8% for throughput and ±40.3% for p95.
 
 | Protocol              | Workload | Raptor req/s | Raptor p95 | Puma req/s  | Puma p95  | vs Puma req/s | vs Puma p95  | PumaPlus req/s | PumaPlus p95 | vs PumaPlus req/s | vs PumaPlus p95 | Falcon req/s | Falcon p95 | vs Falcon req/s | vs Falcon p95 |
 | --------------------- | -------- | ------------ | ---------- | ----------- | --------- | ------------- | ------------ | -------------- | ------------ | ----------------- | --------------- | ------------ | ---------- | --------------- | ------------- |
-| HTTP/1.1              | IO       | 3.28k req/s  | 59.90 ms   | 1.44k req/s | 132.20 ms | 127.7% higher | 54.7% lower  | 1.55k req/s    | 91.30 ms     | 111.3% higher     | 34.4% lower     | 12.50k req/s | 13.80 ms   | 73.7% lower     | 334.1% higher |
-| HTTP/1.1              | CPU      | 8.49k req/s  | 32.40 ms   | 9.08k req/s | 19.40 ms  | 6.5% lower    | 67.0% higher | 8.79k req/s    | 17.40 ms     | 3.4% lower        | 86.2% higher    | 6.89k req/s  | 25.50 ms   | 23.2% higher    | 27.1% higher  |
-| HTTP/1.1 (keep-alive) | IO       | 2.08k req/s  | 54.60 ms   | 1.40k req/s | 112.80 ms | 48.0% higher  | 51.6% lower  | 1.53k req/s    | 91.10 ms     | 35.8% higher      | 40.1% lower     | 6.17k req/s  | 28.70 ms   | 66.3% lower     | 90.2% higher  |
-| HTTP/1.1 (keep-alive) | CPU      | 9.04k req/s  | 17.40 ms   | 8.92k req/s | 21.30 ms  | 1.3% higher   | 18.3% lower  | 9.04k req/s    | 17.00 ms     | 0.1% higher       | 2.4% higher     | 7.32k req/s  | 29.90 ms   | 23.5% higher    | 41.8% lower   |
-| HTTP/2                | IO       | 0.97k req/s  | 201.32 ms  | N/A         | N/A       | -             | -            | 1.49k req/s    | 92.51 ms     | 35.0% lower       | 117.6% higher   | 6.61k req/s  | 27.95 ms   | 85.4% lower     | 620.4% higher |
-| HTTP/2                | CPU      | 5.42k req/s  | 35.22 ms   | N/A         | N/A       | -             | -            | 8.61k req/s    | 18.18 ms     | 37.0% lower       | 93.8% higher    | 7.32k req/s  | 29.95 ms   | 25.9% lower     | 17.6% higher  |
+| HTTP/1.1              | IO       | 3.21k req/s  | 63.20 ms   | 1.48k req/s | 131.00 ms | 117.7% higher | 51.8% lower  | 1.63k req/s    | 84.20 ms     | 97.0% higher      | 24.9% lower     | 12.27k req/s | 14.00 ms   | 73.8% lower     | 351.4% higher |
+| HTTP/1.1              | CPU      | 8.29k req/s  | 33.30 ms   | 8.56k req/s | 21.20 ms  | 3.2% lower    | 57.1% higher | 8.08k req/s    | 19.20 ms     | 2.6% higher       | 73.4% higher    | 6.62k req/s  | 27.00 ms   | 25.2% higher    | 23.3% higher  |
+| HTTP/1.1 (keep-alive) | IO       | 2.43k req/s  | 54.40 ms   | 1.44k req/s | 110.20 ms | 68.7% higher  | 50.6% lower  | 1.58k req/s    | 87.10 ms     | 54.2% higher      | 37.5% lower     | 6.28k req/s  | 27.90 ms   | 61.3% lower     | 95.0% higher  |
+| HTTP/1.1 (keep-alive) | CPU      | 8.40k req/s  | 18.80 ms   | 8.49k req/s | 21.90 ms  | 1.1% lower    | 14.2% lower  | 8.36k req/s    | 18.40 ms     | 0.4% higher       | 2.2% higher     | 7.09k req/s  | 31.50 ms   | 18.5% higher    | 40.3% lower   |
+| HTTP/2                | IO       | 0.97k req/s  | 197.97 ms  | N/A         | N/A       | -             | -            | 1.52k req/s    | 90.13 ms     | 36.0% lower       | 119.6% higher   | 6.59k req/s  | 27.21 ms   | 85.2% lower     | 627.6% higher |
+| HTTP/2                | CPU      | 6.61k req/s  | 31.98 ms   | N/A         | N/A       | -             | -            | 8.05k req/s    | 19.23 ms     | 17.9% lower       | 66.3% higher    | 8.09k req/s  | 45.04 ms   | 18.3% lower     | 29.0% lower   |
 
 > ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [aarch64-linux]
 > 10 worker processes; Raptor, Puma, and PumaPlus run 3 threads per worker, Falcon runs unbounded fibers per worker;

data/docs/brisrails-talk.md

@@ -571,13 +571,17 @@ flowchart TB
         SRV["Server thread<br/>IO.select + accept_nonblock"]
         RCT["Reactor thread<br/>NIO::Selector<br/>red-black tree of timeouts"]
 
-        subgraph RP["Ractor pool"]
-            CRD["Coordinator Ractor"]
+        subgraph RP1["HTTP/1.1 Ractor pool"]
             RW1["Pipeline Ractor 1"]
             RWM["Pipeline Ractor M"]
         end
 
-        COL["Collector thread<br/>drains Ractor::Port"]
+        subgraph RP2["HTTP/2 Ractor pool"]
+            RW2["Pipeline Ractor 1"]
+            RWN["Pipeline Ractor N"]
+        end
+
+        COL["Collector threads<br/>drain Ractor::Ports"]
 
         subgraph ATP["Thread pool, lock-free CAS queue"]
             T1["App thread 1"]
@@ -588,8 +592,10 @@ flowchart TB
         STA["Stats thread<br/>writes 1 Hz"]
 
         SRV --> RCT
-        RCT --> RP
-        RP --> COL
+        RCT --> RP1
+        RCT --> RP2
+        RP1 --> COL
+        RP2 --> COL
         COL --> ATP
         STA --> SHM[("mmap")]
     end
@@ -620,9 +626,9 @@ Every part earns its keep. Let's walk it.
 <br>
 <br>
 
-## The Ractor pool
+## The Ractor pools
 
-The parser. This is where the parallelism actually kicks in.
+Parsing runs in dedicated Ractor pools, one per HTTP protocol. This is where the parallelism actually kicks in.
 
 ```mermaid
 flowchart LR
@@ -1271,8 +1277,8 @@ flowchart TB
     Client(["client"])
     Srv["Server thread<br/>accept_nonblock"]
     Rct["Reactor thread<br/>read_nonblock 64KB"]
-    RP["Ractor pool<br/>parses in own GVL"]
-    Col["Collector thread<br/>drains Ractor::Port"]
+    RP["Protocol-specific Ractor pool<br/>parses in own GVL"]
+    Col["Collector threads<br/>drain Ractor::Ports"]
     ATP["App thread pool<br/>calls Rack app<br/>writes response"]
 
     Client -->|"SYN"| Srv
@@ -1311,7 +1317,7 @@ flowchart TB
 **Fast path**
 
 - <big>First `read_nonblock` gives us a complete request</big>
-- <big>Server thread parses inline</big>
+- <big>Server thread (HTTP/1.1) or accepting pool worker (HTTP/2) parses inline</big>
 - <big>Pushes a proc to the app pool</big>
 - <big>No reactor. No Ractor pool.</big>
 - <big>Common for a normal request that fits in one TCP packet.</big>
@@ -1320,7 +1326,7 @@ flowchart TB
 
 - <big>Bytes not ready, or the request is incomplete</big>
 - <big>Reactor takes over, waits for more bytes</big>
-- <big>When bytes arrive: read up to 64KB per syscall, hand the buffer to the Ractor pool</big>
+- <big>When bytes arrive: read up to 64KB per syscall, hand the buffer to the protocol's Ractor pool</big>
   - 64KB is the per-read size, not a request size limit. Bigger requests just come in over more reads.
 - <big>Ractor parses on a **separate GVL**</big>
 - <big>Parsed env comes back via the collector, which pushes to the app pool</big>
@@ -1487,7 +1493,7 @@ Notable: a single HTTP/2 client connection in Raptor can have many streams in fl
 - <big>Each stream is a separate work item in the queue</big>
 - <big>Different streams from the same connection can end up on different app threads</big>
 - <big>Those threads still share the main GVL, so they overlap productively when the app is in I/O (the common Rails case), the same way Puma's keep-alive requests do</big>
-- <big>The parsing for each stream happens in the Ractor pool on its own GVL, actually in parallel with the app work</big>
+- <big>The parsing for each stream happens in the HTTP/2 Ractor pool on its own GVL, actually in parallel with the app work</big>
 
 <br>
 <br>
@@ -2204,7 +2210,7 @@ I didn't set out to build a small library ecosystem. It's what happens when you
 
 Real numbers are in the [README benchmarks section](../README.md#micro-benchmarks). The shape:
 
-- <big>**IO-bound work**: Falcon wins by a wide margin. Its fibers keep every one of the 48 client connections in flight at once. Thread-based servers cap out at their pool size.</big>
+- <big>**IO-bound work**: Falcon wins by a wide margin. Its fibers keep every client connection in flight at once. Thread-based servers cap out at their pool size.</big>
 - <big>**CPU-bound HTTP/1.1**: Raptor beats Puma on both throughput and tail latency.</big>
   - Tail latency ("p95") is the response time that 5% of requests exceed. It's what your slowest users see. Lower is better.
 - <big>**HTTP/2**: Raptor and Falcon both implement it. Puma doesn't.</big>

data/docs/raptor-vs-puma.md

@@ -20,7 +20,7 @@ This document focuses on Puma because Puma is the incumbent that any new Ruby we
 
 Raptor is a research project. It hasn't run production traffic. The numbers in the README come from a repeatable microbenchmark, not from a real deployment. The benchmark measures only the **server** work: accepting connections, parsing, dispatching, and writing responses. It does not measure your application. In a typical Rails app where most of a request's time goes to ActiveRecord and downstream services, the server accounts for maybe 5 to 15 percent of the total, so a +N% number in this table will show up as a much smaller improvement in production. The gap is real, but it isn't what a Rails app against a real database will report.
 
-The Raptor README carries the [current head-to-head numbers](../README.md#micro-benchmarks) against the latest Puma and Falcon releases, run on the same hardware with the same Rack app on a recent Ruby with YJIT enabled. All three servers run four worker processes; Raptor and Puma use three threads per worker, and Falcon uses unbounded fibers per worker. Load generators use 48 concurrent HTTP/1.1 client connections, and 16 h2 connections × 3 streams each for the h2 rows.
+The Raptor README carries the [current head-to-head numbers](../README.md#micro-benchmarks) against the latest Puma and Falcon releases, run on the same hardware with the same Rack app on a recent Ruby with YJIT enabled. All servers run one worker process per available CPU; Raptor, Puma, and PumaPlus use three threads per worker, and Falcon uses unbounded fibers per worker. Load generators use four client connections per app thread, so on the 10-core machine that produced the current numbers that's 120 concurrent HTTP/1.1 client connections and 40 h2 connections × 3 streams each.
 
 Two workload profiles are measured. **IO-bound** is a GET endpoint that does 5 to 10 short sleeps interleaved with small CPU work per request, simulating a read path that makes several DB or cache calls throughout its lifetime. **CPU-bound** is a POST endpoint with a small JSON body that builds a JSON response in 3 to 5 chunks interleaved with sub-100µs sleeps, simulating a write path that does most of its work in Ruby with a few near-zero-cost cache hits. The workloads are interleaved rather than a single bulk sleep or single bulk serialise so a fiber-per-connection server like Falcon doesn't look artificially good from one-shot IO, and the CPU-bound workload is heavily CPU-dominated by design (roughly 95% CPU / 5% IO by wall time) so it actually measures CPU work rather than smuggling in enough IO for fibers to multiplex.
 
@@ -212,14 +212,15 @@ The design is Pitchfork's, adapted for Raptor's process model. [Pitchfork](https
 
 ### Threading model
 
-This is where Raptor diverges dramatically. Inside a worker there are five kinds of concurrent activity:
+This is where Raptor diverges dramatically. Inside a worker there are six kinds of concurrent activity:
 
 1. **One server thread** running the accept loop.
 2. **One reactor thread** running the NIO event loop plus timeout tree.
-3. **A `RactorPool` of M pipeline Ractors** doing HTTP parsing in parallel. Default M is 1, but the interesting part is that this can be scaled up.
-4. **A collector thread** that receives parsed results from the pipeline Ractors via a `Ractor::Port`.
-5. **An `AtomicThreadPool` of T app threads** running the Rack app and writing responses.
-6. Plus one stats thread that writes the shared-memory slot every second.
+3. **A `RactorPool` for HTTP/1.1 parsing** sized by `http1.ractors`, defaulting to `round(cores / workers)` clamped to `[1, 3]`.
+4. **A `RactorPool` for HTTP/2 parsing** sized by `http2.ractors`, defaulting to `round(cores / workers)` clamped to `[1, 2]`.
+5. **A collector thread per Ractor pool** that receives parsed results via a `Ractor::Port`.
+6. **An `AtomicThreadPool` of T app threads** running the Rack app and writing responses.
+7. Plus one stats thread that writes the shared-memory slot every second.
 
 That is a lot of moving parts. Let us go through why.
 
@@ -231,7 +232,9 @@ The HTTP/1 parser also pre-interns the ~40 most common header keys (`HTTP_HOST`,
 
 The upshot is that while your Rack app runs on regular threads under the GVL (so your app does not need to be Ractor-safe), the protocol-level work runs in parallel across Ractors. Under heavy load with lots of small requests, the GVL contention that would otherwise dominate parsing simply is not there.
 
-**How the Ractor pool actually works.** Raptor uses the `ractor-pool` gem, which is another one of my libraries. The pool has one coordinator Ractor and M pipeline Ractors. When a pipeline Ractor is idle, it sends itself back to the coordinator via `coordinator.send(Ractor.current, move: true)`. When work arrives at the coordinator, it either forwards it to a waiting Ractor (if any) or queues it. This coordinator-dispatch pattern guarantees that no Ractor sits idle while there is work. Results flow back through a shared `Ractor::Port` (a many-to-one channel added in recent Ruby versions and stable in 4.0) to a Ruby-side collector thread. If `M == 1` the coordinator is skipped and work goes straight to the single pipeline Ractor; this is the default because a single Ractor already parses in parallel with the app threads and adds enough headroom for typical workloads.
+**How the Ractor pools actually work.** Raptor uses the `ractor-pool` gem, which is another one of my libraries. Each pool has one coordinator Ractor and M pipeline Ractors. When a pipeline Ractor is idle, it sends itself back to the coordinator via `coordinator.send(Ractor.current, move: true)`. When work arrives at the coordinator, it either forwards it to a waiting Ractor (if any) or queues it. This coordinator-dispatch pattern guarantees that no Ractor sits idle while there is work. Results flow back through a shared `Ractor::Port` (a many-to-one channel added in recent Ruby versions and stable in 4.0) to a Ruby-side collector thread. If `M == 1` the coordinator is skipped and work goes straight to the single pipeline Ractor.
+
+Raptor runs two independent pools per worker, one for HTTP/1.1 parsing and one for HTTP/2 parsing. Both defaults scale with headroom via `round(cores / workers)`, clamped to `[1, 3]` for `http1.ractors` and `[1, 2]` for `http2.ractors`. Splitting the pools means h1 and h2 parsing never share ractor slots, so a burst of small HTTP/1.1 requests cannot delay HTTP/2 frame handling on the same connection, and vice versa.
 
 Note that Ractors also have their own copy of the code, so booting them means loading dependencies inside each Ractor context. Raptor pre-loads only what the parser needs.
 
@@ -243,15 +246,22 @@ The knock-on effect is that reading pool state to make backpressure decisions is
 
 ### I/O model
 
-The server accept loop is an `IO.select` + `accept_nonblock` loop, similar to Puma. What is different is the check right before `accept`:
+The server accept loop is an `IO.select` + `accept_nonblock` loop, similar to Puma. What is different is the pair of checks right before `accept`:
 
 ```ruby
-backpressure_threshold = [(@thread_pool.size * 1.2).ceil, MIN_BACKPRESSURE_THRESHOLD].max
+backpressure_threshold = [(@thread_pool.size * BACKPRESSURE_THRESHOLD_MULTIPLIER).ceil, MIN_BACKPRESSURE_THRESHOLD].max
 # ...
 next if @reactor.backlog >= backpressure_threshold
+
+if @thread_pool.queue_size > @thread_pool.size
+  Thread.pass
+  next
+end
 ```
 
-where `@reactor.backlog` is `thread_pool.queue_size + thread_pool.active_count`. If the total load on the thread pool is at 120% of the pool size, this worker stops accepting until it drains. `MIN_BACKPRESSURE_THRESHOLD` is 8, so small pools (say, 3 threads) trip backpressure at 8 concurrent items rather than at 120% of a very small number; the floor keeps saturated workers signaling early so the load-aware dispatcher (below) has time to route around them.
+The first is a hard skip. `@reactor.backlog` is `thread_pool.queue_size + thread_pool.active_count`; when the total load reaches 120% of the pool size, this worker stops accepting until it drains. `MIN_BACKPRESSURE_THRESHOLD` is 8, so small pools (say, 3 threads) trip backpressure at 8 concurrent items rather than at 120% of a very small number; the floor keeps saturated workers signaling early so the load-aware dispatcher (below) has time to route around them.
+
+The second is a softer yield. When the queue alone exceeds the pool size — the app threads are all busy and there's a queue building on top of them — the accept loop yields the GVL via `Thread.pass` and re-checks the queue on the next iteration instead of accepting more work. This lets the app threads make progress before the server thread grabs another connection, and only fires under real pool pressure (queue depth greater than pool size), so IO-bound workloads where threads spend most of their time in `sleep` and rarely queue past the pool size aren't affected.
 
 Because Raptor is always in cluster mode and every worker listens in the same `SO_REUSEPORT` group, load balancing across workers happens at the kernel level. On Linux, Raptor attaches a small BPF program to the reuseport group. Each worker binds its own listener registered in a sockmap, and a dedicated reporter thread publishes the worker's current reactor backlog into a loads map every millisecond. The BPF program consults the map on every incoming connection. When the spread between the busiest and idlest worker is within one, it treats all workers as tied and hash-distributes the connection by its 4-tuple; otherwise it routes to the least-loaded worker. The tie band matters. Without it, a worker that briefly drained one request would attract every subsequent connection until the next load update, herding bursts onto whichever worker most recently reported the lowest load. If the `libbpf-ruby` gem is not installed or the BPF object has not been compiled, Raptor falls back silently to the default four-tuple-hash routing; if the kernel refuses the program, startup raises. Either way, if a worker is saturated and stops calling `accept`, other workers pick up the slack.
 
@@ -259,7 +269,7 @@ The BPF-based approach was inspired by [a comment](https://github.com/puma/puma/
 
 The reactor is again an `NIO::Selector` loop. Two things make it different from Puma's:
 
-1. **Read strategy.** When a socket is readable, the reactor does one `read_nonblock(64KB)` right there in the reactor thread, updates the buffered state for that connection, and only then decides what to do. If the request is not yet complete, the state stays in the reactor and awaits more data. If it is complete (headers parsed, body received), the state is pushed to the Ractor pool for parsing (or, for HTTP/2, straight to the parser). The reactor does not try to parse; it does the I/O and hands off the raw buffer.
+1. **Read strategy.** When a socket is readable, the reactor does one `read_nonblock(64KB)` right there in the reactor thread, updates the buffered state for that connection, and only then decides what to do. If the request is not yet complete, the state stays in the reactor and awaits more data. If it is complete (headers parsed, body received), the state is pushed to the protocol's Ractor pool for parsing. The reactor does not try to parse; it does the I/O and hands off the raw buffer.
 
 2. **Timeout data structure.** Instead of a sorted linked list, timeouts are stored in a red-black tree (`red-black-tree` gem, yes, also one of mine). Each connection is represented by a `TimeoutClient < RedBlackTree::Node` ordered by its `timeout_at` value. Insertion is O(log n), deletion by key (needed when a connection's timeout is updated mid-flight, which happens on every read) is O(log n), and in-order traversal is O(k) where k is the number of expired connections. After every selector poll, the reactor walks the tree in order and breaks on the first non-expired node.
 
@@ -312,12 +322,12 @@ The `reactor.persist` call re-registers the socket with the reactor using `persi
 
 Raptor speaks HTTP/2 on TLS connections where the client negotiates it via ALPN. The binder sets `alpn_protocols = ["h2", "http/1.1"]` on the SSL context and the ALPN callback picks h2 whenever the client offers it. Puma does not do this. Puma's SSL context does not advertise `h2` in ALPN, so clients transparently fall back to HTTP/1.1.
 
-Once ALPN selects h2, the initial `SETTINGS` frame is written and the socket is registered in the reactor with `protocol: :http2` plus a fresh `Writer` and `FlowControl` for the connection.
+Once ALPN selects h2, the pool worker that ran the TLS handshake calls `Http2#eager_accept`, which creates the per-connection `Writer` and `FlowControl`, attaches them to the reactor, writes the initial `SETTINGS` frame, and tries a non-blocking read on the socket. If bytes are already there, it parses the first frame batch inline via `Http2.process_frames` and dispatches completed streams to the thread pool without ever touching the ractor pool. If not, it hands the socket to the reactor to watch for the first bytes.
 
 From there the shape is similar to HTTP/1.1:
 
 1. Reactor reads frames.
-2. The HTTP/2 parser (native C, with an HPACK decoder using a static Huffman table) parses the frames in the Ractor pool.
+2. The HTTP/2 parser (native C, with an HPACK decoder using a static Huffman table) parses the frames in the HTTP/2 Ractor pool.
 3. Completed requests (once `HEADERS` and `DATA` are complete for a stream) go to the thread pool as separate work items. **A single connection can be servicing many streams in parallel across the thread pool.**
 4. Each stream's response is written back through the connection's `Writer`, which serialises frame writes across threads without a mutex.
 
@@ -350,15 +360,17 @@ flowchart TB
 
         RCT["Reactor thread<br/>NIO::Selector<br/>read_nonblock 64KB<br/>Red-Black-Tree timeouts"]
 
-        subgraph RP["RactorPool"]
-            CRD["Coordinator Ractor<br/>coordinator-dispatch"]
-            RW1["Pipeline Ractor 1<br/>HTTP1 + HTTP2 parser<br/>chunked decode<br/>HPACK decode"]
+        subgraph RP1["HTTP/1.1 RactorPool"]
+            RW1["Pipeline Ractor 1<br/>HTTP/1.x parser<br/>chunked decode"]
             RWM["Pipeline Ractor M"]
-            CRD --> RW1
-            CRD --> RWM
         end
 
-        COL["Collector thread<br/>Ractor::Port receive<br/>dispatches to thread pool<br/>or back to reactor"]
+        subgraph RP2["HTTP/2 RactorPool"]
+            RW2["Pipeline Ractor 1<br/>HTTP/2 parser<br/>HPACK decode"]
+            RWN["Pipeline Ractor N"]
+        end
+
+        COL["Collector threads<br/>Ractor::Port receive<br/>dispatch to thread pool<br/>or back to reactor"]
 
         subgraph ATP["AtomicThreadPool, CAS work queue"]
             TR1["App thread 1"]
@@ -372,10 +384,13 @@ flowchart TB
         KA{"Keep-alive?"}
         EAG{"wait_readable<br/>1ms"}
 
-        SRV -->|"eager_accept, parse inline, push proc"| ATP
-        SRV -->|"data not ready or incomplete, reactor.add"| RCT
-        RCT -->|"Ractor.make_shareable state"| RP
-        RP -->|"result via Ractor::Port"| COL
+        SRV -->|"HTTP/1.1 eager_accept, parse inline, push proc"| ATP
+        SRV -->|"HTTP/2 eager_accept, parse inline, push proc"| ATP
+        SRV -->|"data not ready or incomplete, hand to reactor"| RCT
+        RCT -->|"HTTP/1.1 state via Ractor.make_shareable"| RP1
+        RCT -->|"HTTP/2 state via Ractor.make_shareable"| RP2
+        RP1 -->|"result via Ractor::Port"| COL
+        RP2 -->|"result via Ractor::Port"| COL
         COL --> CHK
         CHK -->|"no, more bytes needed"| RCT
         CHK -->|"yes, push proc"| ATP
@@ -399,13 +414,14 @@ flowchart TB
     classDef storage fill:#e5e7eb,stroke:#6b7280,color:#374151
     class SRV accept
     class RCT reactor
-    class RP parse
+    class RP1 parse
+    class RP2 parse
     class ATP pool
     class COL collector
     class SHM storage
 ```
 
-The critical structural difference from Puma is that parsing is not on the app thread. It is on the Ractor pool. The app thread only does the Rack call and the response write. This decouples the two costs and lets Ruby actually use more than one CPU for the protocol work.
+The critical structural difference from Puma is that parsing is not on the app thread. It is on the protocol's Ractor pool. The app thread only does the Rack call and the response write. This decouples the two costs and lets Ruby actually use more than one CPU for the protocol work.
 
 ## Part III: Head to head
 
@@ -413,9 +429,9 @@ The critical structural difference from Puma is that parsing is not on the app t
 
 **Puma.** Parsing happens on the app thread. The C parser callbacks build the env hash. Between requests, the thread either loops (if there's back-to-back data and a spare thread) or hands off to the reactor. Every request goes through: reactor → thread pool → parser (Ruby thread + C ext) → app → write → reactor. Parsing shares the GVL with the app.
 
-**Raptor.** Parsing happens on Ractors. Between requests, the app thread does a 1ms micro-poll before handing back. Every request goes through: reactor (I/O only) → Ractor pool (parse only) → collector → thread pool (app + write) → 1ms wait → maybe repeat. Parsing does not share the GVL with the app because Ractors have their own GVLs.
+**Raptor.** Parsing happens on Ractors. Between requests, the app thread does a 1ms micro-poll before handing back. Every request goes through: reactor (I/O only) → protocol's Ractor pool (parse only) → collector → thread pool (app + write) → 1ms wait → maybe repeat. Parsing does not share the GVL with the app because Ractors have their own GVLs.
 
-The concrete effect is that Puma has one process-wide GVL. Every thread inside a worker (server, reactor, and every app thread) has to take turns holding it. Raptor has that same main-process GVL plus one additional GVL per Ractor. With 3 app threads and 1 pipeline Ractor, Raptor can genuinely run two things at once on two CPU cores. The Ractor parses an incoming request while an app thread executes the Rack app. Puma cannot. Under CPU-heavy parsing (many small requests, high header count), Raptor's parsing throughput is straightforwardly higher because the parse never contends with the app for the same GVL.
+The concrete effect is that Puma has one process-wide GVL. Every thread inside a worker (server, reactor, and every app thread) has to take turns holding it. Raptor has that same main-process GVL plus one additional GVL per Ractor. With 3 app threads and one HTTP/1.1 pipeline Ractor plus one HTTP/2 pipeline Ractor, Raptor can genuinely run three things at once on three CPU cores. A Ractor parses an incoming request while an app thread executes the Rack app. Puma cannot. Under CPU-heavy parsing (many small requests, high header count), Raptor's parsing throughput is straightforwardly higher because the parse never contends with the app for the same GVL.
 
 ### Timeout management
 
@@ -449,7 +465,7 @@ This is where most of Raptor's keep-alive edge comes from. Subsequent requests a
 
 **Puma.** Cluster mode uses `accept_loop_delay` (sleep proportional to busy ratio) to prevent thundering herd across workers. Single-worker backpressure is implicit; if all threads are busy and the queue is growing, new accepts pile up in the kernel accept queue. Puma does have `queue_requests` (default true) which pushes partial requests into the reactor, freeing the accept loop, but there is no explicit "stop accepting" signal from the worker.
 
-**Raptor.** Explicit backpressure formula, read every iteration of the accept loop: `if backlog >= max(pool_size * 1.2, 8), skip accept`. When a worker is saturated, other workers pick up the traffic. On Linux, an eBPF program attached to the reuseport group actively routes new connections to the least-loaded worker (see the I/O model section); elsewhere Raptor relies on the kernel's default four-tuple-hash routing.
+**Raptor.** Explicit backpressure, read every iteration of the accept loop: hard skip when `backlog >= max(pool_size * 1.2, 8)`, and a softer `Thread.pass` yield when the queue alone exceeds the pool size. When a worker is saturated, other workers pick up the traffic. On Linux, an eBPF program attached to the reuseport group actively routes new connections to the least-loaded worker (see the I/O model section); elsewhere Raptor relies on the kernel's default four-tuple-hash routing.
 
 ### Shared state (worker ↔ master)
 
@@ -551,7 +567,7 @@ Puma has to bounce Request 3 through the reactor and back through the mutex-prot
 
 ### IO-bound work, where Falcon wins and Raptor clearly beats Puma
 
-On the IO-bound benchmark profile, each request does 5 to 10 short sleeps interleaved with small CPU work, simulating a request that makes several DB or cache calls throughout its lifetime. The bottleneck is how many requests a worker can keep in flight while they wait on IO. Raptor and Puma cap out at their 12 total threads (4 workers × 3), so with 48 client connections the extra 36 sit in the pool queue at any given moment. Falcon spawns a fiber per connection and cooperatively yields on every sleep, so all 48 requests can be in flight simultaneously. That gap shows up as roughly 3-4x throughput and much lower p95 for Falcon.
+On the IO-bound benchmark profile, each request does 5 to 10 short sleeps interleaved with small CPU work, simulating a request that makes several DB or cache calls throughout its lifetime. The bottleneck is how many requests a worker can keep in flight while they wait on IO. Raptor and Puma cap out at three threads per worker, so the client connections beyond that (four per app thread, per the load generator's ratio) sit in the pool queue at any given moment. Falcon spawns a fiber per connection and cooperatively yields on every sleep, so every client connection can be in flight simultaneously. That gap shows up as roughly 3-4x throughput and much lower p95 for Falcon.
 
 Between the thread-based servers, Raptor holds a clear lead over Puma on both throughput and p95. The eager accept path, writev-batched responses, and lock-free work queue all shave a bit of per-request time, and those savings stack.
 
@@ -573,7 +589,7 @@ Where Raptor's HTTP/2 support does matter is the all-Ruby stack. No proxy in fro
 
 Falcon also speaks HTTP/2 natively, so it's the interesting comparison there rather than Puma. The shape of the h2 result follows the h1 shape. On CPU-bound h2 Raptor lands close to Falcon on throughput and holds a meaningful edge on p95, for the same reasons it wins CPU-bound h1 keep-alive. Parsing runs in parallel with the app, the lock-free writer serialises frames without a mutex, and per-stream flow-control atoms don't contend. On IO-bound h2 Falcon wins by a wide margin, again because fibers can keep every stream in flight simultaneously while Raptor's thread pool caps concurrency.
 
-Raptor's h2 IO numbers still show some run-to-run variance where h1 doesn't. With only 16 physical connections spread across four workers, even the BPF program's hash-based tie-break can leave one worker over-subscribed, and the concentrated worker becomes the bottleneck for that whole run. h2 CPU stays tight because once workers report distinguishable load the load-aware routing has enough signal to place new connections cleanly regardless of tie-break behaviour.
+Raptor's h2 IO numbers still show some run-to-run variance where h1 doesn't. With only four physical h2 connections per worker, even the BPF program's hash-based tie-break can leave one worker over-subscribed, and the concentrated worker becomes the bottleneck for that whole run. h2 CPU stays tight because once workers report distinguishable load the load-aware routing has enough signal to place new connections cleanly regardless of tie-break behaviour.
 
 Beyond that, Raptor's HTTP/2 CPU-bound throughput in the benchmark is on the same order as its HTTP/1.1 keep-alive throughput on the same profile, despite each connection multiplexing dozens of concurrent streams into a single socket. That only happens if the per-stream coordination is essentially free. The lock-free `Writer` and flow-control atoms are doing real work here. If they used mutexes, throughput would be capped by lock contention rather than by CPU.
 

data/lib/rackup/handler/raptor.rb

@@ -81,7 +81,6 @@ module Rackup
           socket_backlog: (config[:socket_backlog] || cli_defaults[:socket_backlog]).to_i,
           drain_accept_queue: config.key?(:drain_accept_queue) ? config[:drain_accept_queue] : cli_defaults[:drain_accept_queue],
           workers: (options[:Workers] || config[:workers] || Concurrent.available_processor_count).to_i,
-          ractors: (options[:Ractors] || config[:ractors] || cli_defaults[:ractors]).to_i,
           threads: (options[:Threads] || config[:threads] || cli_defaults[:threads]).to_i,
           app: app
         }

data/lib/raptor/cli.rb

@@ -33,7 +33,6 @@ module Raptor
       socket_backlog: 1024,
       drain_accept_queue: false,
       workers: DEFAULT_WORKER_COUNT,
-      ractors: 1,
       threads: 3,
       rackup: "config.ru",
       chdir: nil,
@@ -46,10 +45,12 @@ module Raptor
         body_spool_threshold: 1024 * 1024,
       },
       http1: {
+        ractors: nil,
         persistent_data_timeout: 65,
         max_keepalive_requests: 100,
       },
       http2: {
+        ractors: nil,
         max_concurrent_streams: 100,
       },
       worker_boot_timeout: 60,
@@ -237,10 +238,6 @@ module Raptor
           @options[:workers] = num
         end
 
-        opts.on("-r", "--ractors NUM", Integer, "Number of pipeline ractors per worker (default: 1)") do |num|
-          @options[:ractors] = num
-        end
-
         opts.on("-t", "--threads NUM", Integer, "Number of application threads per worker (default: 3)") do |num|
           @options[:threads] = num
         end
@@ -273,6 +270,10 @@ module Raptor
           @options[:connection][:body_spool_threshold] = bytes
         end
 
+        opts.on("--http1-ractors NUM", Integer, "Number of HTTP/1.1 pipeline ractors per worker (default: `round(cores / workers)`, clamped to 1..3)") do |num|
+          @options[:http1][:ractors] = num
+        end
+
         opts.on("--http1-persistent-data-timeout SECONDS", Integer, "HTTP/1.1 keep-alive idle timeout in seconds (default: 65)") do |timeout|
           @options[:http1][:persistent_data_timeout] = timeout
         end
@@ -281,6 +282,10 @@ module Raptor
           @options[:http1][:max_keepalive_requests] = num
         end
 
+        opts.on("--http2-ractors NUM", Integer, "Number of HTTP/2 pipeline ractors per worker (default: `round(cores / workers)`, clamped to 1..2)") do |num|
+          @options[:http2][:ractors] = num
+        end
+
         opts.on("--http2-max-concurrent-streams NUM", Integer, "Maximum HTTP/2 concurrent streams per connection (default: 100)") do |num|
           @options[:http2][:max_concurrent_streams] = num
         end

data/lib/raptor/cluster.rb

@@ -1,6 +1,7 @@
 # rbs_inline: enabled
 # frozen_string_literal: true
 
+require "concurrent/utility/processor_counter"
 require "json"
 
 require "atomic-ruby/atomic_thread_pool"
@@ -26,6 +27,9 @@ module Raptor
   class Cluster
     INHERITED_FDS_ENV = "RAPTOR_INHERITED_FDS"
 
+    HTTP1_RACTOR_COUNT_CAP = 3
+    HTTP2_RACTOR_COUNT_CAP = 2
+
     # Creates and runs a cluster with the given options.
     #
     # @param options [Hash] cluster configuration options
@@ -36,9 +40,38 @@ module Raptor
       new(options).run
     end
 
+    # Returns the default number of HTTP/1.1 pipeline ractors per
+    # worker for the given worker count, rounded from the available
+    # processor count per worker and clamped to
+    # `[1, HTTP1_RACTOR_COUNT_CAP]`.
+    #
+    # @param worker_count [Integer] the configured worker count
+    # @return [Integer]
+    #
+    # @rbs (Integer worker_count) -> Integer
+    def self.default_http1_ractor_count(worker_count)
+      cores = Integer(Concurrent.available_processor_count)
+      (cores.to_f / worker_count).round.clamp(1, HTTP1_RACTOR_COUNT_CAP)
+    end
+
+    # Returns the default number of HTTP/2 pipeline ractors per
+    # worker for the given worker count, rounded from the available
+    # processor count per worker and clamped to
+    # `[1, HTTP2_RACTOR_COUNT_CAP]`.
+    #
+    # @param worker_count [Integer] the configured worker count
+    # @return [Integer]
+    #
+    # @rbs (Integer worker_count) -> Integer
+    def self.default_http2_ractor_count(worker_count)
+      cores = Integer(Concurrent.available_processor_count)
+      (cores.to_f / worker_count).round.clamp(1, HTTP2_RACTOR_COUNT_CAP)
+    end
+
     # @rbs @drain_accept_queue: bool
     # @rbs @worker_count: Integer
-    # @rbs @ractor_count: Integer
+    # @rbs @http1_ractor_count: Integer
+    # @rbs @http2_ractor_count: Integer
     # @rbs @thread_count: Integer
     # @rbs @environment: String
     # @rbs @connection_options: Hash[Symbol, untyped]
@@ -91,7 +124,6 @@ module Raptor
     # @option options [Integer] :socket_backlog kernel listen() queue depth for TCP/SSL listeners
     # @option options [Boolean] :drain_accept_queue whether to drain the kernel accept queue on shutdown
     # @option options [Integer] :workers number of worker processes
-    # @option options [Integer] :ractors number of ractors per worker process
     # @option options [Integer] :threads number of threads per worker process
     # @option options [#call] :app pre-built Rack application
     # @option options [String] :rackup path to Rack configuration file
@@ -123,7 +155,8 @@ module Raptor
     def initialize(options)
       @drain_accept_queue = options[:drain_accept_queue]
       @worker_count = options[:workers]
-      @ractor_count = options[:ractors]
+      @http1_ractor_count = options[:http1][:ractors] || self.class.default_http1_ractor_count(@worker_count)
+      @http2_ractor_count = options[:http2][:ractors] || self.class.default_http2_ractor_count(@worker_count)
       @thread_count = options[:threads]
       @environment = options[:environment] || ENV["RAILS_ENV"] || ENV["RACK_ENV"] || "development"
       @connection_options = options[:connection]
@@ -736,23 +769,33 @@ module Raptor
         access_log_io: @access_log_io,
         on_error: @on_error
       )
-      ractor_pool = RactorPool.new(
-        size: @ractor_count,
-        worker: http1.parser_worker
+      http1_ractor_pool = RactorPool.new(
+        size: @http1_ractor_count,
+        worker: http1.parser_worker,
+        name: "HTTP/1.1"
       ) do |parsed_result|
         begin
-          if parsed_result[:protocol] == :http2
-            http2.handle_parsed_request(parsed_result, reactor, thread_pool)
-          else
-            http1.handle_parsed_request(parsed_result, reactor, thread_pool)
-          end
+          http1.handle_parsed_request(parsed_result, reactor, thread_pool)
+        rescue => error
+          Log.rescued_error(error)
+        end
+      end
+
+      http2_ractor_pool = RactorPool.new(
+        size: @http2_ractor_count,
+        worker: http2.parser_worker,
+        name: "HTTP/2"
+      ) do |parsed_result|
+        begin
+          http2.handle_parsed_request(parsed_result, reactor, thread_pool)
         rescue => error
           Log.rescued_error(error)
         end
       end
 
       reactor = Reactor.new(
-        ractor_pool,
+        http1_ractor_pool,
+        http2_ractor_pool,
         thread_pool,
         connection_options: @connection_options,
         http1_options: @http1_options
@@ -824,7 +867,8 @@ module Raptor
       server_thread.join
       reactor.shutdown
       reactor_thread.join
-      ractor_pool.shutdown
+      http1_ractor_pool.shutdown
+      http2_ractor_pool.shutdown
       http1.shutdown
       drain_thread_pool(thread_pool)
       stats_thread.join
@@ -931,8 +975,9 @@ module Raptor
       Log.info "│  └─ #{@worker_count} worker process#{"es" if @worker_count > 1}"
       Log.info "│     ├─ 1 server thread"
       Log.info "│     ├─ 1 reactor thread"
-      Log.info "│     ├─ #{@ractor_count} pipeline ractor#{"s" if @ractor_count > 1}"
-      Log.info "│     ├─ 1 pipeline collector thread"
+      Log.info "│     ├─ #{@http1_ractor_count} HTTP/1.1 pipeline ractor#{"s" if @http1_ractor_count > 1}"
+      Log.info "│     ├─ #{@http2_ractor_count} HTTP/2 pipeline ractor#{"s" if @http2_ractor_count > 1}"
+      Log.info "│     ├─ 2 pipeline collector threads"
       Log.info "│     ├─ #{@thread_count} worker thread#{"s" if @thread_count > 1}"
       Log.info "│     └─ 1 stats thread"
       Log.info "└─ Listening on #{@binder.addresses.join(", ")}"

data/lib/raptor/http.rb

@@ -93,8 +93,8 @@ module Raptor
       end
     end
 
-    # Returns a Ractor-safe proc that routes each pipeline task to the
-    # HTTP/1.x or HTTP/2 handler based on the state hash's `:protocol` key.
+    # Returns a Ractor-safe proc that parses an HTTP/1.x request from
+    # the state hash's buffered bytes.
     #
     # @param env_template [Hash] the Rack env template to seed each HTTP/1.x request with
     # @param max_body_size [Integer, nil] byte limit for HTTP/1.x request bodies, or nil for no limit
@@ -103,11 +103,7 @@ module Raptor
     # @rbs (Hash[String, untyped] env_template, Integer? max_body_size) -> ^(Hash[Symbol, untyped]) -> Hash[Symbol, untyped]
     def self.parser_worker(env_template, max_body_size)
       proc do |data|
-        if data[:protocol] == :http2
-          Raptor::Http2.process_frames(data)
-        else
-          Raptor::Http1.parse(data, env_template, max_body_size)
-        end
+        Raptor::Http1.parse(data, env_template, max_body_size)
       end
     end
 

data/lib/raptor/http2.rb

@@ -315,6 +315,18 @@ module Raptor
       Writer.new(write_timeout: @write_timeout)
     end
 
+    # Returns a Ractor-safe proc that parses HTTP/2 frames from the
+    # state hash's buffered bytes.
+    #
+    # @return [Proc]
+    #
+    # @rbs () -> ^(Hash[Symbol, untyped]) -> Hash[Symbol, untyped]
+    def parser_worker
+      proc do |data|
+        Raptor::Http2.process_frames(data)
+      end
+    end
+
     # Advances HTTP/2 frame parsing from the connection buffer, returning
     # updated connection state along with any outgoing protocol frames and
     # completed stream requests.
@@ -550,12 +562,61 @@ module Raptor
     end
     private_class_method :build_result
 
+    # Sends the server SETTINGS frame on a freshly negotiated HTTP/2
+    # connection, then eagerly reads and parses the first client frame
+    # batch, dispatching completed streams directly to the thread pool.
+    # Falls back to the reactor when no initial data is ready.
+    #
+    # @param socket [OpenSSL::SSL::SSLSocket] the connection socket
+    # @param id [Integer] unique client identifier
+    # @param reactor [Reactor] the reactor managing the connection
+    # @param thread_pool [AtomicThreadPool] thread pool for application processing
+    # @param remote_addr [String] client IP address
+    # @param url_scheme [String] "https"
+    # @return [void]
+    #
+    # @rbs (OpenSSL::SSL::SSLSocket socket, Integer id, Reactor reactor, AtomicThreadPool thread_pool, String remote_addr, String url_scheme) -> void
+    def eager_accept(socket, id, reactor, thread_pool, remote_addr, url_scheme)
+      writer = create_writer
+      flow_control = FlowControl.new
+      initial_state = {
+        id: id,
+        protocol: :http2,
+        remote_addr: remote_addr,
+        url_scheme: url_scheme
+      }
+
+      reactor.attach_http2(id: id, socket: socket, state: initial_state, writer: writer, flow_control: flow_control)
+
+      socket.write(@initial_settings_frame) rescue nil
+
+      buffer = begin
+        socket.read_nonblock(EAGER_READ_BUFFER_SIZE)
+      rescue IO::WaitReadable
+        reactor.watch(id)
+        return
+      rescue EOFError, IOError
+        reactor.close_connection(id)
+        return
+      end
+
+      while socket.pending.positive?
+        buffer << socket.read_nonblock(socket.pending)
+      end
+
+      result = Raptor::Http2.process_frames(initial_state.merge(buffer: buffer))
+      handle_parsed_request(result, reactor, thread_pool)
+    rescue => error
+      Log.rescued_error(error)
+      reactor.close_connection(id)
+    end
+
     # Handles a parsed HTTP/2 result. Writes outgoing frames, dispatches
     # completed stream requests to the thread pool, and eagerly consumes
     # further buffered frame batches before returning control to the
     # reactor.
     #
-    # @param result [Hash] the parsed result from the ractor pool
+    # @param result [Hash] the parsed result produced by {process_frames}
     # @param reactor [Reactor] the reactor managing the connection
     # @param thread_pool [AtomicThreadPool] thread pool for Rack app dispatch
     # @return [void]

data/lib/raptor/reactor.rb

@@ -54,7 +54,8 @@ module Raptor
     TIMEOUT_RESPONSE = "HTTP/1.1 408 Request Timeout\r\nContent-Length: 0\r\nConnection: close\r\n\r\n"
 
     # @rbs @thread_pool: untyped
-    # @rbs @ractor_pool: untyped
+    # @rbs @http1_ractor_pool: untyped
+    # @rbs @http2_ractor_pool: untyped
     # @rbs @first_data_timeout: Integer
     # @rbs @chunk_data_timeout: Integer
     # @rbs @persistent_data_timeout: Integer
@@ -69,7 +70,8 @@ module Raptor
 
     # Creates a new Reactor instance.
     #
-    # @param ractor_pool [RactorPool] ractor pool for HTTP parsing
+    # @param http1_ractor_pool [RactorPool] ractor pool for HTTP/1.x parsing
+    # @param http2_ractor_pool [RactorPool] ractor pool for HTTP/2 parsing
     # @param thread_pool [AtomicThreadPool] thread pool for application processing
     # @param connection_options [Hash] per-connection timeout configuration
     # @option connection_options [Integer] :first_data_timeout timeout for initial data
@@ -78,9 +80,10 @@ module Raptor
     # @option http1_options [Integer] :persistent_data_timeout timeout for keep-alive idle connections
     # @return [void]
     #
-    # @rbs (untyped ractor_pool, untyped thread_pool, connection_options: Hash[Symbol, untyped], http1_options: Hash[Symbol, untyped]) -> void
-    def initialize(ractor_pool, thread_pool, connection_options:, http1_options:)
-      @ractor_pool = ractor_pool
+    # @rbs (untyped http1_ractor_pool, untyped http2_ractor_pool, untyped thread_pool, connection_options: Hash[Symbol, untyped], http1_options: Hash[Symbol, untyped]) -> void
+    def initialize(http1_ractor_pool, http2_ractor_pool, thread_pool, connection_options:, http1_options:)
+      @http1_ractor_pool = http1_ractor_pool
+      @http2_ractor_pool = http2_ractor_pool
       @thread_pool = thread_pool
       @first_data_timeout = connection_options[:first_data_timeout]
       @chunk_data_timeout = connection_options[:chunk_data_timeout]
@@ -260,6 +263,40 @@ module Raptor
       @id_to_flow_control[id]
     end
 
+    # Stores an HTTP/2 connection's socket, state, writer, and flow
+    # controller in the reactor's per-connection maps.
+    #
+    # @param id [Integer] unique client identifier
+    # @param socket [TCPSocket] the connection socket
+    # @param state [Hash] initial connection state
+    # @param writer [Http2::Writer] per-connection frame writer
+    # @param flow_control [Http2::FlowControl] per-connection outbound flow controller
+    # @return [void]
+    #
+    # @rbs (id: Integer, socket: TCPSocket, state: Hash[Symbol, untyped], writer: untyped, flow_control: untyped) -> void
+    def attach_http2(id:, socket:, state:, writer:, flow_control:)
+      @id_to_socket[id] = socket
+      @socket_to_state[socket] = state
+      @id_to_writer[id] = writer
+      @id_to_flow_control[id] = flow_control
+    end
+
+    # Registers an attached socket for future reactor-driven reads.
+    #
+    # @param id [Integer] unique client identifier
+    # @return [void]
+    #
+    # @rbs (Integer id) -> void
+    def watch(id)
+      socket = @id_to_socket[id]
+      return unless socket
+
+      @queue << socket
+      @selector.wakeup
+    rescue ClosedQueueError
+      socket.close
+    end
+
     # Updates connection state for an HTTP/2 connection and re-registers
     # the socket for further reads.
     #
@@ -383,7 +420,8 @@ module Raptor
       end
 
       state = state.frozen? ? state.merge(buffer: buffer) : state.merge!(buffer: buffer)
-      @ractor_pool << Ractor.make_shareable(state)
+      pool = state[:protocol] == :http2 ? @http2_ractor_pool : @http1_ractor_pool
+      pool << Ractor.make_shareable(state)
     end
 
     # Cleans up a client connection by removing it from tracking and closing the socket.

data/lib/raptor/server.rb

@@ -206,18 +206,14 @@ module Raptor
       return unless perform_ssl_handshake(ssl_socket)
 
       if ssl_socket.alpn_protocol == H2_PROTOCOL
-        ssl_socket.write(@http2.initial_settings_frame) rescue nil
-
-        @reactor.add(
-          id: ssl_socket.object_id,
-          socket: ssl_socket,
-          remote_addr: remote_addr,
-          url_scheme: HTTPS_SCHEME,
-          protocol: :http2,
-          writer: @http2.create_writer,
-          flow_control: Http2::FlowControl.new
+        @http2.eager_accept(
+          ssl_socket,
+          ssl_socket.object_id,
+          @reactor,
+          @thread_pool,
+          remote_addr,
+          HTTPS_SCHEME
         )
-
         return
       end
 

data/lib/raptor/version.rb

@@ -2,5 +2,5 @@
 # frozen_string_literal: true
 
 module Raptor
-  VERSION = "0.15.1"
+  VERSION = "0.16.0"
 end

data/sig/generated/raptor/cluster.rbs

@@ -8,6 +8,10 @@ module Raptor
   class Cluster
     INHERITED_FDS_ENV: ::String
 
+    HTTP1_RACTOR_COUNT_CAP: ::Integer
+
+    HTTP2_RACTOR_COUNT_CAP: ::Integer
+
     # Creates and runs a cluster with the given options.
     #
     # @param options [Hash] cluster configuration options
@@ -16,7 +20,27 @@ module Raptor
     # @rbs (Hash[Symbol, untyped] options) -> void
     def self.run: (Hash[Symbol, untyped] options) -> void
 
-    @bpf_active: bool
+    # Returns the default number of HTTP/1.1 pipeline ractors per
+    # worker for the given worker count, rounded from the available
+    # processor count per worker and clamped to
+    # `[1, HTTP1_RACTOR_COUNT_CAP]`.
+    #
+    # @param worker_count [Integer] the configured worker count
+    # @return [Integer]
+    #
+    # @rbs (Integer worker_count) -> Integer
+    def self.default_http1_ractor_count: (Integer worker_count) -> Integer
+
+    # Returns the default number of HTTP/2 pipeline ractors per
+    # worker for the given worker count, rounded from the available
+    # processor count per worker and clamped to
+    # `[1, HTTP2_RACTOR_COUNT_CAP]`.
+    #
+    # @param worker_count [Integer] the configured worker count
+    # @return [Integer]
+    #
+    # @rbs (Integer worker_count) -> Integer
+    def self.default_http2_ractor_count: (Integer worker_count) -> Integer
 
     @server_port: Integer
 
@@ -56,6 +80,10 @@ module Raptor
 
     @worker_boot_timeout: Integer
 
+    @http2_options: Hash[Symbol, untyped]
+
+    @bpf_active: bool
+
     @resp_w: IO?
 
     @resp_r: IO?
@@ -94,8 +122,6 @@ module Raptor
 
     @app: untyped
 
-    @http2_options: Hash[Symbol, untyped]
-
     @http1_options: Hash[Symbol, untyped]
 
     @connection_options: Hash[Symbol, untyped]
@@ -104,7 +130,9 @@ module Raptor
 
     @thread_count: Integer
 
-    @ractor_count: Integer
+    @http2_ractor_count: Integer
+
+    @http1_ractor_count: Integer
 
     @worker_count: Integer
 
@@ -117,7 +145,6 @@ module Raptor
     # @option options [Integer] :socket_backlog kernel listen() queue depth for TCP/SSL listeners
     # @option options [Boolean] :drain_accept_queue whether to drain the kernel accept queue on shutdown
     # @option options [Integer] :workers number of worker processes
-    # @option options [Integer] :ractors number of ractors per worker process
     # @option options [Integer] :threads number of threads per worker process
     # @option options [#call] :app pre-built Rack application
     # @option options [String] :rackup path to Rack configuration file

data/sig/generated/raptor/http.rbs

@@ -51,8 +51,8 @@ module Raptor
     # @rbs (TCPSocket socket, Array[String] strings, ?timeout: Integer) -> void
     def self.socket_writev: (TCPSocket socket, Array[String] strings, ?timeout: Integer) -> void
 
-    # Returns a Ractor-safe proc that routes each pipeline task to the
-    # HTTP/1.x or HTTP/2 handler based on the state hash's `:protocol` key.
+    # Returns a Ractor-safe proc that parses an HTTP/1.x request from
+    # the state hash's buffered bytes.
     #
     # @param env_template [Hash] the Rack env template to seed each HTTP/1.x request with
     # @param max_body_size [Integer, nil] byte limit for HTTP/1.x request bodies, or nil for no limit

data/sig/generated/raptor/http2.rbs

@@ -192,6 +192,14 @@ module Raptor
     # @rbs () -> Writer
     def create_writer: () -> Writer
 
+    # Returns a Ractor-safe proc that parses HTTP/2 frames from the
+    # state hash's buffered bytes.
+    #
+    # @return [Proc]
+    #
+    # @rbs () -> ^(Hash[Symbol, untyped]) -> Hash[Symbol, untyped]
+    def parser_worker: () -> ^(Hash[Symbol, untyped]) -> Hash[Symbol, untyped]
+
     # Advances HTTP/2 frame parsing from the connection buffer, returning
     # updated connection state along with any outgoing protocol frames and
     # completed stream requests.
@@ -235,12 +243,28 @@ module Raptor
     # @rbs (Hash[Symbol, untyped] data, String buffer, Array[untyped] hpack_table, Hash[Integer, Hash[Symbol, untyped]] streams, Array[String] outgoing_frames, Array[Hash[Symbol, untyped]] completed_requests, Array[[Integer, Integer]] window_updates, Integer? peer_initial_window_size, Integer connection_window, bool preface_received, Integer last_client_stream_id, Hash[Symbol, untyped]? pending_headers, bool close_connection) -> Hash[Symbol, untyped]
     def self.build_result: (Hash[Symbol, untyped] data, String buffer, Array[untyped] hpack_table, Hash[Integer, Hash[Symbol, untyped]] streams, Array[String] outgoing_frames, Array[Hash[Symbol, untyped]] completed_requests, Array[[ Integer, Integer ]] window_updates, Integer? peer_initial_window_size, Integer connection_window, bool preface_received, Integer last_client_stream_id, Hash[Symbol, untyped]? pending_headers, bool close_connection) -> Hash[Symbol, untyped]
 
+    # Sends the server SETTINGS frame on a freshly negotiated HTTP/2
+    # connection, then eagerly reads and parses the first client frame
+    # batch, dispatching completed streams directly to the thread pool.
+    # Falls back to the reactor when no initial data is ready.
+    #
+    # @param socket [OpenSSL::SSL::SSLSocket] the connection socket
+    # @param id [Integer] unique client identifier
+    # @param reactor [Reactor] the reactor managing the connection
+    # @param thread_pool [AtomicThreadPool] thread pool for application processing
+    # @param remote_addr [String] client IP address
+    # @param url_scheme [String] "https"
+    # @return [void]
+    #
+    # @rbs (OpenSSL::SSL::SSLSocket socket, Integer id, Reactor reactor, AtomicThreadPool thread_pool, String remote_addr, String url_scheme) -> void
+    def eager_accept: (OpenSSL::SSL::SSLSocket socket, Integer id, Reactor reactor, AtomicThreadPool thread_pool, String remote_addr, String url_scheme) -> void
+
     # Handles a parsed HTTP/2 result. Writes outgoing frames, dispatches
     # completed stream requests to the thread pool, and eagerly consumes
     # further buffered frame batches before returning control to the
     # reactor.
     #
-    # @param result [Hash] the parsed result from the ractor pool
+    # @param result [Hash] the parsed result produced by {process_frames}
     # @param reactor [Reactor] the reactor managing the connection
     # @param thread_pool [AtomicThreadPool] thread pool for Rack app dispatch
     # @return [void]

data/sig/generated/raptor/reactor.rbs

@@ -42,35 +42,38 @@ module Raptor
 
     TIMEOUT_RESPONSE: ::String
 
-    @id_to_flow_control: Hash[Integer, untyped]
+    @thread_pool: untyped
 
-    @id_to_writer: Hash[Integer, untyped]
+    @http1_ractor_pool: untyped
 
-    @id_to_timeout: Hash[Integer, TimeoutClient]
+    @http2_ractor_pool: untyped
 
-    @socket_to_state: Hash[TCPSocket, Hash[Symbol, untyped]]
+    @first_data_timeout: Integer
 
-    @id_to_socket: Hash[Integer, TCPSocket]
+    @chunk_data_timeout: Integer
 
-    @timeouts: RedBlackTree[TimeoutClient]
+    @persistent_data_timeout: Integer
+
+    @selector: NIO::Selector
 
     @queue: Queue[TCPSocket]
 
-    @selector: NIO::Selector
+    @timeouts: RedBlackTree[TimeoutClient]
 
-    @persistent_data_timeout: Integer
+    @id_to_socket: Hash[Integer, TCPSocket]
 
-    @chunk_data_timeout: Integer
+    @socket_to_state: Hash[TCPSocket, Hash[Symbol, untyped]]
 
-    @first_data_timeout: Integer
+    @id_to_timeout: Hash[Integer, TimeoutClient]
 
-    @ractor_pool: untyped
+    @id_to_writer: Hash[Integer, untyped]
 
-    @thread_pool: untyped
+    @id_to_flow_control: Hash[Integer, untyped]
 
     # Creates a new Reactor instance.
     #
-    # @param ractor_pool [RactorPool] ractor pool for HTTP parsing
+    # @param http1_ractor_pool [RactorPool] ractor pool for HTTP/1.x parsing
+    # @param http2_ractor_pool [RactorPool] ractor pool for HTTP/2 parsing
     # @param thread_pool [AtomicThreadPool] thread pool for application processing
     # @param connection_options [Hash] per-connection timeout configuration
     # @option connection_options [Integer] :first_data_timeout timeout for initial data
@@ -79,8 +82,8 @@ module Raptor
     # @option http1_options [Integer] :persistent_data_timeout timeout for keep-alive idle connections
     # @return [void]
     #
-    # @rbs (untyped ractor_pool, untyped thread_pool, connection_options: Hash[Symbol, untyped], http1_options: Hash[Symbol, untyped]) -> void
-    def initialize: (untyped ractor_pool, untyped thread_pool, connection_options: Hash[Symbol, untyped], http1_options: Hash[Symbol, untyped]) -> void
+    # @rbs (untyped http1_ractor_pool, untyped http2_ractor_pool, untyped thread_pool, connection_options: Hash[Symbol, untyped], http1_options: Hash[Symbol, untyped]) -> void
+    def initialize: (untyped http1_ractor_pool, untyped http2_ractor_pool, untyped thread_pool, connection_options: Hash[Symbol, untyped], http1_options: Hash[Symbol, untyped]) -> void
 
     # Starts the reactor's main event loop in a new thread. Runs until
     # the registration queue is closed and drained.
@@ -159,6 +162,27 @@ module Raptor
     # @rbs (Integer id) -> untyped?
     def flow_control_for: (Integer id) -> untyped?
 
+    # Stores an HTTP/2 connection's socket, state, writer, and flow
+    # controller in the reactor's per-connection maps.
+    #
+    # @param id [Integer] unique client identifier
+    # @param socket [TCPSocket] the connection socket
+    # @param state [Hash] initial connection state
+    # @param writer [Http2::Writer] per-connection frame writer
+    # @param flow_control [Http2::FlowControl] per-connection outbound flow controller
+    # @return [void]
+    #
+    # @rbs (id: Integer, socket: TCPSocket, state: Hash[Symbol, untyped], writer: untyped, flow_control: untyped) -> void
+    def attach_http2: (id: Integer, socket: TCPSocket, state: Hash[Symbol, untyped], writer: untyped, flow_control: untyped) -> void
+
+    # Registers an attached socket for future reactor-driven reads.
+    #
+    # @param id [Integer] unique client identifier
+    # @return [void]
+    #
+    # @rbs (Integer id) -> void
+    def watch: (Integer id) -> void
+
     # Updates connection state for an HTTP/2 connection and re-registers
     # the socket for further reads.
     #

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: raptor
 version: !ruby/object:Gem::Version
-  version: 0.15.1
+  version: 0.16.0
 platform: ruby
 authors:
 - Joshua Young