Master Nginx Performance: Tuning Workers, Connections, Epoll, and Accept Mutex

Nginx is a foundational component of large‑scale architectures. This guide explains the most impactful performance settings and how to apply them safely.

1. worker_processes – Upper bound of CPU utilization

The worker_processes directive determines how many worker processes Nginx starts. Each worker runs an independent event loop and typically matches the number of CPU cores. worker_processes auto; Using auto lets Nginx set the worker count equal to the core count. Mis‑configurations such as launching eight workers on a single‑core CPU cause excessive context switching, while starting only two workers on a 32‑core machine wastes resources.

2. worker_connections – Core of concurrent connection capacity

worker_connections

defines the maximum number of simultaneous connections each worker can handle.

The theoretical maximum connections are calculated as:

max_connections = worker_processes × worker_connections;

Example: on an 8‑core CPU with worker_processes set to 8 and worker_connections at 65 535, the theoretical concurrency reaches roughly 520 000 connections.

To realize this capacity, system limits must be raised, e.g.:

ulimit -n 1000000
fs.file-max = 2000000

Otherwise Nginx will fail with “too many open files”.

3. use epoll – Event model that defines the concurrency ceiling

On Linux, the epoll event model provides O(1) notification and supports million‑level concurrent connections, avoiding the linear scanning of select or poll.

events {
    use epoll;
}

In high‑traffic scenarios, select / poll quickly saturate the CPU, whereas epoll keeps CPU utilization high and stable, delivering orders‑of‑magnitude performance gains.

4. accept_mutex – Mitigating the thundering‑herd problem

When many workers wake up to accept the same incoming connection, unnecessary wake‑ups waste CPU cycles. Enabling accept_mutex ensures only one worker accepts new connections while others continue processing existing requests. accept_mutex on; This setting is especially beneficial for high‑QPS short‑lived connections where connection churn is frequent.

By applying these four configurations—proper worker_processes, sufficient worker_connections, enabling epoll, and turning on accept_mutex —you can unlock Nginx’s full performance potential.