What one host can serve¶

Nerthus.Core (until cutover). This page describes the frozen system that runs today and is deleted at cutover. Replaced by: not yet written.

This page carries the daemon's measured capacity, the conditions that produced it, and — at the bottom, and read it — what it does not cover.

A capacity statement is a claim about a system nobody has run at capacity. The primary's ambient rate over 671 hours is 1.4 requests per minute, which is about 0.015% of the ceiling below. The number on this page will be quoted for years and has never been near a real load. That is not a reason to withhold it; it is a reason to publish the conditions in the same artefact.

The statement¶

For one fleet host, on this read mix:

Past 3 the CPU cap is reached and added concurrency buys nothing: roughly 5 ms of p50 and 8 ms of p90 per extra in-flight request, which is pure queueing.

The ramp¶

Closed-loop, 40 seconds per level, ten levels, 0 errors in 64 057 requests. Each worker holds one connection open the way a browser does and asks for the next thing the moment the last answer lands, so concurrency here is in-flight requests, not request rate.

Read the p90 row across, not down: 27 ms at two in flight and 150 ms at sixteen, for a throughput that never rises above the level-5 figure. That is the whole argument for the second number.

A single expensive read dropped into a steady stream is a smaller event than the table above might suggest: one /hygiene/orphans at 950 ms moved session.one from p50 5.1 ms to 11.0 ms while it ran (n=152) and back to 5.8 ms after. The route it lands on matters more than the load — see The accept loop.

An earlier pass, on the previous image digest, measured ~173 rps with the same knee at 3. Both readings are here rather than averaged: they are of different artefacts, and the shape — a knee at 3, no flat latency region, the CPU cap reached and held — is what survives both.

The conditions, in the same artefact as the number¶

It is a rig number. The rig reproduces a fleet host's HostConfig byte for byte and the daemon itself is not host-dependent — eder, an idle eight-core VPS, against the laptop's bench container on the same image and the same limits, measured a median ratio of 1.03× across eleven routes. The eight-core box is not faster because it is not allowed to be.

The read mix is the harness's, not a user's. A mix weighted toward the model-backed routes would give a lower number: those cost 100× to 2 500× more on a converging primary than on a rig, for a reason described under Why a rig and a host disagree.

It says nothing about writes. See The write path.

The eight cores nobody is allowed to use¶

Read from the rented host on 2026-08-25:

The rented box is the most throttled host in the fleet, and the 1.03× ratio above is the proof that the cap and not the hardware is what binds.

The reason is structural rather than accidental. reader_threads and search_index are per-role in Nerthus.Core.Infra.Dev/fleet.settings.yml; cpus and memory are literals in Nerthus.Core.Infra.Common/compose/docker-compose.yml, shared by every host, sized in a comment against "a laptop's share" from a burn-in on four laptop hosts. The settings schema already knows how to be per-role; the compose file does not know how to be per-host.

The decision is deferred deliberately. Adding a schema key to a fleet contract that three hosts are not yet executing is how the previous contract problem recurred. The measurement is finished and recorded here so it is not derived a third time; the contract edit belongs after the fleet is running the contract it declares.

And the shape it should take, since the question was asked: not a per-host override but two declared host roles, small and large, the way primary and replica already work — a per-host key invites drift no one reviews, while a role is a decision made once and applied by membership. small should keep today's numbers exactly (cpus: "1.5", memory: 3072M): they were sized against a laptop that also runs a second daemon stack, a CI runner and a Docker VM, and this page's own ramp shows a single daemon saturating 150% of a core cap under load. Nothing here argues for lowering them, and raising them on the laptop over-commits a machine that is already the fleet's contention floor.

The accept loop is a single point of failure¶

The daemon answers 231 routes on one accept loop plus two reader threads. Of its 134 GET routes, 67 may be answered on a reader thread and 67 are answered by the loop itself — which also runs thirteen scheduled ticks before every connection it accepts.

The isolation works in exactly one direction. Under control, 45-second arms with probes on both surfaces throughout (measured 2026-08-22, before the cost repairs that made two of these loads cheap):

Oversubscribing the reader pool fourfold leaves the loop at 7.2 ms. Two ordinary unpooled GETs take both surfaces, 341× and 337×.

