Why Does Nginx Use a Multi‑Process, Asynchronous Event Model?

It is well known that Nginx delivers high performance, and this performance is inseparable from its architecture. Let’s first get acquainted with the Nginx framework.

After starting, Nginx runs as a daemon in the background on Unix systems, consisting of one master process and multiple worker processes. The master manages workers—receiving signals, sending signals, monitoring status, and restarting workers on failure—while workers handle network events. Workers compete equally for client requests, and each request is processed by a single worker. The number of workers is typically set to match the CPU core count.

The master process can be controlled via signals (e.g., kill -HUP <pid> for graceful reload) or newer command‑line options such as ./nginx -s reload and ./nginx -s stop. A graceful reload loads new configuration, spawns new workers, and retires old ones after they finish pending requests.

Worker processes accept connections using an accept_mutex to ensure only one worker registers the listen socket for reading. Once a worker accepts a connection, it reads, parses, processes, and responds to the request entirely within that worker.

Multi‑thread model vs. multi‑process model

The multi‑process model brings several benefits: no locking overhead, easier debugging, isolation (a crashed worker does not affect others), and rapid replacement of failed workers. Although Nginx also supports threads, the default and mainstream deployment is multi‑process.

To achieve high concurrency, Nginx uses an asynchronous non‑blocking event model. Instead of blocking on I/O, it registers interest in events with mechanisms like epoll (or kqueue, select, poll). When an event is not ready, the system call returns EAGAIN, allowing the worker to continue processing other ready events. This eliminates the need for thousands of threads and reduces context‑switch overhead.

Besides network events, Nginx also handles signals and timers. Signals interrupt the process and may cause epoll_wait to return early. Timers are stored in a red‑black tree; the nearest timer determines the timeout passed to epoll_wait. When the timeout expires, Nginx processes timer events before handling network events.

Below is a simplified pseudo‑code representation of Nginx’s event loop:

while (true) {
    for t in run_tasks:
        t.handler();
        update_time(&now);
        timeout = ETERNITY;
        for t in wait_tasks:  /* sorted already */
            if (t.time <= now) {
                t.timeout_handler();
            } else {
                timeout = t.time - now;
                break;
            }
        nevents = poll_function(events, timeout);
        for i in nevents:
            task t;
            if (events[i].type == READ) {
                t.handler = read_handler;
            } else {  /* events[i].type == WRITE */
                t.handler = write_handler;
            }
        run_tasks_add(t);
}

The accompanying diagram illustrates the master‑worker process model:

In summary, Nginx’s architecture combines a multi‑process model with an asynchronous, non‑blocking event loop, enabling it to handle millions of concurrent connections efficiently while maintaining stability and low resource consumption.