nginx高性能核心在于高效接入、合理分发与资源协同：必须显式配置use epoll;，worker_connections需匹配系统文件描述符限制，启用multi_accept on;和accept_mutex on;协同优化连接调度，并结合keepalive_timeout与内核tcp参数加速连接回收。
核心是让 Nginx 更快地“听”到连接、“接”住连接、“分”给 worker，同时避免资源争抢和浪费。关键不在堆参数，而在匹配业务场景与系统能力。
选对事件模型：Linux 必须用 epoll
Linux 下默认可能回退到低效的 select 或 poll，必须显式指定 epoll。它基于内核就绪通知，时间复杂度 O(1)，能稳定支撑 10 万级并发；而轮询方式在连接数过几千后性能会断崖下跌。
- 配置写法：
use epoll;，放在events { }块内 - Docker 环境需确认基础镜像内核 ≥ 2.6（主流发行版默认满足）
- 可通过
nginx -V 2>&1 | grep -o with-epoll验证编译是否支持
设准 worker_connections：匹配系统文件描述符上限
这个值不是越大越好，它直接受限于系统允许打开的文件描述符（fd）总数。设高了启动失败，设低了浪费资源。
- 先查限制：
ulimit -n（用户级），sysctl fs.file-max（系统级） - 永久放宽：
/etc/security/limits.conf中为 nginx 用户加两行：* soft nofile 65535* hard nofile 65535 - 若用 systemd 启动，还要检查
nginx.service是否覆盖了LimitNOFILE= - 建议预留 10%～20% fd 给日志、上游连接等，别把理论值用满
调优连接调度：multi_accept 与 accept_mutex 协同控制
新连接到来时，Linux 默认会唤醒所有空闲 worker（惊群），但只有一个能真正 accept 成功——这对短连接密集型服务尤其低效。
-
multi_accept on;：让单个 worker 一次尽可能多收就绪连接，减少系统调用和唤醒次数 -
accept_mutex on;（Nginx 1.11.3 后默认 off，但高并发建议显式开启）：让 worker 轮流获取 accept 锁，避免锁争抢集中在某个进程 - API 网关等短连接场景可尝试
accept_mutex off;，前提是内核 ≥ 3.9 + Nginx ≥ 1.9.1，且已启用SO_REUSEPORT
配合内核与超时设置，加速连接回收
events 块管“接入”，但连接释放快不快，还取决于 http 块超时策略和系统 TCP 参数。
- 短连接场景（如 API）：
keepalive_timeout 0;或5s，主动关闭复用 - 搭配
reset_timedout_connection on;：对超时 keepalive 连接发 RST，比 FIN 更快回收 socket - 系统层配合：
net.ipv4.tcp_tw_reuse = 1（代理场景尤其有用）、net.core.somaxconn = 65535（扩全连接队列）
