Why doesn't NGINX use a thread-per-request model like Apache's prefork MPM?

A thread- or process-per-request model has to pay fixed overhead for every connection: allocating a stack, and having the OS scheduler context-switch between threads as it decides which gets CPU time next. That overhead is manageable at low concurrency but grows painfully as connection counts rise into the thousands - this is the C10k problem NGINX was explicitly designed to solve.

NGINX instead uses a small, fixed number of worker processes, each handling many connections through non-blocking I/O and an event loop. Because a connection that's idle - waiting on network I/O or a slow backend - doesn't tie up a dedicated thread, memory and CPU use scale far more gently as concurrent connections increase.

The trade-off is architectural complexity: code has to be written in a non-blocking style, and CPU-heavy work inside a request can stall every other connection that worker is handling, since there's no separate thread to isolate it. That's a deliberate design choice in exchange for dramatically better concurrency at scale.