Roundhouse benchmark results — campfire

1. Throughput across targets

Each endpoint is its own chart. Bars are log-scaled; raw req/sec is shown at the right.

/rooms/1

/rooms/1/messages

2. Lowerer dividend (ruby vs rails)

Same Ruby interpreter, same YJIT, same Puma — the only variable is whether the framework runtime is Rails or Roundhouse-emitted. The multiplier above each pair is the lift from the lowerer pipeline.

3. Cost economics (req/sec per GB of RSS)

Throughput normalized by memory footprint — req/sec divided by RSS in GB. This reorders the raw throughput charts above: targets with small working sets rise and high-RSS targets fall. Bars are log-scaled. How much the metric matters depends on the deployment shape — most on metered or serverless surfaces, least on bare metal with memory headroom.

/rooms/1

/rooms/1/messages

4. Memory footprint (PSS)

Max PSS observed across all endpoints, per target, sorted low to high.

PSS, not a sum of RSS: adding RSS across a process tree counts every shared page once per process, which reads high for a clustered lane and changes nothing for a single-process one. PSS divides each shared page among its sharers.

5. Latency (p50 / p99 at c=16)

Latencies are at c=16 concurrent connections; treat p50 as the median per-connection wait and p99 as the tail. Rows are ordered by measured median p50 across endpoints, fastest first.

All values in milliseconds. Lower is better.

6. Cold start

Time from exec to a server that answers, and to a signed-in /rooms/1 that comes back 200. Median of 3 boots per lane, all on the shape named in the row. The room page is the number that matters: it contains the first render, and on a fragment-cached lane a restart keeps the Redis its own Procfile runs in a separate process, so this is a warm-cache restart rather than a cold deployment.

Milliseconds. Lower is better. A deployed Rails lane boots a proxy, a Puma master and one worker per (processor_count × 0.666).ceil; the binary boots one process.

7. WebSocket connections

Sockets held open, subscribed to a room, then idled and driven: each lane pinned to the same cores, one client, exact delivered/expected frame counts. The idle column is the cost of holding connections that are doing nothing, which is what a chat deployment does most of the time. Read the fan-out latency against the per-room column — one message costs one write per subscriber in its room, so a room of 200 and a room of 50 are different workloads at the same socket count.

The driver is one thread reading every socket; its longest single reading pass in this run was 58 ms. A fan-out p99 near that number is the client's backlog rather than the server's fan-out.

Memory is PSS where the lane is multi-process, RSS otherwise. Lower is better in every column except frames, which must be exact.

8. What each lane rendered

One authenticated GET per lane per endpoint, captured before any load. Equal tag counts are what makes the throughput numbers above a comparison rather than two measurements.

Run-to-run stability

Each cell is timed 3 times and the charts above report the median run. This section reads per-run.json directly to show how far the individual runs strayed from it. Across all 16 cells the median run-to-run coefficient of variation in req/sec is 0.92% — the timed runs of a given cell agree to a fraction of a percent, so the reported medians aren't masking noise.

The 5 cells that vary by more than 3% are concentrated in the lowest-throughput cells, where a small absolute swing is a larger fraction of the rate; in 5 of them the first timed run is the slowest, consistent with residual warmup the fixed 20s warmup doesn't fully absorb:

req/sec per timed run; CV = standard deviation ÷ mean.

Generated 2026-09-06T00:25:00Z from summary.json.