工作上，需要配置 Nginx，要投入生產使用，做了一點優化工作，加上以前也經常折騰 Nginx，故記下一些優化工作。

優化 Nginx 進程數量

配置參數如下：

worker_processes 1; # 指定 Nginx 要開啟的進程數，結尾的數字就是進程的個數，可以為 auto

這個參數調整的是 Nginx 服務的 worker 進程數，Nginx 有 Master 進程和 worker 進程之分，Master 為管理進程、真正接待“顧客”的是 worker 進程。

進程個數的策略：worker 進程數可以設置為等于 CPU 的核數。高流量高并發場合也可以考慮將進程數提高至 CPU 核數 x 2。這個參數除了要和 CPU 核數匹配之外，也與硬盤存儲的數據及系統的負載有關，設置為 CPU 核數是個好的起始配置，也是官方建議的。

當然，如果想省麻煩也可以配置為worker_processes auto;，將由 Nginx 自行決定 worker 數量。當訪問量快速增加時，Nginx 就會臨時 fork 新進程來縮短系統的瞬時開銷和降低服務的時間。

將不同的進程綁定到不同的CPU

默認情況下，Nginx 的多個進程有可能運行在同一個 CPU 核上，導致 Nginx 進程使用硬件的資源不均，這就需要制定進程分配到指定的 CPU 核上處理，達到充分有效利用硬件的目的。配置參數如下：

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

其中 worker_cpu_affinity 就是配置 Nginx 進程與 CPU 親和力的參數，即把不同的進程分給不同的 CPU 核處理。這里的0001 0010 0100 1000是掩碼，分別代表第1、2、3、4核CPU。上述配置會為每個進程分配一核CPU處理。

當然，如果想省麻煩也可以配置worker_cpu_affinity auto;，將由 Nginx 按需自動分配。

Nginx 事件處理模型優化

Nginx 的連接處理機制在不同的操作系統中會采用不同的 I/O 模型，在 linux 下，Nginx 使用 epoll 的 I/O 多路復用模型，在 Freebsd 中使用 kqueue 的 I/O 多路復用模型，在 Solaris 中使用 /dev/poll 方式的 I/O 多路復用模型，在 Windows 中使用 icop，等等。

配置如下：

events {use epoll;
}

events 指令是設定 Nginx 的工作模式及連接數上限。use指令用來指定 Nginx 的工作模式。Nginx 支持的工作模式有 select、 poll、 kqueue、 epoll 、 rtsig 和/ dev/poll。當然，也可以不指定事件處理模型，Nginx 會自動選擇最佳的事件處理模型。

單個進程允許的客戶端最大連接數

通過調整控制連接數的參數來調整 Nginx 單個進程允許的客戶端最大連接數。

events {worker_connections 20480;
}

worker_connections 也是個事件模塊指令，用于定義 Nginx 每個進程的最大連接數，默認是 1024。

最大連接數的計算公式如下：

max_clients = worker_processes * worker_connections;

如果作為反向代理，因為瀏覽器默認會開啟 2 個連接到 server，而且 Nginx 還會使用fds（file descriptor）從同一個連接池建立連接到 upstream 后端。則最大連接數的計算公式如下：

max_clients = worker_processes * worker_connections / 4;

另外，進程的最大連接數受 Linux 系統進程的最大打開文件數限制，在執行操作系統命令 ulimit -HSn 65535或配置相應文件后， worker_connections 的設置才能生效。

配置獲取更多連接數

默認情況下，Nginx 進程只會在一個時刻接收一個新的連接，我們可以配置multi_accept 為 on，實現在一個時刻內可以接收多個新的連接，提高處理效率。該參數默認是 off，建議開啟。

events {multi_accept on;
}

配置 worker 進程的最大打開文件數

調整配置 Nginx worker 進程的最大打開文件數，這個控制連接數的參數為 worker_rlimit_nofile。該參數的實際配置如下:

worker_rlimit_nofile 65535;

可設置為系統優化后的 ulimit -HSn 的結果

優化域名的散列表大小

http {server_names_hash_bucket_size 128;
}

參數作用:設置存放域名( server names)的最大散列表的存儲桶( bucket)的大小。 默認值依賴 CPU 的緩存行。

server_names_hash_bucket_size 的值是不能帶單位 的。配置主機時必須設置該值，否則無法運行 Nginx，或者無法通過測試 。 該設置與 server_ names_hash_max_size 共同控制保存服務器名的 hash 表， hash bucket size 總是等于 hash 表的大小， 并且是一路處理器緩存大小的倍數。若 hash bucket size 等于一路處理器緩存的大小，那么在查找鍵時， 最壞的情況下在內存中查找的次數為 2。第一次是確定存儲單元的地址，第二次是在存儲單元中查找鍵值 。 若報 出 hash max size 或 hash bucket size 的提示，則需要增加 server_names_hash_max size 的值。

