The Event-Driven Core, Revisited

Web Servers Fundamentals Chapter 2 described Nginx's event-driven model conceptually: a small number of worker processes, each an event loop handling many connections without a thread per connection. This chapter tunes that model for a real workload — the two directives that actually control it, the OS-level mechanism underneath, and the real ceiling those directives run into.

worker_processes

worker_processes sets how many worker processes Nginx runs. Setting it to auto matches it to the number of available CPU cores — generally the right starting point, since each worker's own event loop runs most efficiently with its own dedicated core. Setting it too low under-uses available hardware; setting it meaningfully higher than the core count doesn't add real capacity and just adds context-switching overhead between more processes than the machine can genuinely run in parallel.

worker_connections

worker_connections, set inside the events {} block, caps how many simultaneous connections a single worker can hold open. The real theoretical maximum number of simultaneous connections Nginx can handle is worker_processes × worker_connections — but this number is also capped by the operating system's own file descriptor limit, since every open connection consumes one file descriptor. Raising worker_connections without also raising the OS limit (worker_rlimit_nofile, and the OS's own ulimit) simply hits that ceiling instead of the number configured in Nginx.

The Event Loop in Practice

On Linux, Nginx's event loop is built on epoll, a kernel mechanism that lets a single process ask "which of these thousands of connections actually has new data ready?" without checking each one individually — the technical foundation underneath Web Servers Fundamentals' own conceptual description of "non-blocking I/O." This is what lets one worker process track thousands of mostly-idle connections cheaply, rather than needing a dedicated thread watching each one.

multi_accept and accept_mutex

Two lesser-known but real tuning directives, both inside events {}: multi_accept controls whether a worker accepts every waiting new connection in one pass or just one per event-loop cycle; accept_mutex historically serialized which worker was allowed to accept a new incoming connection, to avoid all workers waking up for the same single new connection (a "thundering herd"). Modern Nginx defaults accept_mutex to off, since modern kernels already handle this efficiently on their own — a good example of a once-important tuning knob that's since become mostly unnecessary.

Hands-On Exercises