raptor 0.16.0 → 0.16.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 02fe742ea31e44d742de9f0ed5b94cc53901d39e25b054fe0bd4affd14e169c1
-  data.tar.gz: 4279672bfd532f9bcadfb5ce81d85b8ba4921b8072e302bfc33bf74ce4609224
+  metadata.gz: 0e564259e8919bb36ded41097d9f3930fcf6ad2f2d090cd4bf0a2ef4cbf424b4
+  data.tar.gz: 1bf2f2e1077af1c2b61ba4b52bd5b13460bf0f27105a355b5dc01ff05e62b7b8
 SHA512:
-  metadata.gz: 283c078528cfd9cdfdfb795e4587a60607fa382d09efe1194330d5a9a6c7f319af94bc63a2da62396c7aba8484a0041260fcd70b0d82a5c324c7fd6b9221abc5
-  data.tar.gz: 9ee16f87805c340d17da270a81131f191b09500cbd622e3bd06bd32acff3f2ec215004e110187de1d01f6815fdcdfdf962c50c521398ce45e469358d3c155dd8
+  metadata.gz: 103f96d2f2490ea4bd1f844f29a8980deba5881e52b3c684ec2db963c0b0b0d426d616ce66ff22be93736550583891862502c1216663426249e015e1c68ab29d
+  data.tar.gz: e377a59417305334b255cf08be1c8c257971840d244b8b14b461ebbdfb857dc5a8cfbd6d37bee26ab2dc95642601bd1b7640100277c0b401f225fab66bbf8c77

data/CHANGELOG.md

@@ -1,10 +1,14 @@
 ## [Unreleased]
 
+## [0.16.1] - 2026-08-23
+
+- Drop the stale `Ractors=NUM` option from the Rackup handler
+
 ## [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
+- Nest the `ractors` config under `http1` and `http2`
 
 ## [0.15.1] - 2026-08-16
 

data/Dockerfile

@@ -18,8 +18,6 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
     && rm -rf /var/lib/apt/lists/*
 
 COPY --from=hey-builder /go/bin/hey /usr/local/bin/hey
-COPY --from=hey-builder /usr/local/go /usr/local/go
-ENV PATH=/usr/local/go/bin:${PATH}
 
 ENV BUNDLE_PATH=/workspace/.bundle
 ENV BUNDLE_APP_CONFIG=/workspace/.bundle

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 83654|Main|Main] Cluster initializing:
-[Raptor 83654|Main|Main] ├─ Version: 0.16.0
+[Raptor 83654|Main|Main] ├─ Version: 0.16.1
 [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
@@ -201,28 +201,28 @@ Worker 1 (phase 0): pid=91351, requests=1199, busy=1/3, backlog=0, booted, last_
 
 ## (Micro) Benchmarks
 
-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
-that does most of its work in Ruby with a few near-zero-cost cache hits.
+Raptor 0.16.1 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
+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 ±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.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   |
+| Protocol              | Workload | 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       | 3.21k req/s  | 63.20 ms   | 1.48k req/s | 131.00 ms | 117.7% higher | 51.8% 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 | 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  | 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  | 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       | -             | -            | 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.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;
+> 10 worker processes; Raptor and Puma run 3 threads per worker, Falcon runs unbounded fibers per worker;
 > 120 concurrent HTTP/1.1 client connections; 40 concurrent HTTP/2 client connections × 3 streams each
 
 See [bin/benchmark](bin/benchmark) for more details.

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 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.
+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 and Puma 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.
 

data/lib/rackup/handler/raptor.rb

@@ -43,7 +43,6 @@ module Rackup
           "Host=HOST"   => "Hostname to listen on (default: #{DEFAULT_OPTIONS[:Host]})",
           "Port=PORT"   => "Port to listen on (default: #{DEFAULT_OPTIONS[:Port]})",
           "Workers=NUM" => "Number of worker processes (default: available processor count)",
-          "Ractors=NUM" => "Number of pipeline ractors per worker (default: 1)",
           "Threads=NUM" => "Number of threads per worker (default: 3)",
           "Config=PATH" => "Load additional configuration from PATH"
         }

data/lib/raptor/cluster.rb

@@ -46,11 +46,11 @@ module Raptor
     # `[1, HTTP1_RACTOR_COUNT_CAP]`.
     #
     # @param worker_count [Integer] the configured worker count
+    # @param cores [Integer] the available processor count
     # @return [Integer]
     #
-    # @rbs (Integer worker_count) -> Integer
-    def self.default_http1_ractor_count(worker_count)
-      cores = Integer(Concurrent.available_processor_count)
+    # @rbs (Integer worker_count, ?cores: Integer) -> 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
 
@@ -60,11 +60,11 @@ module Raptor
     # `[1, HTTP2_RACTOR_COUNT_CAP]`.
     #
     # @param worker_count [Integer] the configured worker count
+    # @param cores [Integer] the available processor count
     # @return [Integer]
     #
-    # @rbs (Integer worker_count) -> Integer
-    def self.default_http2_ractor_count(worker_count)
-      cores = Integer(Concurrent.available_processor_count)
+    # @rbs (Integer worker_count, ?cores: Integer) -> 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
 

data/lib/raptor/version.rb

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

data/sig/generated/raptor/cluster.rbs

@@ -26,10 +26,11 @@ module Raptor
     # `[1, HTTP1_RACTOR_COUNT_CAP]`.
     #
     # @param worker_count [Integer] the configured worker count
+    # @param cores [Integer] the available processor count
     # @return [Integer]
     #
-    # @rbs (Integer worker_count) -> Integer
-    def self.default_http1_ractor_count: (Integer worker_count) -> Integer
+    # @rbs (Integer worker_count, ?cores: Integer) -> Integer
+    def self.default_http1_ractor_count: (Integer worker_count, ?cores: Integer) -> Integer
 
     # Returns the default number of HTTP/2 pipeline ractors per
     # worker for the given worker count, rounded from the available
@@ -37,10 +38,11 @@ module Raptor
     # `[1, HTTP2_RACTOR_COUNT_CAP]`.
     #
     # @param worker_count [Integer] the configured worker count
+    # @param cores [Integer] the available processor count
     # @return [Integer]
     #
-    # @rbs (Integer worker_count) -> Integer
-    def self.default_http2_ractor_count: (Integer worker_count) -> Integer
+    # @rbs (Integer worker_count, ?cores: Integer) -> Integer
+    def self.default_http2_ractor_count: (Integer worker_count, ?cores: Integer) -> Integer
 
     @server_port: Integer
 

metadata

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