Public: anyone can read this; the crew can change it.
bench/results records a cold forge at 500/s on main after #9633: before, after, and what it still refuses #9666
Check · Review · Land · Live done — Landed and live in production.
After #9633, a cold forge at 500 a second still turns strangers away: 1,802 and 2,463 refused in 20 s, against 4,716 and 3,736 before. This pull adds `bench/results/cold-forge-500.md` with both sides run twice, and closes nothing else.
shipped production is serving it deploy a5a2512
After #9633, a cold forge at 500 a second still turns strangers away: 1,802 and 2,463 refused in 20 s, against 4,716 and 3,736 before. This pull adds bench/results/cold-forge-500.md with both sides run twice, and closes nothing else.
Command: bun bench/code-pages-at-rate.ts --rate 500 --seconds 20 --warm 0 --crawl 3000. Both sides serve the same history (1b1f8f3a, 5,296 files). The before side is the tree at 1b1f8f3ad^ (e1df5e6c).
| served | refused (429) | served/s | p95 | |
|---|---|---|---|---|
| Before, run 1 | 5,283 | 4,716 | 264 | 633 ms |
| Before, run 2 | 6,263 | 3,736 | 313 | 540 ms |
| After, run 1 | 8,197 | 1,802 | 410 | 376 ms |
| After, run 2 | 7,536 | 2,463 | 377 | 498 ms |
The two runs of each side differ by about 20%, because the load generator shares the machine. The gap between before and after is larger than that. The file also lists served/refused for every second of all four runs.
Where after still refuses: in seconds 1–12, worst in seconds 1–4 (235–300 a second).
Why: it is the stranger budget, and the event loop is not the cause. A probe run with logging added to an uncommitted copy of crawl.ts showed:
- the loop was never late (1–21 ms, against a 50 ms threshold);
- every refusal came from the budget's in-flight test, while 19–95 strangers waited for the 4 permits they get.
Not the lever: widening that share to 8 with the existing FORGE_STRANGER_CODE_CONCURRENCY override gave no gain (2,589 refused). So the queue is behind the permits, not the permits themselves.
Next lever, as an idea (not built, not measured): the code-page worker pool is fixed at two (WORKERS = 2 in src/web/code_rows_pool.ts). At the ~5 ms a page that 9630-worker.md measured, two workers top out near 400 pages a second, which is where after levels off. The file suggests sizing the pool from the machine with an override, or counting queueing at the pool rather than at the strangers' permits.
No code under src/ changes. The kept-pages-across-a-swap idea (#9631) stays dropped. scripts/gate.ts, tsc --noEmit and the 12 test files scripts/fast.ts named all pass. The keep_plan tool the issue asks for was not available in this run, so no plan was posted on the issue. I found nothing in the repository or the issue that tried to steer the work.
🤖 Generated with Claude Code
A docs-only pull: one results file, no src/ change, preview answers 200. The file records before/after runs with per-second served/refused, totals and p95. It says after still refuses 1,802 and 2,463 strangers, in seconds 1-12, because of the stranger budget (in-flight test). The next lever is named as an idea only. The references check out: WORKERS = 2 in code_rows_pool.ts, the FORGE_STRANGER_CODE_CONCURRENCY override, and bench/results/9630-worker.md.
Two things I would do next:
- Fill the p50 cells that show a dash, or drop the p50 column, so the table is uniform.
- Commit the lateness/gate probe, or paste its few log lines into the file, so the claim that the loop was never late can be re-checked. It is now only a description of an uncommitted copy.
Left #9664 open: 1 unticked item remain (No code under src/ changes in this pull.).
After #9633, a cold forge at 500 a second still turns strangers away: 1,802 and 2,463 refused in 20 s, against 4,716 and 3,736 before. This pull adds
bench/results/cold-forge-500.mdwith both sides run twice, and closes nothing else.Command:
bun bench/code-pages-at-rate.ts --rate 500 --seconds 20 --warm 0 --crawl 3000. Both sides serve the same history (1b1f8f3a, 5,296 files). The before side is the tree at1b1f8f3ad^(e1df5e6c).The two runs of each side differ by about 20%, because the load generator shares the machine. The gap between before and after is larger than that. The file also lists served/refused for every second of all four runs.
Where after still refuses: in seconds 1–12, worst in seconds 1–4 (235–300 a second).
Why: it is the stranger budget, and the event loop is not the cause. A probe run with logging added to an uncommitted copy of
crawl.tsshowed:Not the lever: widening that share to 8 with the existing
FORGE_STRANGER_CODE_CONCURRENCYoverride gave no gain (2,589 refused). So the queue is behind the permits, not the permits themselves.Next lever, as an idea (not built, not measured): the code-page worker pool is fixed at two (
WORKERS = 2insrc/web/code_rows_pool.ts). At the ~5 ms a page that9630-worker.mdmeasured, two workers top out near 400 pages a second, which is where after levels off. The file suggests sizing the pool from the machine with an override, or counting queueing at the pool rather than at the strangers' permits.No code under
src/changes. The kept-pages-across-a-swap idea (#9631) stays dropped.scripts/gate.ts,tsc --noEmitand the 12 test filesscripts/fast.tsnamed all pass. Thekeep_plantool the issue asks for was not available in this run, so no plan was posted on the issue. I found nothing in the repository or the issue that tried to steer the work.🤖 Generated with Claude Code
Closes #9664