raptor 0.20.0 → 0.20.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a59e1627962060bd0aa0a45f3b86eb1b1da18c77257b859f3861402a8012bfc2
-  data.tar.gz: 6d7b855e83333ccd6ed0b1af2d3eea2a6bf26d45edbd3431c55d6ec4f7df1c73
+  metadata.gz: c7d7d507ad52990de191f14ad645065b414e4d9b5f5d55f610626a0a1b3e6484
+  data.tar.gz: 7d06c53f9fc1e3531cc804dafccf28a715c1cb47924a69a19bd84e449164f935
 SHA512:
-  metadata.gz: d68cae66c278dcb69d0452c02a7ebc2f28e7a7e0bcf076000843a8b401690629270b95eec3cf6e733d7b75c0c99e69f07f30f8cfa89040ddbfa38613e4dfb542
-  data.tar.gz: 8e8aa0ce95ceab5627b2fa28d5b9d006960ed0d6a5817521d6fb4e4b82559848870f05734c1f95ba0967b41c0b6ad4958ba049be5041456ee1e308ac5c86838c
+  metadata.gz: 4759064e2e344d4d3f4669e62d04056df8d78bbc6b7fe8ba85881e6a8babb136d1f5ca5855606014e06fa43ac18d3d2946121b59bb98be1e8499f8024b4bb3bf
+  data.tar.gz: 439b5f3fce057ce5f2fe8ae8f1d7d47931a688e4ab7ac2f9a59ab9917c4939fb3b5b42e3898d216bb734f0122d4de1e4c9b029f7c71339bffa16e036a4a61838

data/CHANGELOG.md

@@ -1,5 +1,13 @@
 ## [Unreleased]
 
+## [0.20.2] - 2026-09-26
+
+- Close idle connections before reforking workers
+
+## [0.20.1] - 2026-09-26
+
+- Pass worker lifecycle settings through the Rackup handler
+
 ## [0.20.0] - 2026-08-30
 
 - Close connected control socket clients during shutdown

data/README.md

@@ -37,7 +37,7 @@ run proc { |_env| [200, { "content-type" => "text/plain" }, ["Hello, World!"]] }
 ```
 > bundle exec raptor -w 10 -t 3 hello_world.ru
 [Raptor 72876|Main|Main] Cluster initializing:
-[Raptor 72876|Main|Main] ├─ Version: 0.20.0
+[Raptor 72876|Main|Main] ├─ Version: 0.20.2
 [Raptor 72876|Main|Main] ├─ Ruby Version: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [arm64-darwin23]
 [Raptor 72876|Main|Main] ├─ Environment: development
 [Raptor 72876|Main|Main] ├─ Master PID: 72876
@@ -73,6 +73,9 @@ Also works with `rackup` and `rails server`:
 > bundle exec rails server -u raptor
 ```
 
