Two vCPUs rendered 5,000 separately editable sites at 150 requests a second

45.6% of two vCPUs ^[5] is 0.912 vCPU-seconds of CPU spent per wall-clock second. Divide that by 150 responses per second and each response cost roughly 6.1 ms of CPU ^[2]. The post enumerates what that budget has to cover: domain resolution, Kooboo site selection, routing, layout and view rendering, the uncached home-page content query, HTML generation and response transfer ^[11]. The requests arrived over HTTPS from a separate cloud, across the public Internet, not over loopback ^[1].

The arithmetic closes. A target of 150 starts per second for ten minutes is 90,000 requests, and 89,969 verified responses plus 31 connection timeouts is exactly 90,000 ^[1]. Nothing went missing between the generator and the summary table.

Two other divisions carry more weight than the headline. Resident memory peaked near 2.50 GiB across 5,000 sites, about 0.51 MiB per site ^[3], and because that total includes the runtime baseline the marginal cost per site is lower than that. And 150 requests per second spread across 5,000 hostnames is 0.03 requests per second per site, about 18 requests per site over the whole run ^[4]. That is the traffic shape of long-tail hosting, which is the honest workload for 5,000 small sites, but it means no individual site was ever hot.

The run does not locate a ceiling, and it was not built to. The generator held a fixed target rate ^[3] rather than ramping until failures climbed. Sampled peak CPU was 81.5% against the 45.6% average ^[5], a peak-to-average ratio near 1.8, and scaling the offered rate by 100/81.5 would put sampled peaks at the two-vCPU wall somewhere near 184 requests per second ^[5]. That is arithmetic on two sampled numbers rather than a measurement. The 31 failures were connection timeouts ^[4], which points at connection handling rather than the render path.

What would have to be true for this density to transfer is the harder question, and Kooboo is straight about part of it. All 5,000 sites came from one imported package, which held page structure, content volume, query shape and response size constant, and the post says that choice creates an important limitation ^[13]. Five thousand sites that launched with the same ten AI-written articles ^[9] are the cheapest five thousand sites anyone will ever host. Real tenants diverge in template count, content volume and query shape, and divergence is what stops a shared working set from staying small. The benchmark also requested only root pages, so the article-detail routes shipped inside the package went unexercised ^[11].

The parts of this I would keep are the verification and the cache configuration. Each clone carries a visible marker such as Site 4996, and the client checked for the expected marker in every body, on the grounds that a 200 cannot prove 5,000 hostnames reached 5,000 correct site bindings ^[12]. Only the Header View is configured with cache-by-purpose and there is no full-page output cache ^[10], so the measured work is rendering rather than a cache read. The isolation claim, that all 5,000 share one server process while each keeps its own editable site record ^[8], is the one thing a CSV cannot demonstrate, and Kooboo is offering technical reviewers temporary access to edit an assigned site and watch what happens ^[14].