性能调优：先把连接模型搞对，再谈参数

连接模型三件套

# 1. worker 数：与 CPU 核数对齐，auto 自动做对
worker_processes auto;

# 2. 单 worker 连接数：十万级没问题，但系统 fd 上限必须跟上
worker_connections 20480;
#   全局并发上限 ≈ worker_processes × worker_connections ÷ 2
#   （除 2：每个客户端连接对应一个 upstream 连接）

# 3. 系统级文件描述符：不调它，上面全白搭
worker_rlimit_nofile 65535;      # Nginx 进程的 fd 上限
#   同时系统层面：ulimit -n 65535（/etc/security/limits.conf）
#   报 "too many open files" 就是这道墙先到了

events {
    use epoll;                   # Linux 默认就是 epoll，显式写出防歧义
    multi_accept on;
}

upstream 长连接：被忽略的大头

upstream app_server {
    server 10.0.0.1:8080;
    server 10.0.0.2:8080;
    keepalive 32;                          # 每台 worker 预留 32 条复用连接
}
server {
    location / {
        proxy_pass http://app_server;
        proxy_http_version 1.1;            # 长连接必须 1.1
        proxy_set_header Connection "";    # 清空 Connection 头
    }
}
# 不配的结果：Nginx 与后端每次请求都新建 TCP
#   TIME_WAIT 堆到几万（netstat 一看吓一跳），端口耗尽随机 502
# 这三行是"TIME_WAIT 暴涨"问题的标准解法，缺一不可

这是实践中收益最明显的一处优化：短连接时代三次握手加挥手，每次请求多耗几毫秒，还把端口表搅得稀烂；长连接复用后，QPS 上一个台阶，TIME_WAIT 消失。

静态发送与上传

# 静态文件：sendfile 内核直发（动静分离篇讲过），配包聚合
sendfile on;
tcp_nopush on;       # 攒满包再发，适合大文件
http {
    tcp_nodelay on;  # 小包立即发，适合交互型响应
}

# 上传与响应体：两个常见报错都从这里来
client_max_body_size 20m;              # 上传超 20M 报 413
client_body_buffer_size 128k;
proxy_buffer_size 16k;
proxy_buffers 8 32k;                   # 后端大响应的读取缓冲
# 大响应占满缓冲会落盘临时文件——别关 proxy_buffering，
# 除非 SSE/流式接口（那类接口单独 location 关掉）

压测验证：数据说话

调优不是改完就宣布胜利，要压测对比：wrk 或 ab 造流量，记录QPS、P99 延迟、错误率三个数，改一项测一项。示例流程：基线压测 → 开 upstream keepalive → 复测对比 → 保留有效项。这套"单变量加压测对比"的方法论，与 JVM 调优篇、全链路压测篇完全同源——性能优化没有玄学，只有受控实验。还有最后一个维度没覆盖：Nginx 自己挂了怎么办——下一篇高可用。