The C10k Problem
In the late nineties a single web server rarely handled more than a few hundred clients at once. As the web grew, engineers asked a sharper question: can one machine hold ten thousand open connections at the same time. That target became known as the C10k problem.
The trouble was never raw bandwidth or processing power. It was the cost of the model used to track each connection. The classic design gave every connection its own operating system thread. With ten thousand threads, the memory for stacks and the time spent switching between them swamped the actual work.
- Memory Each thread reserves stack space, often a megabyte, so ten thousand threads can demand gigabytes before serving a byte.
- Scheduling The kernel must pick among thousands of threads, and most are merely waiting on the network.
- Idle waiting Connections spend almost all their life idle, so dedicating a busy thread to each one wastes the resource.
C10k reframed scalability as a question of design rather than hardware. The answer was to stop pairing one thread with one connection and instead let a small number of threads watch many connections at once.
Key idea
The C10k problem showed that scaling to many connections is limited by the per connection model, not by hardware, pushing servers away from one thread per client.