Roundhouse benchmark results — campfire

Methodology. AMD Ryzen 5 3600 6-Core Processor, 6c/12t, 3.6 GHz, boost disabled, governor=performance, 63 GB RAM, Ubuntu 24.04.5 LTS. Toolchains pinned via mise. Harness: scripts/bench-campfire — workers=1, c=16, 3×20s runs per cell after 20s warmup (jruby 60s, truffleruby 120s, rails-truffleruby 240s — those lanes plateau later); the median of the 3 runs is reported (the run-to-run spread is in the stability section below). Quiet machine throughout. The managed-heap cells run under a fixed heap budget so their RSS is comparable to the other cells' working sets rather than the runtime's default share of host RAM: the JVM cell via -Xmx=-Xms (jruby 1g), and the TruffleRuby cells via --vm.Xmx (truffleruby 1g, rails-truffleruby 2g). Full hardware, toolchain versions, and the exact invocation are in the environment appendix below.

rails and the emit lanes BOTH serve campfire's message fragments from a cache — Rails from Redis (cached: true), the emitted tree from its own process-local store — so the deployed lanes compare like with like. Until 2026-09-07 the emit had no fragment cache and this page carried a rails-nocache column so the comparison was renderer against renderer rather than emit against Redis; that column is now a diagnostic, requested by name, and is not published here.

The deployed lanes are what each project would run on this box. rails is once-campfire AS ITS OWN DOCKERFILE RUNS IT: Thruster in front of Puma, (processor_count * 0.666).ceil workers x 5 threads from its own config/puma.rb, jemalloc preloaded, resque-pool alongside. ruby is the CRuby emit in the same Puma shape with the same allocator; spinel is the binary with its workers autodetected.

ruby IS A MATCHED-SHAPE RUNTIME COMPARISON, NOT A DEPLOYMENT CLAIM. It runs Rails' worker count so the number is not a core count, but the emitted tree's Action Cable registry and its job queue are both in-process: at more than one worker a broadcast reaches only the subscribers sharing a process with the poster, so campfire could not actually run this shape. Its deployable CRuby shape today is one worker, which is the ruby-1p row. Cross-worker pubsub would go behind the existing Broadcasts.set_transport seam and is not implemented. spinel needs none of this: one process, green threads, one shared registry — which is why it is the emit lane the WebSocket tier can measure at its full worker count.

The -1p lanes are the diagnostic, and what they pin is ONE CPU rather than one process — CRuby needs a process per core because of the GVL, while the binary is a single process either way and varies its OS worker count instead (SPINEL_WORKERS=1). They exist because a deployed number cannot say WHY it landed where it did, so these rows separate "their runtime is slower" from "we gave them fewer cores". Read them per lane-family: ruby and spinel differ from their -1p twins in worker count and NOTHING else, but rails-1p also sheds Thruster and resque-pool, so its delta is not attributable to cores alone.

Known omissions, stated rather than discovered: the WebSocket phase's rails lane runs Puma with campfire's worker count and its allocator but WITHOUT Thruster and resque-pool, and no lane terminates TLS.

MEMORY IS THE SERVER PROCESS TREE, and the rails lanes keep part of themselves outside it. Their fragment cache, their Action Cable adapter and Resque's queue all live in a system Redis (~16 MB RSS here) that is nobody's descendant and so is in no lane's number — while the emit lanes hold their equivalent inside the measured process. Throughput is unaffected: the rails lanes pay for every Redis round trip in their req/s. Counted for rails: Thruster, the Puma master and its workers, resque-pool and its workers.

The CRuby fragment store is PER PROCESS, so the ruby lane holds one cache per worker where spinel holds one for the whole binary.

jruby and truffleruby are the SAME emitted tree under another Ruby — jruby re-emitted with --target jruby (identical app and framework; SQLite over JDBC instead of the C extension), truffleruby the ruby tree unmodified with a bundle TruffleRuby compiled itself. Both are ONE process, because neither can fork: jruby with a Puma thread per hardware thread (no GVL — measured on this box, 12 threads beat 40 by 19%), truffleruby in the ruby-1p shape of one process × 5 threads (it keeps a GIL for Ruby code, and 4 threads beat 40 by 56%). That makes jruby the one multi-core CRuby-family row campfire could actually deploy: the JVM has no GVL, and one process means one Action Cable registry, one fragment cache and one job queue shared by every thread — the exact property the eight-worker ruby row lacks. Heaps are pinned at 1 GB (512 MB, the blog's budget, holds the tree but costs it 24% to GC pressure).

truffleruby reads the other way from the blog page, and the cause is the GEM, not the runtime. TruffleRuby has no GVL for Ruby code; it gives a GLOBAL C-EXTENSION LOCK to any extension that has not declared itself thread-safe, and sqlite3 2.9.3 declares neither rb_ext_ractor_safe() nor rb_ext_thread_safe() — so every row every thread steps queues behind every other thread's. This lane runs the DEFAULT, locked, because that is what bundle install gives a deployer; --cexts-lock=false, TruffleRuby's own documented benchmarking advice, is worth 2.5× on this page (432 → 1,078 req/s at 5 threads, 393 → 977 at 12, measured 2026-09-22), which puts the emit at 2.3× the CRuby one-process row rather than 0.9×. What the flag does NOT remove is the per-call cost: single-threaded, a row stepped through the gem is 2.4 µs here against CRuby's 0.83, and the lock is only ~3% of that. Read this row against ruby-1p, the same one-process shape on CRuby.

rails-truffleruby is once-campfire ITSELF under TruffleRuby: the same oracle tree, rows, production config and Redis fragment cache, with a second bundle whose C extensions TruffleRuby compiled. It is ONE Puma process × 5 threads — TruffleRuby has no fork, so neither campfire's worker formula nor resque-pool can run, and Thruster is not in front — which makes it a runtime swap on the one-process rails-1p row, not on rails. Heap pinned at 2 GB, twice the blog's stock-Rails budget, for twice the working set. There is no rails-jruby: the AR-JDBC adapter drives Rails 8.0 only and campfire tracks rails/rails main, a gap recorded here rather than shimmed with a hand-pinned app.

spinel runs the same Roundhouse-emitted framework as the CRuby ruby cell, but compiled by Spinel behind its thread-per-connection server (a green thread per connection on the runtime's autodetected OS worker count) rather than CRuby + Puma — so the ruby → spinel gap is a runtime swap, not a framework or source change.