We put http.serve on the bench this week and found it
serving one connection at a time. Every connection got a correct answer,
and every connection waited its turn. At any load, throughput sat at a
flat 39k requests per second.
The fix is a classic single-threaded poll event loop inside the serve machinery. Connections now overlap; the handler still runs on the one VM thread, so the actor model's whole "no shared mutable state" story is untouched. Same box, same test, the sweep now reads 47k at one connection, 146k at eight, and 164k at 64, with latency rising the healthy way as load grows.
For fun, we ran the same plaintext hello-world against Node (112k) and Python (30k) on that box. And we do mean for fun: hello-world throughput benchmarks are a sport, tell you little about real HTTP workloads with real handlers and real databases, and every runtime plays it with different rules. We publish ours anyway because the trend line matters to us, and the setup is in the repo (Apple M4 Max, SCUA 0.13.0 release build, wrk 4.2.0, plaintext, measured July 15, 2026, zero socket errors, zero non-2xx). Read it as a health check, never a verdict.
The benchmark also caught something better than a number: the garbage
collector never ran during http.serve, so a long-lived
server's memory grew without bound. Ten seconds of load grew the arena
to 870 MB. That is fixed, the VM now collects at a safe point between
requests, and the counter that caught it (--serve-stats)
shipped so we keep catching things like it.