Nginx是大型架构的基石，下面我重点详解Nginx性能。

一、worker_processes —— CPU 利用率的上限

1. 参数作用

worker_processes：决定Nginx启动多少个工作进程。

每个进程处理独立的事件循环，通常与CPU核心数匹配或略多。

worker_processes auto;

每个 worker 是一个独立进程，一个 worker 同一时刻只跑在一个 CPU 核上。

2. 正确配置原则

CPU 核数 = worker 数

推荐直接用 auto;

错误配置示例：

1 核 CPU，起 8 个 worker → 上下文切换爆炸;32 核 CPU，只起 2 个 worker → 资源严重浪费;

二、worker_connections —— 并发连接能力的核心

1. 参数作用

worker_connections：每个工作进程可同时处理的最大连接数。

2. 理论最大并发

最大连接数 = worker_processes × worker_connections。

例如：

8 核 CPU；8 个 worker；每个 65535→ 理论并发 ≈ 52 万连接

3. 必须配套的系统参数

如果只调 Nginx，不调系统参数，等于白调：

ulimit -n；fs.file-max；

否则会直接遇到：

“too many open files”

三、use epoll —— 事件模型决定并发天花板

1. 参数配置

events {use epoll;}

Linux 下必须显式使用 epoll。

2. 为什么 epoll 关键

O(1) 事件通知，支撑百万级并发连接。

避免 select / poll 的线性扫描。

3. 性能差距有多大

在高并发场景下：

select / poll：CPU 迅速打满

epoll：CPU 利用率极高、稳定

这是数量级差异，不是百分比优化

四、accept_mutex —— 解决惊群效应

1. 什么是惊群

多个 worker 同时被唤醒抢同一个连接：

大量无效唤醒

CPU 白白消耗

2. 关键配置

accept_mutex on;

只允许一个 worker 接受新连接

其他 worker 继续处理已有请求

3. 适用场景

高并发短连接

QPS 高、连接频繁创建销毁。

阅读原文：原文链接