一、前言

相信对于 Nginx 你一定并不陌生，它是一款轻量级的开源 Web 服务及代理程序，因其轻量化、支持高并发等特性，目前国内企业早已广泛的使用 Nginx。既然 Nginx 使用这么广泛，那么我们在性能测试工作中如何对其进行优化和配置便成了重中之重。

二、配置优化

2.1 并发处理架构优化

2.1.1 工作进程配置

现代 CPU 多核架构下，Nginx 的 worker 进程若在不同核心间频繁调度，会增加 CPU 上下文切换损耗。CPU 亲和性通过将 worker 进程固定到特定核心，避免跨核调度，提升缓存利用率。所以就需要配置 Nginx 的 CPU 亲和性来解决这个问题。

那由于 Nginx CPU 亲和性配置本身有多套配置方案，这里推荐你直接将配置项设置成 auto（worker_cpu_affinity ），即采用了 Nginx 推荐的 CPU 绑核策略方式。另外的一个方式是手动绑定，将 worker 线程数量与 CPU 核心数一一绑定方式设置。我们设置成 auto Nginx 会自动识别并按照推荐策略来分配 worker 线程和 CPU。

配置方案：

• 自动绑定（推荐）：通过 worker_cpu_affinity auto 让 Nginx 自动识别 CPU 核心并按最优策略绑定。例如 8 核 CPU 会将 8 个 worker 进程一对一绑定到 CPU0~CPU7，实现负载均衡。
• 手动绑定：按核心数显式配置，如 worker_cpu_affinity 0001 0010 0100 1000（4 核场景）。

配置示例如下：

worker_cpu_affinity auto;     # 自动将工作进程绑定到可用的 CPU 核心
worker_processes auto;          # 基于CPU核心数动态分配工作进程，充分利用多核性能  
worker_connections 1024;       # 单进程最大并发连接数，支持高并发场景  
worker_rlimit_nofile 65535;    # 单进程文件描述符上限，突破系统资源限制  

理论并发能力：
通过多进程模型实现水平扩展，总并发量为：worker_processes × worker_connections
（例：4 核 CPU 配置下可达 4×1024=4096 并发连接）。

需结合系统级限制（如 nofile）。若未调整 sysctl，实际并发可能受限于系统默认值（通常 1024）。

# 系统级文件描述符限制
worker_rlimit_nofile 65535;  # 需在系统中同步调整（/etc/security/limits.conf）

2.1.2 事件驱动模型

Linux 系统下一切皆文件，比如打开一个设备，它便会产生一个文件描述符。在产生一个进程时，这个进程便需要一个进程描述符，这个进程描述符也是一个文件。所以在 Nginx 处理请求的时候，每一个请求都会产生处理请求的描述符。

其次，在 Nginx 处理大规模请求的时候，为了提高并发效率需要采用异步非阻塞模型，epoll 本身是以异步非阻塞模型来处理请求流中的事件流。

这里还需要注意一点，并不是所有的 Linux 操作系统都可以使用 epoll，它是在 kernel 2.6 版本以后提出的，早期内核使用的 select\poll 模型，select 模型比 epoll 模型性能要低很多。

模型对比：

• epoll（Kernel 2.6+）：异步非阻塞模型，基于事件驱动，通过 mmap 共享用户态与内核态空间，突破 select/poll 的 1024 文件描述符限制，支持百万级并发。
• select/poll：早期模型，需轮询扫描所有文件描述符，性能随并发量下降明显。

配置示例如下：

multi_accept on;            # 一次性接受所有新连接
use epoll;      # Linux高效IO多路复用，支持C10K级别并发  

2.2 传输效率优化

2.2.1 零拷贝技术

Nginx 在处理文件时，会将文件传入操作系统内核态的 Buffer Cache，然后传递到操作系统上层的用户态，经用户态的 Buffer Cache 再传回内核态中，最后通过 Socket 将文件转发出去。

通过 sendfile on 实现内核态直接传输，避免文件在用户态与内核态间的冗余拷贝。传统流程需 4 次拷贝（内核 Buffer→用户 Buffer→内核 Buffer→Socket），零拷贝仅需 2 次内核态数据搬运，尤其适合图片、视频等静态资源。

配置示例如下：

# I/O优化 - 减少带宽消耗和提高传输效率
sendfile on;                # 开启零拷贝文件传输，减少CPU消耗和内核上下文切换
tcp_nopush on;              # 优化数据包传输，减少网络报文数量，配合sendfile使用
tcp_nodelay on;             # 禁用Nagle算法，降低小数据包传输延迟

2.2.2 长连接复用

配置示例如下：

