How Nginx’s Multi‑Process Architecture Powers High‑Performance Web Serving

Basic Principles

Nginx operates on a multi‑process architecture consisting of one Master process and multiple Worker processes.

Nginx Process Model

Multi‑process : one Master process and several Worker processes.

Master process manages Worker processes, handling external signals and forwarding internal operations to Workers.

Worker processes are equal; each handles network requests and can be configured to match the number of CPU cores.

Request Handling Flow

When Nginx starts, the Master process loads the configuration file.

The Master process initializes listening sockets.

The Master process forks the configured number of Worker processes.

Workers compete for new connections; the winner completes the TCP three‑way handshake, establishes a socket, and processes the request.

Nginx Event Processing Model

Requests are processed in three stages: receive, process, and respond.

Receive request : read request line, headers, and body if present.

Process request .

Return response : generate response line, headers, and body.

Modular Architecture

event module : provides an OS‑independent event handling framework (e.g., ngx_events_module, ngx_event_core_module, ngx_epoll_module).

phase handler : handles client requests and generates response content (e.g., ngx_http_static_module).

output filter : modifies output content such as adding footers or rewriting URLs.

upstream : implements reverse‑proxy functionality, forwarding requests to backend servers.

load‑balancer : selects a backend server based on a specific algorithm.

Common Questions

Nginx vs. Apache

Apache uses a blocking, multi‑process/thread model, offering stability and richer modules, while Nginx employs a non‑blocking, event‑driven model with higher performance and lower resource consumption.

I/O Models

Nginx relies on I/O multiplexing (epoll on Linux, kqueue on BSD) to achieve high concurrency.

select : limited to 1024 file descriptors, linear scanning, and data copying.

poll : replaces the fixed‑size fd_set with a pollfd array, removing the descriptor limit.

epoll : event‑driven, registers interest events for each fd, adds ready fds to a ready list, and supports a much larger number of descriptors limited only by OS resources.

Maximum Connections

The maximum number of connections is determined by the number of Worker processes multiplied by the per‑process worker_connections limit, which cannot exceed the system’s open‑file limit ( nofile). When Nginx acts as a reverse proxy, each client connection also creates a backend connection, effectively consuming two file descriptors per request.

Concurrency Capability

After optimization, Nginx can handle peak concurrent connections of 10 000–30 000, depending on memory and CPU core count.

int select(int maxfdp, fd_set *readfds, fd_set *writefds, fd_set *errorfds, struct timeval *timeout);
int poll(struct pollfd fds[], nfds_t nfds, int timeout);