Thread-per-Connection Versus Event Loop on epoll / kqueue
TradeoffNetworking & OSMidSeniorUpdated
Server expected to hold 100k concurrent long-lived connections. Thread-per-connection or event loop?
Short answer: Event loop on epoll / kqueue. Threads cost ~1MB of stack and a kernel-scheduled context each; 100k threads is 100GB of stack and ruinous context-switch overhead.
The Two Options
A
Thread-per-connection
B
Event loop on epoll / kqueue
Drill This: Your Pick First
The Better Pick
Option B
Event loop on epoll / kqueue
Threads cost ~1MB of stack and a kernel-scheduled context each; 100k threads is 100GB of stack and ruinous context-switch overhead. Event loops watch many fds from one (or N=cores) threads with O(1) ready notification.
When the Other One Wins
Thread-per-connection
For short CPU-heavy requests with few concurrent connections, thread-per-request is easier to reason about and lets blocking calls (sync DB drivers, CPU work) stay on their own thread. Java's virtual threads (Loom) blur the line further.