Web / NGINX Interview questions
Why is NGINX considered more performant than process-per-connection servers?
Process-per-connection (or thread-per-connection) servers pay a fixed cost for every open connection: memory for the process/thread stack, and CPU time for the OS to context-switch between them. As concurrent connections climb into the thousands, that overhead compounds - this is the classic C10k problem.
NGINX avoids most of that cost by handling many connections within a single worker's event loop instead of spinning up new OS-level execution contexts. A connection that's idle, waiting on the network or a slow backend, costs almost nothing while it waits - no dedicated thread is sitting there consuming a stack's worth of memory.
The practical result is that NGINX can hold far more concurrent connections per unit of memory and CPU than a traditional process-per-connection model, which is exactly why it became a default choice for handling high levels of simultaneous traffic.
More Related questions...