Why Nginx Is So Fast: Inside Its Process Model and High‑Performance Architecture

Nginx Overview

Nginx is a free, open‑source, high‑performance HTTP server and reverse proxy, also supporting IMAP/POP3. It is renowned for its speed, stability, rich features, simple configuration, and low resource consumption. This article analyzes why Nginx is so fast from a low‑level perspective.

Process Model

Nginx uses a multi‑process architecture consisting of one master process and multiple worker processes.

Master Process: Manages worker processes, receives external signals, forwards commands to workers, and monitors worker health, automatically restarting any worker that exits unexpectedly.

Worker Processes: All workers are equal and handle network requests. The number of workers is configured in nginx.conf, typically set to the number of CPU cores to maximize resource utilization while avoiding excessive context switching.

HTTP Connection Establishment and Request Handling

The typical flow when Nginx starts:

Master process loads the configuration file.

Master initializes listening sockets.

Master forks multiple worker processes.

Workers compete for new connections; the winning worker completes the TCP three‑way handshake and processes the request.

Why Nginx Achieves High Performance and Concurrency

Multi‑process + asynchronous non‑blocking I/O (IO multiplexing with epoll).

Request processing pipeline: establish connection → read request → parse request → process request → send response.

Underlying operations are socket read/write events.

Event Handling Model

Nginx’s event model is built on an OS‑independent framework that registers events for each file descriptor and adds ready descriptors to an event list, avoiding linear scans.

Modular Architecture

Event module: Provides the core event handling mechanism (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 for static files).

Output filter: Modifies outgoing content, such as adding footers or rewriting image URLs.

Upstream: Implements reverse proxy, forwarding requests to backend servers and returning their responses.

Load‑balancer: Selects a backend server based on a specific algorithm.

Nginx vs Apache

Nginx: IO multiplexing (epoll/kqueue), high performance, high concurrency, low resource usage.

Apache: Blocking I/O with multi‑process/thread model, more stable, richer module ecosystem.

Maximum Connections

Maximum connections = number of worker processes × maximum connections per worker (set by worker_connections). When used as a reverse proxy, the effective maximum is half of that because each client connection also opens a backend connection.

HTTP Request and Response Structure

Request line: method, URI, HTTP version.

Request headers.

Request body.

Response line: HTTP version, status code.

Response headers.

Response body.

I/O Models

Two main approaches for handling multiple requests:

IO multiplexing: A single thread monitors many sockets and reads/writes only the ready ones.

Blocking IO + multithreading: One thread per request, simpler but incurs higher context‑switch overhead.

Select / Poll vs Epoll

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);

Both are synchronous I/O; epoll adds an event‑driven mechanism that avoids linear scans and supports a much larger number of file descriptors.

Concurrency Capability

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