原文：https://www.linpx.com/p/11-nginx-parameter-performance-optimization-suggestions.html
工作上，需要配置 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用來決定請求體的大小，用來限制上傳文件的大小。上面列出的參數可以作為起始參數。
配置壓縮優化
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_types text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml text/javascript application/javascript application/x-javascript text/x-json application/json application/x-web-app-manifest+json text/css text/plain text/x-component font/opentype application/x-font-ttf application/vnd.ms-fontobject image/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。
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、css location ~ .*\.(js|css)?$ { expires 7d; access_log off; } }收官~