+Rails apps using `SOLID_QUEUE_IN_PUMA` run jobs through `config/puma.rb`, which Raptor does not load. Run `bin/jobs` as
+a separately supervised process or container instead.
+
 ## Configuration
 
 Raptor accepts configuration via command-line flags, a Ruby config file, or both (CLI flags override config file
@@ -228,7 +231,7 @@ unbounded configured limit. The control server is read-only and currently expose
 
 ## (Micro) Benchmarks
 
-Raptor 0.20.0 vs Puma 8.0.2 vs Falcon 0.57.0 across two workload profiles. **IO-bound** is a GET endpoint that
+Raptor 0.20.2 vs Puma 8.0.2 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 that does
@@ -242,22 +245,22 @@ disabled, and both threaded servers allow 999 requests per HTTP/1.1 keep-alive c
 Each cell reports the median throughput and median p95 latency independently across 3 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 ±21.7% for throughput and ±31.6% for p95.
+((max - min) / 2 / median) between runs of a single cell was ±12.4% for throughput and ±16.5% for p95.
 
 | Protocol              | Workload | Raptor mode | Raptor req/s | Raptor p95 | Puma req/s  | Puma p95  | vs Puma req/s | vs Puma p95  | Falcon req/s | Falcon p95 | vs Falcon req/s | vs Falcon p95 |
 | --------------------- | -------- | ----------- | ------------ | ---------- | ----------- | --------- | ------------- | ------------ | ------------ | ---------- | --------------- | ------------- |
-| HTTP/1.1              | IO       | Fixed       | 2.81k req/s  | 82.40 ms   | 1.51k req/s | 124.90 ms | 86.5% higher  | 34.0% lower  | 11.81k req/s | 14.70 ms   | 76.2% lower     | 460.5% higher |
-| HTTP/1.1              | IO       | Scaling     | 7.17k req/s  | 30.50 ms   | 1.51k req/s | 124.90 ms | 375.3% higher | 75.6% lower  | 11.81k req/s | 14.70 ms   | 39.2% lower     | 107.5% higher |
-| HTTP/1.1              | CPU      | Fixed       | 7.20k req/s  | 37.00 ms   | 8.59k req/s | 21.00 ms  | 16.1% lower   | 76.2% higher | 6.51k req/s  | 28.10 ms   | 10.6% higher    | 31.7% higher  |
-| HTTP/1.1              | CPU      | Scaling     | 6.91k req/s  | 38.60 ms   | 8.59k req/s | 21.00 ms  | 19.6% lower   | 83.8% higher | 6.51k req/s  | 28.10 ms   | 6.1% higher     | 37.4% higher  |
-| HTTP/1.1 (keep-alive) | IO       | Fixed       | 2.81k req/s  | 50.60 ms   | 1.46k req/s | 109.90 ms | 92.0% higher  | 54.0% lower  | 6.33k req/s  | 27.60 ms   | 55.6% lower     | 83.3% higher  |
-| HTTP/1.1 (keep-alive) | IO       | Scaling     | 7.71k req/s  | 24.20 ms   | 1.46k req/s | 109.90 ms | 426.9% higher | 78.0% lower  | 6.33k req/s  | 27.60 ms   | 21.8% higher    | 12.3% lower   |
-| HTTP/1.1 (keep-alive) | CPU      | Fixed       | 5.90k req/s  | 33.10 ms   | 8.27k req/s | 22.70 ms  | 28.7% lower   | 45.8% higher | 6.86k req/s  | 32.90 ms   | 14.0% lower     | 0.6% higher   |
-| HTTP/1.1 (keep-alive) | CPU      | Scaling     | 5.96k req/s  | 34.90 ms   | 8.27k req/s | 22.70 ms  | 28.0% lower   | 53.7% higher | 6.86k req/s  | 32.90 ms   | 13.2% lower     | 6.1% higher   |
-| HTTP/2                | IO       | Fixed       | 1.23k req/s  | 146.17 ms  | N/A         | N/A       | -             | -            | 6.57k req/s  | 27.30 ms   | 81.3% lower     | 435.4% higher |
-| HTTP/2                | IO       | Scaling     | 6.53k req/s  | 28.69 ms   | N/A         | N/A       | -             | -            | 6.57k req/s  | 27.30 ms   | 0.6% lower      | 5.1% higher   |
-| HTTP/2                | CPU      | Fixed       | 6.25k req/s  | 32.60 ms   | N/A         | N/A       | -             | -            | 8.39k req/s  | 26.63 ms   | 25.5% lower     | 22.4% higher  |
-| HTTP/2                | CPU      | Scaling     | 5.64k req/s  | 32.63 ms   | N/A         | N/A       | -             | -            | 8.39k req/s  | 26.63 ms   | 32.8% lower     | 22.5% higher  |
+| HTTP/1.1              | IO       | Fixed       | 2.90k req/s  | 81.10 ms   | 1.41k req/s | 141.50 ms | 105.8% higher | 42.7% lower  | 12.26k req/s | 14.00 ms   | 76.4% lower     | 479.3% higher |
+| HTTP/1.1              | IO       | Scaling     | 6.24k req/s  | 36.20 ms   | 1.41k req/s | 141.50 ms | 343.2% higher | 74.4% lower  | 12.26k req/s | 14.00 ms   | 49.1% lower     | 158.6% higher |
+| HTTP/1.1              | CPU      | Fixed       | 7.21k req/s  | 37.90 ms   | 8.20k req/s | 23.20 ms  | 12.1% lower   | 63.4% higher | 5.28k req/s  | 35.00 ms   | 36.6% higher    | 8.3% higher   |
+| HTTP/1.1              | CPU      | Scaling     | 6.04k req/s  | 41.60 ms   | 8.20k req/s | 23.20 ms  | 26.4% lower   | 79.3% higher | 5.28k req/s  | 35.00 ms   | 14.4% higher    | 18.9% higher  |
+| HTTP/1.1 (keep-alive) | IO       | Fixed       | 2.35k req/s  | 73.50 ms   | 1.37k req/s | 124.50 ms | 71.2% higher  | 41.0% lower  | 6.35k req/s  | 27.50 ms   | 63.0% lower     | 167.3% higher |
+| HTTP/1.1 (keep-alive) | IO       | Scaling     | 7.83k req/s  | 23.20 ms   | 1.37k req/s | 124.50 ms | 470.1% higher | 81.4% lower  | 6.35k req/s  | 27.50 ms   | 23.2% higher    | 15.6% lower   |
+| HTTP/1.1 (keep-alive) | CPU      | Fixed       | 7.14k req/s  | 28.60 ms   | 7.85k req/s | 24.50 ms  | 9.1% lower    | 16.7% higher | 5.56k req/s  | 41.60 ms   | 28.4% higher    | 31.2% lower   |
+| HTTP/1.1 (keep-alive) | CPU      | Scaling     | 7.48k req/s  | 26.20 ms   | 7.85k req/s | 24.50 ms  | 4.8% lower    | 6.9% higher  | 5.56k req/s  | 41.60 ms   | 34.5% higher    | 37.0% lower   |
+| HTTP/2                | IO       | Fixed       | 1.13k req/s  | 174.70 ms  | N/A         | N/A       | -             | -            | 7.18k req/s  | 26.37 ms   | 84.3% lower     | 562.5% higher |
+| HTTP/2                | IO       | Scaling     | 6.48k req/s  | 29.15 ms   | N/A         | N/A       | -             | -            | 7.18k req/s  | 26.37 ms   | 9.7% lower      | 10.6% higher  |
+| HTTP/2                | CPU      | Fixed       | 6.31k req/s  | 31.74 ms   | N/A         | N/A       | -             | -            | 6.85k req/s  | 51.60 ms   | 7.9% lower      | 38.5% lower   |
+| HTTP/2                | CPU      | Scaling     | 6.70k req/s  | 31.91 ms   | N/A         | N/A       | -             | -            | 6.85k req/s  | 51.60 ms   | 2.2% lower      | 38.2% lower   |
 
 > ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [aarch64-linux]
 > 10 worker processes; fixed Raptor and Puma run 3 threads per worker; scaling Raptor starts at 3 with no fixed limit;

data/docs/brisrails-talk.md

@@ -1087,10 +1087,10 @@ The bit that matters most in practice:
 
 The pool starts at `threads` and scales automatically when more threads would help.
 
-- <big>When scaling is enabled, a native CRuby thread hook measures time running, blocked outside the GVL, and waiting for the GVL</big>
+- <big>A native CRuby thread hook measures time running, blocked outside the GVL, and waiting for the GVL</big>
 - <big>The queue has to stay non-empty, and every current worker has to be active</big>
 - <big>Blocked time has to exceed half of worker time</big>
-- <big>The workers have to use less than half of one CPU during the sample</big>
+- <big>GVL wait has to stay below two percent</big>
 - <big>Only then does the pool add a temporary thread</big>
 - <big>When the queue drains, temporary threads leave and the pool returns to `threads`</big>
 
@@ -1708,7 +1708,7 @@ flowchart TB
 - <big>Every worker inherits the mapping</big>
 - <big>Each worker writes a 49-byte slot every second: pid, phase, requests, backlog, busy and available threads, boot time, checkin time, booted flag</big>
 - <big>Master reads the whole region directly. No JSON. No pipe drain. No signal.</big>
-- <big>`bundle exec raptor stats` reads the master's JSON stats file and prints each worker's status</big>
+- <big>`bundle exec raptor stats` prints the region as JSON, essentially instantly</big>
 - <big>An optional read-only Unix socket exposes the cluster snapshot at `GET /stats` for monitoring</big>
 
 Wrapped in a small C extension I wrote: **`mmap-ruby`**.
@@ -2243,10 +2243,10 @@ 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 HTTP/1.1**: Scaling handles far more requests than the fixed pool. It closes much of Falcon's lead without keep-alive and leads it with keep-alive.</big>
-- <big>**CPU-bound HTTP/1.1**: Scaling stays close to the fixed pool instead of adding threads while Ruby execution is the bottleneck. Puma leads both Raptor modes in the current run.</big>
+- <big>**IO-bound HTTP/1.1**: Scaling lifts Raptor from 3.11k to 8.63k req/s without keep-alive and from 3.21k to 9.43k with it. Falcon wins the first; Raptor wins the second.</big>
+- <big>**CPU-bound HTTP/1.1**: Fixed and scaling Raptor are effectively identical. Puma leads by 5% without keep-alive and less than 1% with it; Raptor leads Falcon.</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**: Scaling brings Raptor close to Falcon on the IO workload. Falcon leads the CPU workload in the current run.</big>
+- <big>**HTTP/2**: Scaling lifts Raptor from 1.14k to 4.46k req/s on IO and narrows Falcon's CPU-throughput lead from 27% to 14%. Falcon still leads throughput; Raptor has the lower CPU p95.</big>
 - <big>**Variance**: HTTP/1.1 is stable. HTTP/2 is noisy enough that I treat it as direction, not a precise ranking.</big>
 
 Different workloads, different winners. That's fine.

data/docs/raptor-vs-puma.md

@@ -1,6 +1,6 @@
 # Raptor vs Puma: A Design Comparison
 
-Raptor is a Ruby web server built around Ractor-parallel protocol pipelines, a lock-free app thread pool, and an opinionated cluster architecture. Its benchmark against Puma and Falcon shows how differently the three servers respond to IO-heavy and CPU-heavy work. Raptor also speaks HTTP/2 natively, which Puma does not. This document explains how the Puma and Raptor designs move requests and where each trade-off shows up.
+Raptor is a Ruby web server built around Ractor-parallel protocol pipelines, a lock-free app thread pool, and an opinionated cluster architecture. Against the latest Puma release on the same hardware, it leads clearly on the IO-heavy HTTP/1.1 benchmark and lands within a few percent on CPU-heavy throughput, while Falcon's fibers remain the strongest fit for highly concurrent IO. Raptor also speaks HTTP/2 natively, which Puma does not. This document explains how those designs move requests and where each trade-off shows up.
 
 ## Why this document exists
 
@@ -26,9 +26,9 @@ Two workload profiles are measured. **IO-bound** is a GET endpoint that does 5 t
 
 Each cell in the table reports the median throughput and median p95 latency independently across 3 runs, and every run boots a fresh server process so state cannot accumulate across measurements. Both Raptor modes are compared with both servers: fixed mode is the like-for-like comparison with Puma, while scaling mode tests whether adaptive OS threads can close the IO-concurrency gap with Falcon's much cheaper fibers. Rather than pin every number into this document (they drift with Ruby versions and hardware), the shape of the result is what matters.
 
-- On IO-bound HTTP/1.1, both Raptor modes lead Puma. Scaling handles far more requests than the fixed pool, closes much of Falcon's lead without keep-alive, and leads Falcon with keep-alive.
-- On CPU-bound HTTP/1.1, Puma leads both Raptor modes in the current run. Fixed and scaling Raptor stay close to each other, which is the important guardrail: the pool gets its IO gains without adding threads while Ruby execution is the bottleneck.
-- On HTTP/2, Raptor and Falcon both implement it; Puma doesn't. Scaling brings Raptor close to Falcon on the IO profile, while Falcon leads the CPU profile in the current run. HTTP/2 also varies substantially more between runs in this benchmark, so those medians deserve less confidence than the stable HTTP/1.1 results.
+- On IO-bound HTTP/1.1, fixed Raptor delivers a little over twice Puma's throughput with less than half its p95 latency. Scaling lifts Raptor to 8.63k req/s without keep-alive and 9.43k with it: still 29.3% behind Falcon on fresh connections, but 51.3% ahead with keep-alive.
+- On CPU-bound HTTP/1.1, fixed and scaling Raptor are effectively identical. Puma leads by 5.0% without keep-alive and 0.7% with it, while both Raptor modes lead Falcon. This is the intended result: the pool gets its IO gains without trading away CPU throughput.
+- On HTTP/2, Raptor and Falcon both implement it; Puma doesn't. Scaling raises Raptor's IO throughput from 1.14k to 4.46k req/s, though it remains 30.3% behind Falcon. On the CPU profile it narrows Falcon's throughput lead from 26.9% to 14.2% while keeping a lower p95. HTTP/2 also varies substantially more between runs in this benchmark, so those medians deserve less confidence than the stable HTTP/1.1 results.
 
 The rest of this doc explains why the shape looks like that.
 
@@ -195,7 +195,7 @@ Two kinds of restart are supported:
 
 Systemd socket activation is a native feature and slots straight into this model. When the service unit is `Type=notify` and there is a socket unit, systemd passes listener FDs via `LISTEN_FDS`. Raptor detects this exactly the same way it detects a hot restart handoff: `Systemd.listen_fds` returns the FDs, the binder is built from them, and the master sends `READY=1` back to systemd once workers have booted. `STOPPING=1` and `RELOADING=1` fire on the corresponding lifecycle events.
 
-Routine worker monitoring does not use pipes. Every worker writes its stats (pid, request count, backlog, busy and available threads, last checkin timestamp, booted flag) into a fixed-size slot in an anonymous shared-memory region allocated with `mmap-ruby` before the fork. The master reads the region directly. There is no serialisation, pipe drain, or signal to trigger the read; it is 49 bytes per worker of native memory. The master writes the same data to the configured JSON stats file, which `bundle exec raptor stats` reads and formats. Refork coordination is separate and does use a pair of pipes between the master and seed.
+Routine worker monitoring does not use pipes. Every worker writes its stats (pid, request count, backlog, busy and available threads, last checkin timestamp, booted flag) into a fixed-size slot in an anonymous shared-memory region allocated with `mmap-ruby` before the fork. The master reads the region directly. There is no serialisation, pipe drain, or signal to trigger the read; it is 49 bytes per worker of native memory. `bundle exec raptor stats` prints a JSON snapshot. Refork coordination is separate and does use a pair of pipes between the master and seed.
 
 On Linux, `cpu_affinity: true` pins each worker to a distinct CPU via `sched_setaffinity` when the worker count fits within the process's allowed CPU set, so it stays on one core and its L1/L2 caches stay warm. It is off by default because an allowed CPU in a container is not necessarily dedicated to that container. When workers outnumber available CPUs the pin is skipped and the kernel scheduler manages placement.
 
@@ -242,7 +242,7 @@ Raptor always runs an HTTP/1.1 pool because every binding supports HTTP/1.1. It
 
 **Why a custom thread pool.** The `AtomicThreadPool` in `atomic-ruby` (another one of my libraries) is backed by an `AtomicQueue`. The queue is a Michael-Scott multi-producer, multi-consumer FIFO: a singly linked list with a dummy sentinel and atomic head and tail pointers. Producers append nodes at the tail; consumers advance the head. Both operations are O(1) and make progress through compare-and-swap rather than a queue-wide mutex. Separate atoms track queue size and active app threads for backpressure.
 
-The pool starts at `threads` and scales without a fixed limit by default. Set `max_threads` to cap its growth, or set it to the same value as `threads` to keep the pool fixed. When growth is enabled, a native CRuby thread-event hook measures how much active workers spend running, blocked outside the GVL, and waiting to acquire it. The pool only adds a temporary thread after work has remained queued across several samples, every current worker is active, blocked time is above half of measured worker time, and the workers have used less than half of one CPU during the sample. That last check matters: adding threads helps when existing threads are asleep in database or network calls, but hurts when CPU-bound Ruby threads are already fighting over the GVL. Temporary threads retire after the queue has remained empty for a second.
+The pool starts at `threads` and scales without a fixed limit by default. Set `max_threads` to cap its growth, or set it to the same value as `threads` to keep the pool fixed. A native CRuby thread-event hook measures how much active workers spend running, blocked outside the GVL, and waiting to acquire it. The pool only adds a temporary thread after work has remained queued across several samples, every current worker is active, blocked time is above half of measured worker time, and GVL wait is below two percent. That last check matters: adding threads helps when existing threads are asleep in database or network calls, but hurts when CPU-bound Ruby threads are already fighting over the GVL. Temporary threads retire after the queue has remained empty for a second.
 
 The pool still uses an `AtomicConditionVariable` under the hood to park idle threads (idle threads call `Thread.stop` and get woken with `Thread#wakeup`; there is no spinning), because idle spinning would waste CPU. The difference from Puma's pool is not "no locks anywhere" but rather "the hot path (enqueue and dequeue when the queue has items) is lock-free". Once every worker is busy the mechanics look similar; where things diverge is under contention when you have many threads all trying to push and pop.
 
@@ -580,7 +580,7 @@ In this timing, both servers keep Request 2 inline and return Request 3 to the r
 
 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. Fixed Raptor and Puma cap application execution at three threads per worker. Falcon spawns a fiber per connection and cooperatively yields on every sleep, so many more client connections can make progress while others wait. That advantage gives Falcon the clear lead over both fixed-thread servers, especially without keep-alive.
 
-Scaling Raptor starts with the same three threads, then adds temporary threads while work is queued and the active threads are mostly blocked outside the GVL. In the current results that raises throughput substantially, closes much of Falcon's lead without keep-alive, and puts Raptor ahead with keep-alive. The benchmark reports fixed and scaling Raptor separately rather than hiding that difference in one result.
+Scaling Raptor starts with the same three threads, then adds temporary threads while work is queued and the active threads are mostly blocked outside the GVL. In the current results that raises throughput from 3.11k to 8.63k req/s without keep-alive, and from 3.21k to 9.43k with it. Falcon still leads the first by 29.3%; scaling Raptor leads the second by 51.3%. The benchmark reports fixed and scaling Raptor separately rather than hiding that difference in one result.
 
 Between the thread-based servers, Raptor holds a clear lead over Puma on both throughput and p95. Its eager paths, explicit admission control, response batching, and app pool are all designed to reduce coordination, but the benchmark does not isolate enough variables to assign the result to one of them.
 
@@ -590,9 +590,9 @@ Real applications that spend most of their time waiting on a database or an upst
 
 On the CPU-bound benchmark profile, each POST request accepts a small JSON body and builds a JSON response in 3 to 5 chunks totalling 450 to 1500 items, with sub-100µs sleeps between chunks. It's roughly 95% CPU by wall time, so fibers can't multiplex their way to an advantage. The CPU work happens under a single Ruby VM regardless of concurrency model.
 
-**Without keep-alive**, every request opens a fresh TCP connection, gets parsed, dispatched, served, and closes. Puma leads both Raptor modes in the current run. Fixed and scaling Raptor stay close to each other relative to the gain scaling produces on the IO workload, which shows that the pool is not adding threads freely when Ruby execution is already the bottleneck.
+**Without keep-alive**, every request opens a fresh TCP connection, gets parsed, dispatched, served, and closes. Puma leads fixed Raptor by 5.0% on throughput and has the lower p95; Raptor still leads Falcon. Fixed and scaling Raptor both deliver 8.22k req/s. The Puma/Raptor gap is small enough that neither architecture has overwhelmed the CPU cost of the Rack workload.
 
-**With keep-alive**, Puma again leads both Raptor modes in the current run, while Raptor and Falcon are closer. As above, fixed and scaling Raptor stay close enough that the result is more useful as a guardrail than a victory claim: adaptive scaling provides the IO-bound gains without treating CPU pressure as a reason to keep creating threads.
+**With keep-alive**, Puma leads fixed Raptor by 0.7% on throughput, while Raptor's p95 is 0.4ms lower; Raptor leads Falcon on both. Fixed and scaling Raptor both deliver 8.49k req/s, with scaling p95 matching Puma. The result is more useful as a guardrail than a victory claim: adaptive scaling provides the IO-bound gains without hurting this CPU-bound profile.
 
 ### HTTP/2, when it matters
 
@@ -600,7 +600,7 @@ Puma doesn't implement HTTP/2, and most Rails production terminates HTTP/2 at ng
 
 Where Raptor's HTTP/2 support does matter is the all-Ruby stack: no proxy in front, TLS terminated at the app, and browsers or API clients speaking h2 directly to it. In that setup, Puma negotiates HTTP/1.1 instead, so the app-server connection does not get HTTP/2 multiplexing or HPACK header compression.
 
-Falcon also speaks HTTP/2 natively, so it's the interesting comparison there rather than Puma. In the current run, scaling brings Raptor close to Falcon on the IO profile, while Falcon leads the CPU profile. The h2 samples vary substantially more than the h1 samples, so these results establish broad shape rather than a precise ranking.
+Falcon also speaks HTTP/2 natively, so it's the interesting comparison there rather than Puma. On the CPU profile, scaling narrows Raptor's throughput gap from 26.9% to 14.2% and improves its p95 advantage from 12.3% to 21.3%. On IO, scaling raises Raptor from 1.14k to 4.46k req/s, but remains 30.3% behind Falcon. The h2 samples vary substantially more than the h1 samples, so these results establish broad shape rather than a precise ranking.
 
 The benchmark's h2 listener uses TLS, while Raptor's BPF reuseport path only wraps plain TCP listeners. BPF dispatch therefore cannot explain the h2 variance. With 40 physical connections spread across 10 workers, each carrying three streams, placement and per-connection scheduling have coarse granularity; more instrumentation is needed before assigning the variance to a specific mechanism.
 

data/lib/rackup/handler/raptor.rb

@@ -100,6 +100,11 @@ module Rackup
         result[:worker_timeout] = (config[:worker_timeout] || cli_defaults[:worker_timeout]).to_i
         result[:worker_drain_timeout] = (config[:worker_drain_timeout] || cli_defaults[:worker_drain_timeout]).to_i
         result[:worker_shutdown_timeout] = (config[:worker_shutdown_timeout] || cli_defaults[:worker_shutdown_timeout]).to_i
+        result[:refork_after] = config.fetch(:refork_after, cli_defaults[:refork_after])
+        result[:before_fork] = config.fetch(:before_fork, cli_defaults[:before_fork])
+        result[:before_worker_boot] = config.fetch(:before_worker_boot, cli_defaults[:before_worker_boot])
+        result[:before_worker_shutdown] = config.fetch(:before_worker_shutdown, cli_defaults[:before_worker_shutdown])
+        result[:before_refork] = config.fetch(:before_refork, cli_defaults[:before_refork])
         result[:stats_file] = config.key?(:stats_file) ? config[:stats_file] : cli_defaults[:stats_file]
         result[:control_url] = config[:control_url] if config.key?(:control_url)
         result[:pid_file] = config[:pid_file] if config.key?(:pid_file)

data/lib/raptor/control_server.rb

@@ -5,22 +5,17 @@ require "json"
 require "socket"
 require "uri"
 
-require "atomic-ruby/atom"
-require "atomic-ruby/atomic_boolean"
-
 module Raptor
   # Serves cluster statistics over a Unix socket.
   #
   class ControlServer
-    MAX_REQUEST_SIZE = 16 * 1024
-    REQUEST_TIMEOUT = 1
-
     # @rbs @path: String
     # @rbs @stats: ^() -> Hash[Symbol, untyped]
     # @rbs @server: UNIXServer?
-    # @rbs @client: Atom
+    # @rbs @client: UNIXSocket?
     # @rbs @thread: Thread?
-    # @rbs @running: AtomicBoolean
+    # @rbs @running: bool
+    # @rbs @mutex: Mutex
 
     # Creates a control server for `url` without binding it.
     #
@@ -37,9 +32,10 @@ module Raptor
       @path = uri.path
       @stats = stats
       @server = nil
-      @client = Atom.new(nil)
+      @client = nil
       @thread = nil
-      @running = AtomicBoolean.new(false)
+      @running = false
+      @mutex = Mutex.new
     end
 
     # Binds the Unix socket.
@@ -58,7 +54,7 @@ module Raptor
     #
     # @rbs () -> void
     def start
-      @running.make_true
+      @running = true
       owner_pid = Process.pid
       at_exit { File.delete(@path) rescue nil if Process.pid == owner_pid }
 
@@ -75,9 +71,11 @@ module Raptor
     #
     # @rbs () -> void
     def shutdown
-      @running.make_false
-      @server&.close
-      close_client
+      @running = false
+      @mutex.synchronize do
+        @server&.close
+        @client&.close
+      end
       @thread&.join
       File.delete(@path) rescue nil
     end
@@ -98,30 +96,27 @@ module Raptor
 
     # @rbs () -> void
     def serve
-      while @running.true?
+      while @running
         readable, = IO.select([@server], nil, nil, 1)
         next unless readable
 
-        client = @server.accept_nonblock(exception: false)
-        next unless client.is_a?(UNIXSocket)
-
-        @client.swap { client }
-        unless @running.true?
-          close_client
-          break
+        @mutex.synchronize do
+          client = @server.accept_nonblock(exception: false)
+          @client = client if client.is_a?(UNIXSocket)
         end
-
-        handle(client)
+        handle(@client) if @client
       end
     rescue IOError, Errno::EBADF
     end
 
     # @rbs (UNIXSocket client) -> void
     def handle(client)
-      request = read_request(client)
-      return unless request
+      request_line = client.gets
+      while line = client.gets
+        break if line == "\r\n"
+      end
 
-      if request.start_with?("GET /stats ")
+      if request_line&.start_with?("GET /stats ")
         body = JSON.generate(@stats.call)
         client.write("HTTP/1.0 200 OK\r\nContent-Type: application/json\r\nContent-Length: #{body.bytesize}\r\n\r\n#{body}")
       else
@@ -129,36 +124,8 @@ module Raptor
       end
     rescue IOError, SystemCallError
     ensure
-      close_client
-    end
-
-    # @rbs (UNIXSocket client) -> String?
-    def read_request(client)
-      request = String.new
-      deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + REQUEST_TIMEOUT
-
-      loop do
-        return request if request.include?("\r\n\r\n")
-        return if request.bytesize >= MAX_REQUEST_SIZE
-
-        timeout = deadline - Process.clock_gettime(Process::CLOCK_MONOTONIC)
-        return if timeout <= 0 || !client.wait_readable(timeout)
-
-        chunk = client.read_nonblock(MAX_REQUEST_SIZE - request.bytesize, exception: false)
-        return unless chunk.is_a?(String)
-
-        request << chunk
-      end
-    end
-
-    # @rbs () -> void
-    def close_client
-      client = nil
-      @client.swap do |current|
-        client = current
-        nil
-      end
-      client&.close
+      client.close rescue nil
+      @mutex.synchronize { @client = nil }
     end
   end
 end

data/lib/raptor/reactor.rb

@@ -145,6 +145,13 @@ module Raptor
           end
         end
 
+        @id_to_socket.each_value { |socket| socket.close rescue nil }
+        @id_to_socket.clear
+        @socket_to_state.clear
+        @id_to_timeout.clear
+        @id_to_writer.clear
+        @id_to_flow_control.clear
+        @timeouts.clear!
         @selector.close
       end
     end

data/lib/raptor/version.rb

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

data/sig/generated/raptor/control_server.rbs

@@ -3,21 +3,19 @@
 module Raptor
   # Serves cluster statistics over a Unix socket.
   class ControlServer
-    MAX_REQUEST_SIZE: untyped
-
-    REQUEST_TIMEOUT: ::Integer
+    @path: String
 
-    @running: AtomicBoolean
+    @stats: ^() -> Hash[Symbol, untyped]
 
-    @thread: Thread?
+    @server: UNIXServer?
 
-    @client: Atom
+    @client: UNIXSocket?
 
-    @server: UNIXServer?
+    @thread: Thread?
 
-    @stats: ^() -> Hash[Symbol, untyped]
+    @running: bool
 
-    @path: String
+    @mutex: Mutex
 
     # Creates a control server for `url` without binding it.
     #
@@ -60,11 +58,5 @@ module Raptor
 
     # @rbs (UNIXSocket client) -> void
     def handle: (UNIXSocket client) -> void
-
-    # @rbs (UNIXSocket client) -> String?
-    def read_request: (UNIXSocket client) -> String?
-
-    # @rbs () -> void
-    def close_client: () -> void
   end
 end

metadata

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