TCP 優化

http {sendfile on;tcp_nopush on;keepalive_timeout 120;tcp_nodelay on;
}

第一行的 sendfile 配置可以提高 Nginx 靜態資源托管效率。sendfile 是一個系統調用，直接在內核空間完成文件發送，不需要先 read 再 write，沒有上下文切換開銷。

TCP_NOPUSH 是 FreeBSD 的一個 socket 選項，對應 Linux 的 TCP_CORK，Nginx 里統一用 tcp_nopush 來控制它，并且只有在啟用了 sendfile 之后才生效。啟用它之后，數據包會累計到一定大小之后才會發送，減小了額外開銷，提高網絡效率。

TCP_NODELAY 也是一個 socket 選項，啟用后會禁用 Nagle 算法，盡快發送數據，某些情況下可以節約 200ms（Nagle 算法原理是：在發出去的數據還未被確認之前，新生成的小數據先存起來，湊滿一個 MSS 或者等到收到確認后再發送）。Nginx 只會針對處于 keep-alive 狀態的 TCP 連接才會啟用 tcp_nodelay。

優化連接參數

http {client_header_buffer_size 32k;large_client_header_buffers 4 32k;client_max_body_size 1024m;client_body_buffer_size 10m;
}

這部分更多是更具業務場景來決定的。例如client_max_body_size用來決定請求體的大小，用來限制上傳文件的大小。上面列出的參數可以作為起始參數。

配置壓縮優化

9.1、Gzip 壓縮

我們在上線前，代碼（JS、CSS 和 HTML）會做壓縮，圖片也會做壓縮（PNGOUT、Pngcrush、JpegOptim、Gifsicle 等）。對于文本文件，在服務端發送響應之前進行 GZip 壓縮也很重要，通常壓縮后的文本大小會減小到原來的 1/4 - 1/3。

http {gzip on;gzip_buffers 16 8k;gzip_comp_level 6;gzip_http_version 1.0;gzip_min_length 1000;gzip_proxied any;gzip_vary on;gzip_typestext/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xmltext/javascript application/javascript application/x-javascripttext/x-json application/json application/x-web-app-manifest+jsontext/css text/plain text/x-componentfont/opentype application/x-font-ttf application/vnd.ms-fontobjectimage/x-icon;gzip_disable "MSIE [1-6]\.(?!.*SV1)";
}

這部分內容比較簡單，只有兩個地方需要解釋下：

gzip_vary 用來輸出 Vary 響應頭，用來解決某些緩存服務的一個問題，詳情請看我之前的博客：HTTP 協議中 Vary 的一些研究。

gzip_disable 指令接受一個正則表達式，當請求頭中的 UserAgent 字段滿足這個正則時，響應不會啟用 GZip，這是為了解決在某些瀏覽器啟用 GZip 帶來的問題。

默認 Nginx 只會針對 HTTP/1.1 及以上的請求才會啟用 GZip，因為部分早期的 HTTP/1.0 客戶端在處理 GZip 時有 Bug。現在基本上可以忽略這種情況，于是可以指定 gzip_http_version 1.0 來針對 HTTP/1.0 及以上的請求開啟 GZip。

9.2、Brotli 壓縮

Brotli 是基于LZ77算法的一個現代變體、霍夫曼編碼和二階上下文建模。Google軟件工程師在2015年9月發布了包含通用無損數據壓縮的Brotli增強版本，特別側重于HTTP壓縮。其中的編碼器被部分改寫以提高壓縮比，編碼器和解碼器都提高了速度，流式API已被改進，增加更多壓縮質量級別。

需要安裝libbrotli 、ngx_brotli ，重新編譯 Nginx 時，帶上--add-module=/path/to/ngx_brotli即可，然后配置如下

http {brotli on;brotli_comp_level 6;brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;
}

Brotli 可與 Gzip 共存在一個配置文件中

靜態資源優化

靜態資源優化，可以減少連接請求數，同時也不需要對這些資源請求打印日志。但副作用是資源更新可能無法及時。

server {# 圖片、視頻location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|flv|mp4|ico)$ {expires 30d;access_log off;}# 字體location ~ .*\.(eot|ttf|otf|woff|svg)$ {expires 30d;access_log off;}# js、csslocation ~ .*\.(js|css)?$ {expires 7d;access_log off;}
}

---

收官~

首發于 https://www.linpx.com