# 连接优化 - 减少TCP连接建立的开销
keepalive_timeout 65;       # 保持客户端连接超时时间(秒)，减少重复的TCP握手
keepalive_requests 100;     # 在一个keepalive连接上可处理的最大请求数

2.3 缓存体系构建

用到缓存优化主要期望提高网站服务访问效率，减少服务端的性能使用。这里缓存配置优化大致可以分为几个部分，分别是文件描述符缓存、代理缓存优化、静态资源缓存优化等。

2.3.1 文件描述符缓存

打开文件缓存设置在 Nginx 端，通常而言我们会把一些静态元素（如：JPG、CSS、GS）在代理端通过这种方式进行设置，这里 Nginx 缓存的是静态元素的元数据。元数据的作用就是缓存打开用户所请求的静态元素的文件路径等信息，那么如果在本地频繁地查找之前请求过的静态元素文件而没有缓存元数据时效率比较低，而如果我们把一部分索引数据缓存到 Nginx 的 Cache 下，这种频繁访问就可以很大地提高访问效率。

配置示例如下：

# 缓存优化 - 减少重复读取文件的开销
open_file_cache max=10000 inactive=20s;  # 缓存最多10000个文件描述符，20秒不使用则关闭
open_file_cache_valid 30s;               # 每30秒检查一次缓存中的文件描述符是否仍然有效
open_file_cache_min_uses 2;              # 文件被访问至少2次后才会被缓存，降低低频访问文件的缓存
open_file_cache_errors on;               # 同时缓存文件错误信息，避免重复访问不存在的文件

2.3.2 代理缓存

反向代理场景下缓存后端服务响应，支持 UWSGI、FastCGI 等协议。首先通过 Nginx 作代理，可以支持实现动静态的分离，静态元素直接交给 Nginx 来处理，再把后端动态数据适当作缓存。通常做这种代理+缓存的架构，是能有效的提高整体网站的访问并发性能。

配置示例如下：

# 代理缓存 - 减少对后端服务的请求
proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60mlocation / {proxy_cache my_cache;…
}

参数说明：

• proxy_cache_path 表示在本地分配哪个路径来存储并缓存后台返回数据；
• cache levels 表示存放文件的分层方式；
• my_cache:10m max_size=10g 分别表示是开辟一个名为my_cache共享块（用于统计访问次数）及缓存的单个文件的最大大小等。

这些都是做对应的缓存在本地的文件目录相关属性的一些设置。另外一块的设置表示在proxy_cache 的时候，通过 location 引用到 cache 的名称。

2.3.3 静态资源缓存

通常可以把静态元素，比如用户请求的图片、CSS 、JS 等元素缓存到客户端。这种缓存可以通过 Nginx配置中的 expires 配置项进行设置，expires 后面可以加具体的时间，也可以加对应的特定意义的数值，比如 -1 表示不缓存资源，max 设置最大周期缓存（默认缓存周期为 10 年），需要做具体的时间的设置可以写入具体的时间周期，比如一个小时或是一天。

配置示例如下：

# 静态资源缓存配置
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {  # 匹配静态资源文件扩展名expires 30d;                        # 客户端缓存30天add_header Cache-Control "public";  # 允许所有缓存服务器缓存access_log off;                     # 减少日志噪音
}

在缓存整体使用中，虽缓存越多、越靠前、命中率越高越好，但需综合考量并注意实际问题：

• 一是文件更新策略问题，配置文件后端缓存策略时，要考虑缓存删除与更新策略，确保后端数据更新能被前端用户及时感知；
• 二是缓存命中率失败给后端造成的瞬间压力，前端缓存失效等情况会给后端带来瞬间压力，网站设计时需考虑如何避免缓存失效及缓存失效时保证后端服务高可用；
• 三是多节点缓存一致性，做缓存设置时，当前端多节点保存相同内容，需考虑如何保证数据一致性，涉及缓存架构设计及前端缓存节点更新策略。

2.4 协议层深度优化

2.4.1 HTTP/2 支持

HTTP/2 作用与优势：

• 多路复用 (Multiplexing)：允许在单个 TCP 连接上并行传输多个请求/响应，彻底解决 HTTP/1.x 的队头阻塞问题，降低延迟并提升页面加载速度。
• 头部压缩 (HPACK)；使用二进制格式和静态字典压缩 HTTP 头部，减少冗余数据传输（典型场景可节省 50% 的头部大小）。
• 服务器推送 (Server Push)：可主动向客户端推送关键资源（如 CSS/JS），无需等待 HTML 解析，优化首次渲染时间。
• 流量优先级控制：允许标记资源优先级（如优先加载首屏内容），提升用户体验。

