// the take
A set of 13 small Go TCP server implementations benchmarking different approaches to handling 1 million concurrent connections: goroutine-per-connection, raw epoll, prefork, worker pool/reactor, with separate throughput/latency and CPU/IO-bound variants. It's for Go developers researching connection-scaling strategies and wanting real numbers instead of folklore.
The spread of implementations (goroutine-per-conn vs single/multiple epoll vs prefork vs worker pool) isolates one variable at a time, which makes the throughput/latency table at the bottom genuinely useful for understanding tradeoffs. It includes matching client-side epoll implementations so load generation isn't the bottleneck. The IO-bound vs CPU-bound server variants are a nice touch most 'C10M' benchmark repos skip.
Dead since 2021 — no updates for newer Go runtime scheduler changes (which materially affect goroutine-per-connection numbers) or netpoller improvements. Benchmarks were run once on one two-socket E5-2630 v4 box with no methodology for variance, warmup, or repeat runs, so the numbers are a single data point, not something you can trust for capacity planning. epoll_linux.go is Linux-only with no io_uring variant, so it's already behind the current state of the art for this exact problem. This is benchmark code, not a library — there's nothing here to depend on or integrate, only patterns to read and reimplement yourself.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →