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.

Open Source Linux
Open Source Linux
Open Source Linux
Why Is Nginx So Fast? Inside Its Process Model and Event Architecture

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/19571087

Maximum 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

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendperformanceWeb serverEvent-drivenProcess Model
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.