http2 on;                # 启用HTTP/2多路复用  

注意：

HTTP/2 必须基于 HTTPS，需先配置 SSL 证书。主流浏览器（Chrome/Firefox/Edge）均支持，但旧客户端（如
IE11）自动回退到 HTTP/1.x。

2.4.2 TLS优化

建议禁用不安全协议：TLSv1.0 和 TLSv1.1 存在已知漏洞（如 POODLE、BEAST），必须禁用。
另外，TLSv1.3 优势：更少握手次数（1-RTT 或 0-RTT），降低延迟。支持现代加密算法（如 ChaCha20-Poly1305），安全性更高。AES-GCM：硬件加速支持好，适合现代 CPU。

ssl_protocols TLSv1.2 TLSv1.3;        # 仅允许安全协议版本  
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256";  # 高效加密套件  
ssl_session_cache shared:SSL:10m;     # 10MB共享内存缓存SSL会话  
ssl_session_timeout 10m;              # 会话超时时间  

2.5 资源处理优化

Nginx 基础配置优化的最后一项是文件压缩，我们希望做到 Nginx 服务端往客户端发送的数据越小，占用的延迟越低用户体验便会越好。所以往往在代理或 Nginx 中会设置文件压缩，我们通过 gzip 压缩文本类资源（HTML/CSS/JS），降低带宽占用。典型配置如下：

2.5.1 压缩与大文件支持

 # Gzip压缩配置 - 显著减少传输数据量，节省带宽gzip on;                    # 启用gzip压缩，可减少传输数据量40%-70%gzip_comp_level 6;          # 压缩级别(1-9)，一般来说推荐你设置成 6 就比较合适gzip_min_length 256;        # 最小压缩文件大小(字节)，小于此值的文件不压缩gzip_proxied any;           # 对所有代理请求进行压缩，包括反向代理的响应gzip_vary on;               # 添加Vary: Accept-Encoding响应头，正确处理缓存gzip_http_version 1.1;      # 使用HTTP 1.1版本，支持gzip压缩gzip_types text/plain              # 压缩纯文本text/css                # 压缩CSStext/xml                # 压缩XMLtext/javascript         # 压缩JSapplication/javascript  # 压缩JSapplication/json        # 压缩JSONapplication/xml         # 压缩XMLapplication/xml+rss     # 压缩RSSimage/svg+xml           # 压缩SVG图片font/eot               # 压缩EOT字体font/otf               # 压缩OTF字体font/ttf               # 压缩TTF字体application/octet-stream;  # 压缩二进制文件流gzip_disable "MSIE [1-6]\."; # 对IE6及以下浏览器禁用gzip，避免兼容性问题gzip_static on;             # 优先使用预压缩.gz文件，减少CPU使用率

2.5.2 大文件支持

若业务需要用户上传大文件（如视频、高清图片），若 API 接口接收 JSON/POST 数据（如大数据分析场景），需根据需求调整限制。

client_max_body_size 500M;            # 允许上传500MB文件  

2.6 内存管理优化

2.6.1 缓冲区与共享内存

HTTPS 建连需多次加密协商，通过ssl_session_cache缓存会话密钥（SessionKey），减少重复握手。

gzip_buffers 16 8k;                   # 128KB压缩缓冲区  
proxy_buffering off;                  # 关闭代理缓冲，实时传输  
ssl_session_cache shared:SSL:10m;     # SSL会话共享内存  
ssl_session_timeout 10m;             # 设置 SSL 会话超时时间为 10 分钟

通过在 Nginx 中添加 ssl_session_cache 配置，配置中分配 Nginx 在处理 SSL 会话所需要开辟的共享内存的空间，我这里这里设置值为 10 MB，第二个参数就是设置 SSL SessionKey 的超时时间，这里设置的为 10 分钟，也就是每隔 10 分钟需要重新再进行一次建联，这是一个在服务端的超时时间。

三、总结

通过以上配置，我们能达到以下目标：

• 1.并发能力：支持 worker_processes × worker_connections 的并发连接（如4核CPU：4×1024=4096并发）。
• 2.传输效率：通过HTTP/2多路复用、零拷贝、长连接复用，减少50%以上的网络延迟。
• 3.缓存命中率：静态资源缓存30天，文件描述符缓存减少 80 %的磁盘IO。
• 4.性能平衡：SSL会话复用降低 50 %握手开销。

终极目录即构建毫秒级响应、C10K级别（万级并发）并发处理能力，适用于高并发、高安全、低带宽要求的Web服务场景。

NGINX高性能配置示例：

• https://github.com/zuozewei/blog-example/tree/master/Operations/NGINX