Why Is Nginx So Fast? Inside Its Process and Event Models

Basic Principles

Nginx is a free, open‑source, high‑performance HTTP server, reverse proxy, and IMAP/POP3 proxy. Its reputation stems from high performance, stability, rich features, simple configuration, and low resource consumption.

Nginx Process Model

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

The master process manages the workers and handles external signals.

Worker processes are equal peers that actually 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).

HTTP Connection Establishment and Request Processing

The master process loads the configuration file at startup.

It creates listening sockets.

It forks the configured number of worker processes.

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

Nginx Event Processing Model

Nginx combines a multi‑process architecture with an asynchronous, non‑blocking I/O model (IO multiplexing using epoll on Linux).

The request handling flow is:

Establish the TCP connection.

Read and parse the request line, headers, and optional body.

Process the request (static file handling, proxying, etc.).

Generate and send the 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 : Handles client requests and produces response content (e.g., ngx_http_static_module for static files).

Output filter : Modifies output content, such as injecting footers or rewriting URLs.

Upstream : Implements reverse‑proxy functionality, forwarding requests to backend servers.

Load‑balancer : Selects a backend server based on configured algorithms.

Common Questions

Nginx vs. Apache

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

Apache relies on blocking I/O with multiple processes/threads, providing stability, a larger module ecosystem, and fewer bugs.

Reference URLs: http://www.oschina.net/translate/nginx-vs-apache, https://www.zhihu.com/question/19571087

I/O Models

When handling many requests you can choose: IO multiplexing (e.g., epoll) – suitable for I/O‑intensive, long‑connection scenarios; reduces context‑switch overhead. Blocking I/O + multithreading – simpler to implement, better for CPU‑intensive workloads but incurs higher thread‑scheduling costs.

Select / Poll vs. Epoll

System calls:

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

Select uses a fixed‑size fd_set (default 1024), suffers from linear scanning and a hard descriptor limit.

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

Epoll registers events per descriptor, avoids linear scans, and supports virtually unlimited descriptors (limited only by OS resources).

Maximum Connections in Nginx

Each worker process can open a limited number of file descriptors (FDs) defined by the nofile limit ( ulimit -n).

The per‑worker connection limit is set with worker_connections and cannot exceed the nofile limit.

The total number of workers is configured with worker_processes.

Maximum total connections ≈ worker_processes × worker_connections. In reverse‑proxy mode the effective limit is roughly half because each client connection also opens a backend connection.

Typical optimized Nginx deployments can sustain 10,000–30,000 concurrent connections, depending on memory and CPU core count.