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

Nginx is a free, open‑source, high‑performance HTTP server, reverse proxy, and IMAP/POP3 proxy.

Nginx Process Model

It uses a master‑worker architecture: one master process manages multiple worker processes. The master handles signals, monitors workers, and restarts them if they exit unexpectedly. Workers are equal and handle network requests; the number of workers is usually set to the CPU core count to maximize resource utilization while avoiding excessive context switching.

Multi‑process: one master, multiple workers.

Master process: manages workers, receives external signals, forwards them, monitors worker status, and restarts crashed workers.

Worker process: handles network requests; the number of workers is configured in nginx.conf, typically equal to the number of CPU cores.

HTTP Connection Establishment and Request Handling

Master loads configuration at startup.

Master initializes listening sockets.

Master forks 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 Concurrency

Uses multi‑process + asynchronous non‑blocking I/O (epoll).

Full 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

Basic HTTP web server workflow: receive request (read request line, headers, body), process request, return response (status line, headers, body).

Modular Architecture

event module: provides OS‑independent event framework (ngx_events_module, ngx_event_core_module, ngx_epoll_module, etc.).

phase handler modules: handle client requests and generate content (e.g., ngx_http_static_module).

output filter modules: modify output content (e.g., add footers, rewrite URLs).

upstream modules: implement reverse proxy, forwarding requests to backend servers.

load‑balancer modules: select a backend server according to a load‑balancing algorithm.

Common Questions

Nginx vs Apache

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

Apache uses blocking I/O with multi‑process/thread, more stable, richer modules.

Maximum Connections

Nginx is multi‑process; workers handle requests.

Each process’s file descriptor limit is set by ulimit -n. worker_connections limits connections per worker; worker_processes sets number of workers.

Maximum connections = workers × worker_connections. For reverse proxy, effective connections are roughly half because each client connection also opens a backend connection.

HTTP Request and Response

Request line: method, URI, HTTP version.

Request headers.

Request body.

Response line: HTTP version, status code.

Response headers.

Response body.

I/O Models

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

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

Blocking I/O + multithreading: a new thread per request.

Select, Poll, and 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: scans fd_set (max 1024), limited connections, linear scan, copies data between user and kernel.

Poll: replaces fd_set with an array of pollfd, removes the 1024 limit but still copies data.

epoll: registers events for each fd, avoids linear scan, unlimited fd count (OS limit), event‑driven.

Nginx Concurrency Capability

After optimization, Nginx can handle peak concurrent connections of roughly 10‑30 k, depending on memory and CPU cores.