Why Is Nginx So Fast? Inside Its Process Model and Event Architecture
This article explores Nginx’s high performance by dissecting its multi‑process architecture, event‑driven model, modular design, and I/O handling, comparing it with Apache, and explaining connection limits, request flow, and concurrency mechanisms to reveal why Nginx excels under heavy load.
Introduction
Nginx is renowned for high performance, stability, rich features, simple configuration, and low resource consumption. This article analyzes the underlying principles that make Nginx so fast.
Nginx Process Model
Normal operation
Multi‑process : one master process and multiple worker processes.
Master process : manages workers, receives external signals, forwards commands, monitors worker status, and restarts workers on failure.
Worker processes : all workers are equal; they handle network requests. The number of workers is configured in nginx.conf, typically set to the number of CPU cores to maximize utilization while avoiding excessive context switching.
Thoughts
Does the request first reach the master process for handling and forwarding?
How is a specific worker chosen to process a request, and does the response pass through the master?
HTTP Connection Establishment and Request Processing
When Nginx starts, the master process loads the configuration file.
The master initializes listening sockets.
The master forks multiple worker processes.
Workers compete for new connections; the winner completes the TCP three‑way handshake, establishes a socket, and processes the request.
Why Nginx Achieves High Performance and Concurrency
Uses a multi‑process + asynchronous non‑blocking model (I/O multiplexing with epoll).
Request flow: connection → read request → parse request → process request → send response.
At the low level, this corresponds to read/write socket events.
Nginx Event Handling Model
In Nginx, an HTTP request follows the same routine as any web server: receive request line and headers, read the body if present, process the request, and generate a response (status line, headers, 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 : processes client requests and generates responses, such as the static file handler ngx_http_static_module.
Output filter : modifies the output content, e.g., adding footers 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.
Common Questions
Nginx vs Apache
Nginx :
I/O multiplexing (epoll on Linux, kqueue on FreeBSD)
High performance
High concurrency
Low resource consumption
Apache :
Blocking I/O with multi‑process/multi‑thread model
More stable, fewer bugs
Richer module ecosystem
Reference articles:
http://www.oschina.net/translate/nginx-vs-apache
https://www.zhihu.com/question/19571087Maximum Connections
Nginx is a multi‑process model; each worker handles requests. The per‑process file descriptor limit is set by ulimit -n. worker_connections defines the maximum connections per worker, and worker_processes defines the number of workers.
Therefore, the maximum connections for a generic Nginx server are:
Maximum connections = worker_processes × worker_connections.
When used as a reverse proxy, the effective maximum is half of that because each client connection also opens a connection to the backend.
HTTP Request and Response
Request consists of a request line (method, URI, HTTP version), headers, and optional body.
Response consists of a status line (HTTP version, status code), headers, and body.
I/O Models
I/O multiplexing : a single thread monitors many sockets and reads/writes only the ready ones.
Blocking I/O + multithreading : each request is handled by a separate thread.
Choosing between them depends on workload: I/O multiplexing excels at high concurrency and low resource usage, especially for long‑lived connections, while multithreading is simpler but incurs higher context‑switch overhead.
Select / Poll / Epoll Comparison
// 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);Select uses a fixed‑size fd_set (default 1024), requires linear scanning, and copies state between user and kernel space, limiting the number of descriptors.
Poll replaces fd_set with an array of pollfd, removing the descriptor limit but still copying state.
Epoll registers events for each descriptor, avoids linear scans, and supports an unlimited number of descriptors (limited only by OS resources).
Nginx Concurrency Capability
After optimization, Nginx can handle 10,000–30,000 concurrent connections, depending on memory and CPU core count.
Author: NingG1
Source: http://ningg.top/nginx-series-principle
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
