The README's benchmark on a 2M-message database: Rails, the open performance PRs, the Spinel binary, Rust and Go

[namespaceMarcello]

The README's table measures five workloads on a small database. These are the same five workloads, measured the same way (16 concurrent clients, four hardware threads per app), on a database with 2 million messages and 10,008 users. The same run on a small database sits beside them, on the same machine.

Setup

• On our machine: a laptop with an AMD Ryzen 9 7940HX, running Docker Desktop on Windows 11. Each app was pinned to 4 CPUs and wrk -t2 -c16 to 4 others. Each run had 5 s of warm-up and 20 s measured.
• Rails ran as the Procfile ships it: Thruster in front of Puma with config/puma.rb's workers (3 × 5 threads on 4 CPUs), with resque-pool beside it and Redis in the same container.
• Every app read its own copy of the same SQLite file:
  • small: 50 users, 5 rooms, 500 messages;
  • large: 2,000,000 messages (room 1 holds 1,000,000 of them and has 10,003 members) and 10,008 users.
• The five implementations:
  • rails 90b3300: the commit Roundhouse pins;
  • rails + PRs: d2155e8 (which includes Preload only uncached messages and reduce rendering overhead #292, Index messages by room and creation time #295, Check for a second page of messages without counting the room #297, Search for operator words instead of parsing them #298, Read the newest search matches off the index instead of sorting them all #304 and Post a webhook reply as an attachment only when the bot answered 200 #306) plus the open Fan the unread room notice out from a job #296, Find a direct room with one query instead of checking every one #310, Find the messages a refresh replaces through an index #312 and List one page of account members at a time #316, on the same gems;
  • spinel: the published Roundhouse/Spinel archive of 90b3300;
  • rust: once-campfire-rust ccece30;
  • go: once-campfire-go 8d2f7f2.

Requests per second

	rails 90b3300	rails + PRs	spinel	rust	go
small · Room page	150	154	2,154	9,112	7,343
Messages page	242	270	3,149	10,025	9,549
Sidebar	322	325	3,378	11,599	8,497
Search	54	89	1,476	5,729	3,844
Post a message	143	207	1,002	3,533	2,626
large · Room page (1M messages)	7.4	155	9.2	4,439	3,520
Messages page	9.8	240	14.0	9,859	9,494
Sidebar	286	296	1,893	4,076	4,232
Search	24	106	57	13	24
Post a message (10,003 members)	1.4	125 *	53	282	144

wrk counted 26 socket timeouts across the Rust and Go runs, out of about 1.1 million requests, and none on Rails or the binary. No responses outside 2xx/3xx.

What the table shows:

• With the PRs, Rails keeps its throughput from the small database to the large one: 154 → 155 on the room page, 270 → 240 on the messages page. At 90b3300 it drops about twentyfold.
• The compiled binary of 90b3300 drops the same way, from 2,154 to 9.2. The cost is in the query, so compiling doesn't change it.
• Where every implementation runs the same efficient query (room page, messages page), Rust and Go stay 20–40 times ahead of Rails, as in the README.
• Search on the large database: Rails with the PRs serves 106 requests a second, Rust 13 and Go 24. The ports sort every match by created_at before taking 100. That is the sort Read the newest search matches off the index instead of sorting them all #304 removed from Rails (on a copy of the large database, 62 ms against 0.1 ms per query for the same 100 ids). We'll offer the ports the same change.

* Posting into a room with 10,003 members: in the request at 90b3300, Rails publishes one Redis message per member (Message::Broadcasts#broadcast_unread_room). #296 moves that into a job, so the response is fast, but the work remains: after the 20 s run, 5,897 jobs were still queued. Measured on its own, with no subscribers and Redis in the same container, sending those 10,003 publishes one at a time took 1,038 ms through Action Cable's Redis adapter, and 24 ms in one Redis pipeline. A batched broadcast would lift that limit. We'll take that to Rails separately.

One request at a time (large database, ms, median of 11 after 3 warm-ups)

Rails ran as one Puma worker with five threads, as in bench/compare_http.rb, and each app was limited to 8 CPUs.

	rails 90b3300	rails + PRs	spinel	rust	go	PR
Room page	377	27	387	2.0	2.4	#295, #297
Messages page (before)	294	10	261	1.3	1.8	#295, #297
Refresh (nothing new)	424	4.4	435	221	216	#312
Search	106	23	55	76	149	#304
Account settings, 10,008 users	3,234	163 †	310	92	309	#316
"Ping" with 10,000 direct rooms	3,442	9.7	1,553	23	10	#310
Post, 10,003 members	1,218	20 *	44	11	11	#296

† One page of 500 members (1 MB), where the others render all 10,008 (16–20 MB). That difference is the change #316 makes.

Rails' own log splits the time. At 90b3300 the room page spends 352 of its 370 ms in SQL, refresh 417 of 423, and "Ping" makes 40,005 queries. With the PRs these are 0.9 ms of SQL, 2 ms in total, and 8 queries.

Limits

• One machine and one run per configuration. The run-to-run spread of the throughput numbers wasn't measured.
• rails + PRs also differs from 90b3300 by the other upstream commits since then, Preload only uncached messages and reduce rendering overhead #292 among them.
• The binary doesn't log per-request timings, so its time isn't broken down.

The scripts (seed, wrk driver, latency probe) are in this gist.

Written by Claude Code (AI assistant) on behalf of @namespaceMarcello, who directs this work.