Understanding Nginx Process Model and High‑Performance Architecture

Nginx is renowned for its high performance, stability, rich feature set, simple configuration, and low resource consumption. This article analyzes the underlying principles that make Nginx so fast.

Nginx Process Model

During normal operation, Nginx runs one master process and multiple worker processes.

Multi‑process: one master process, many worker processes.

Master process: manages workers, receives external signals, forwards commands to workers, and monitors worker status, 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 , usually set to the number of CPU cores to fully utilize resources while avoiding excessive context‑switch overhead.

Thought:

Does the master process handle and forward incoming connections?

How is a specific worker chosen to process a request, and does the request pass through the master again?

HTTP Connection Establishment and Request Processing

When Nginx starts, the master loads the configuration file.

The master initializes listening sockets.

The master forks multiple worker processes.

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

Nginx High Performance and High Concurrency

Why can Nginx achieve high performance and support high concurrency?

Nginx uses a multi‑process + asynchronous non‑blocking model (I/O multiplexing with epoll).

The complete request flow is: establish connection → read request → parse request → process request → send response.

At the low level, this flow corresponds to read/write socket events.

Nginx Event Handling Model

In a basic HTTP web server, the workflow is:

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

Process request.

Return response: generate response line, headers, and body based on processing results.

Nginx follows the same overall flow.

Modular Architecture

Nginx modules are grouped by functionality:

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

Phase handler: also called handler modules; they process client requests and generate content (e.g., ngx_http_static_module for static files).

Output filter: modifies the output content, such as adding a footer to HTML pages or rewriting image URLs.

Upstream: implements reverse‑proxy functionality, forwarding requests to backend servers and returning their responses.

Load‑balancer: selects a backend server based on a specific algorithm for each request.

Common Questions

Nginx vs Apache

Nginx: I/O 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 workers × maximum connections per worker (controlled by worker_connections ).

When used as a reverse proxy, the effective maximum is roughly half of that because each client connection also opens a connection to the backend.

HTTP Request and Response Structure

Request consists of request line (method, URI, HTTP version), headers, and optional body. Response consists of status line (HTTP version, status code), headers, and body.

I/O Models

Multiple requests can be handled using I/O multiplexing or blocking I/O with multithreading.

I/O multiplexing: a single thread monitors many sockets and reads/writes the ready ones.

Blocking I/O + multithreading: each request gets its own thread, which is simpler but incurs higher context‑switch overhead.

Select/Poll vs Epoll

Key differences:

Select: uses a fixed‑size fd_set (default 1024), linear scanning, limited number of descriptors.

Poll: replaces fd_set with an array of pollfd , removing the descriptor limit but still requires copying state between user and kernel.

Epoll: event‑driven, registers interest per fd, no inherent descriptor limit, avoids linear scans.

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

Nginx Concurrency Capability

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

-END-