How Nginx’s Multi‑Process and Event Model Powers High‑Performance Web Serving

Nginx’s underlying implementation consists of three main modules: Process, Event, and Network.

Process Module

By default Nginx starts in daemon mode, where the master process runs in the background.

After startup, Nginx creates one master process and multiple worker processes. The master process manages workers, collects and distributes network events, and schedules CPU resource usage.

Typically the number of worker processes matches the number of CPU cores to maximize CPU utilization and avoid extra overhead from process allocation.

Master Process Working Principle

The master process mainly manages worker processes, for example:

Receiving external signals and forwarding them to workers.

Monitoring worker status and automatically restarting a new worker if one exits abnormally.

Worker Process Working Principle

Basic network events are handled inside worker processes.

All workers are equal; each has the same opportunity to handle requests.

When a worker accepts a connection, it reads, parses, processes the request, generates a response, sends it back to the client, and finally closes the connection. The entire request lifecycle is handled by a single worker.

Nginx provides an accept_mutex lock so that only one worker accepts a connection at a time, eliminating the need for additional locking inside workers.

Benefits:

Each worker runs as an independent process without locks, reducing lock overhead and simplifying debugging.

Workers do not affect each other; if one exits, others continue serving, and the master quickly spawns a replacement.

Event Module

Traditional Apache uses a thread-per-request model, which consumes large memory and CPU due to thread context switches when handling thousands of concurrent requests.

Nginx adopts a multi‑worker model where each worker contains only a single main thread. Despite this, Nginx achieves high concurrency through an asynchronous non‑blocking approach, allowing it to handle tens of thousands of simultaneous connections.

Why can Nginx use asynchronous non‑blocking? Because it avoids blocking system calls. When an event is not ready, the call returns EAGAIN, indicating the operation should be retried later. The worker periodically checks the event status, performing other tasks in the meantime.

Although this requires frequent event checks, it enables the server to do more work without the cost of blocking.

Setting the number of workers equal to the CPU core count is recommended; adding more workers only increases competition for CPU resources and unnecessary context switches.

For a basic web server, events are typically of three types: network events, signals, and timers. Network events are efficiently handled by the asynchronous non‑blocking model. Signal and timer handling are mentioned but not detailed.

Signal handling (to be added).

Timer handling: Nginx stores timer events in a red‑black tree and determines the epoll_wait timeout based on the nearest timer.

Network Module

Not discussed in this article.

References:

Nginx Implementation Principles http://www.jianshu.com/p/b77482d4b670

How Nginx’s Multi‑Process Model Achieves High Concurrency https://www.zhihu.com/question/22062795

Exploring the Nginx Platform http://tengine.taobao.org/book/chapter_02.html

Source: https://www.cnblogs.com/xawei/p/6748315.html