On a real host over 671 hours, from the primary's own request stream: 323 accept-loop requests took longer than ten seconds, holding 5 961.5 s of merged wall time, during which the host answered 19 other requests — 0.191 per minute against an ambient 1.409. The same window's thirteen long pooled holds let 41 others through, 8.9× above ambient. The pool blocks nothing; the loop blocks everything.

GET /routes now says which is which, and why: poolReason distinguishes a route on the loop because it is cheap from one on the loop because it mutates shared state.

The write path¶

Every write measured on this daemon runs from tens of milliseconds to several seconds, against reads whose p50 is 2–20 ms. A capacity figure derived from reads and quoted at a system that also writes is the kind of number that has to be re-derived later.

The reader that pays for the commit. Two readers driving GET /sessions/summary across a real publish, on the repaired daemon:

The first read after the commit was the slowest in the window, at 3 962.3 ms against a p50 of 73.4 ms. That is the surface set being rebuilt, and the daemon now starts that rebuild from the write rather than waiting for a reader to ask — but a reader arriving inside the rebuild window still waits for it. What changed is the ordinary case on a host at 1.4 requests per minute, where the first reader after a write arrives long after the build has finished.

And that the read was slow is the proof it was not stale. A rebuild moved onto a background thread that served the old answer would have made that read fast. It was the slowest one.

POST /sessions/report is not in the table. The measurement sent no body and the route needs one, so what was recorded was a 400 in 346.9 ms — the cost of a refusal, not of a write.

Why a rig and a host disagree¶

State-free routes agree within 1.5×–8×. Model-backed ones do not:

The rig is not measuring wrongly. It only ever measures the warm case. A rig boots with sync off against an idle throwaway clone, pays a cold derivation once, and then measures the cached path forever. The discriminating evidence is the same bare route on the same host 111 seconds apart:

2026-08-05T15:46:10Z   GET /hygiene/orphans   17 431 ms
2026-08-05T15:48:01Z   GET /hygiene/orphans        7 ms
2026-08-05T15:48:11Z   GET /hygiene/orphans        3 ms

Nothing changed between them but whether something had already been derived — no converge fired, and the expensive sample had one other request in flight while the cheap ones had none, so it is neither the corpus nor queueing. The same split exists on the rig and had simply never been recorded: /hygiene/orphans costs 806.6 ms cold and 4.7 ms warm there.

At an ambient 1.4 requests per minute, every live read is a cold read. That is what the live figures above are a sample of.

A magnitude gap survives the split — the rig's cold arm is 806.6 ms and the primary's is 9 507–17 431 ms — and closing it needs a rig pointed at the primary's own commit with the same corpora wired. That has not been done, and this paragraph is the whole of what is known about it.

Three published numbers this page corrects¶

The two cold costs, so they are not conflated again:

• the surface set, built one-shot at boot and again whenever the model stamp moves — 6 087–9 560 ms on a rig and 27 613–33 556 ms on the three fleet hosts, read from /health.surfaces.ms on 2026-08-25;
• the search index, built lazily on first read — 785 ms for the lore tier and 4 738 ms for all four.

The fleet's surface build is four to five times the rig's on the same image, which is the largest unexplained rig-versus-host gap on this page and is not the same gap as the model-backed one above.

What is NOT covered¶

A capacity page with no section like this is the shape that makes the next reader believe the number covers their case.

• Writes. The ramp is reads. The write costs are in their own section and were not driven concurrently.
• The authenticated route surface. The eder comparison covers 22 anonymous routes, and only the 12 that resolve without a path parameter, so nothing in it speaks to authorization cost.
• The browser tier. ci/bench/04-sweep.mjs was not run.
• 129 of the 231 routes. The mix reaches 94 of them. The run says nothing about the rest.
• Every route whose measurement describes an EMPTY ARCHIVE rather than a fast daemon — speech, scenes, mentions, relations, log.archive, and /maps/dimensions, which answers 404 on a rig because the map corpus is not wired. Those belong to whoever wires the corpora.
• Production. Every number here describes the dev fleet.
• Sustained load against a fleet host. Permitted for this page and not taken: the daemon is not host-dependent (1.03×), so the reading would have cost a hole in the availability ledger to confirm a ratio already measured.