一、前言

相信對于 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