摘要：配置如下指令是設(shè)定的工作模式及連接數(shù)上限。指令用來指定的工作模式。該參數(shù)默認是，建議開啟。配置進程的最大打開文件數(shù)調(diào)整配置進程的最大打開文件數(shù)，這個控制連接數(shù)的參數(shù)為。但副作用是資源更新可能無法及時。

工作上，需要配置 Nginx，要投入生產(chǎn)使用，做了一點優(yōu)化工作，加上以前也經(jīng)常折騰 Nginx，故記下一些優(yōu)化工作。

配置參數(shù)如下：

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

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

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

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

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

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

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

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

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

配置如下：

events {
  use epoll;
}

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

通過調(diào)整控制連接數(shù)的參數(shù)來調(diào)整 Nginx 單個進程允許的客戶端最大連接數(shù)。

events {
  worker_connections 20480;
}

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

最大連接數(shù)的計算公式如下：

max_clients = worker_processes * worker_connections;

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

max_clients = worker_processes * worker_connections / 4;

另外，進程的最大連接數(shù)受 Linux 系統(tǒng)進程的最大打開文件數(shù)限制，在執(zhí)行操作系統(tǒng)命令 ulimit -HSn 65535或配置相應(yīng)文件后， worker_connections 的設(shè)置才能生效。

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

events {
  multi_accept on;
}

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

worker_rlimit_nofile 65535;

可設(shè)置為系統(tǒng)優(yōu)化后的 ulimit -HSn 的結(jié)果

http {
  server_names_hash_bucket_size 128;
}

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

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

http {
  sendfile on;
  tcp_nopush on;

  keepalive_timeout 120;
  tcp_nodelay on;
}

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

TCP_NOPUSH 是 FreeBSD 的一個 socket 選項，對應(yīng) Linux 的 TCP_CORK，Nginx 里統(tǒng)一用 tcp_nopush 來控制它，并且只有在啟用了 sendfile 之后才生效。啟用它之后，數(shù)據(jù)包會累計到一定大小之后才會發(fā)送，減小了額外開銷，提高網(wǎng)絡(luò)效率。

TCP_NODELAY 也是一個 socket 選項，啟用后會禁用 Nagle 算法，盡快發(fā)送數(shù)據(jù)，某些情況下可以節(jié)約 200ms（Nagle 算法原理是：在發(fā)出去的數(shù)據(jù)還未被確認之前，新生成的小數(shù)據(jù)先存起來，湊滿一個 MSS 或者等到收到確認后再發(fā)送）。Nginx 只會針對處于 keep-alive 狀態(tài)的 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;
}

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

9.1、Gzip 壓縮

我們在上線前，代碼（JS、CSS 和 HTML）會做壓縮，圖片也會做壓縮（PNGOUT、Pngcrush、JpegOptim、Gifsicle 等）。對于文本文件，在服務(wù)端發(fā)送響應(yīng)之前進行 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)";
}

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

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

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

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

9.2、Brotli 壓縮

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

需要安裝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 共存在一個配置文件中

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

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;
    }
}

收官~

首發(fā)于 https://www.linpx.com