4.8.2　核心配置優化

4.3節中的Nginx配置可進行的優化如下。

1）worker_processes：表示worker進程數量。worker_processes默認情況下為1，官方的建議是修改成CPU的內核數，增加worker_processes數量，充分利用I/O帶寬，以減小機器I/O帶來的影響。

服務器A 2C/4G，測試運行結果如下：

• 設置worker_processes=1，打開2個線程，其中有一個是主線程，運行很穩定；
• 設置worker_processes=2，打開3個線程，其中有一個是主線程，運行相對較穩，高并發請求時會出現502的錯誤；
• 設置worker_processes=4，打開5個線程，其中有一個是主線程，運行很穩定。

2）worker_connections：表示work進程連接數量，默認是1024。worker_connections優化需要考量兩個指標，即內存和操作系統級別的“進程最大可打開文件數”。建議設置到65535，可根據內存自行調整。

• 內存：每個連接數分別對應一個read_event、一個write_event事件。一個連接數大概占用232B，2個事件共占用96B，所以一個連接總共占用328B。100W連接大概占用100W*328/1024/1024～=310MB。
• 進程最大可打開文件數：受限于操作系統，通過ulimit -n命令可查詢，默認是1024，建議設置為65535。

3）keepalive_timeout：表示KeepAlive的超時時間，指定每個TCP連接最多可以保持多長時間。Nginx的默認值是75秒。

【示例】　以電商網站上傳附件功能為例，客戶端使用Nginx反向代理。

對于電商后臺管理模塊來說，運營人員每天會定時上傳商品的附件，有時上傳的附件較大，需要等待很久服務器才響應，有時候超過默認值后會提示“超時”等現象。經日志分析請求發現，超時等問題和Nginx的keepalive_timeout配置項相關。頁面請求后端采用HTTP方式。由于HTTP底層采用TCP協議網絡傳輸，故當上傳附件時頁面會向服務端發送一個請求，由于附件過大，上傳處理時間超過了TCP連接最多可以保持時間，從而導致“超時”等異常。

評估附件上傳的平均時長后，更改keepalive_timeout默認配置項，將其調整到500，運行過程中不再出現“超時”等現象。在后續運行過程中，發現批量上傳的視頻數量較多時，會出現部分視頻上傳失敗的問題，日志提示“socket() failed (24: Too many open files) while connecting to upstream”。分析可知，是連接數不夠，于是調制worker_connections默認連接數到8729。之后批量上傳視頻時，在視頻的大小均衡且總數量偏小的情況下功能正常。但當出現視頻大小不均衡并且總數量偏大情況，部分視頻還會上傳失敗。

繼續分析日志，發現由于keepalive_timeout設置過長，在上傳視頻時，有些請求傳輸的過程會很快執行完畢，如果超時時間設置過長，因處理完畢的請求連接沒有被釋放掉，所以會導致請求過多積累后會出現異常。

那么如何合理設置keepalive_timeout的時間呢？

優化思路：在存在一些業務功能比較耗時的情況下，可以優化程序，比如采用同步轉異步、多線程等優化手段，這樣可提高應用程序整體的執行效率，減少響應時間。不要因為業務功能而犧牲其他網絡、系統、代理相關的服務，由于部分瀏覽器僅支持最多保持在60s左右，所以把keepalive_timeout調整到60s左右比較合理，如keepalive_timeout 60。

4）gzip：表示Nginx采用Gzip壓縮的形式發送數據。這將減少我們發送的數據量，建議開啟該功能，即gzip on。

5）gzip_proxied：允許或者禁止壓縮基于請求和響應的響應流。比如，gzip_proxied any表示壓縮所有的請求。

6）gzip_min_length：表示數據啟用壓縮的最少字節數，建議請求大于1KB及以上時進行壓縮，如gzip_min_length 1000。壓縮過小的數據會降低處理此請求的所有進程的速度。

7）gzip_comp_level：表示開啟Gzip壓縮。Gzip的壓縮參數值的范圍是1到9，那么，將其設置為多少合適呢？

【示例】　靜態文件包括4個H5文件、4個JS、2個CSS文件，合計大小為380KB，設置gzip_comp_level參數從1到9的結果如下：

• gzip_comp_level=1，資源文件大小為160KB；
• gzip_comp_level=2，資源文件大小為150KB；
• gzip_comp_level=3，資源文件大小為142KB；
• gzip_comp_level=4，資源文件大小為127KB；
• gzip_comp_level=5，資源文件大小為119KB；
• gzip_comp_level=6，資源文件大小為102KB；
• gzip_comp_level=7，資源文件大小為102KB；
• gzip_comp_level=8，資源文件大小為97KB；
• gzip_comp_level=9，資源文件大小為97KB。

隨著壓縮比例升高，CPU消耗也不斷升高，正常虛擬機2C/4G建議設置為4，4C/8G建設設置為5。建議根據服務器的配置取值4或5即可。

8）gzip_type：設置需要壓縮的數據格式。如gzip_type text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript。

9）access_log：設置Nginx是否存儲訪問日志。如有其他日志記錄，建議關閉這個選項，這樣可以有效讓讀取磁盤的I/O操作執行得更快，如access_log off。

10）sendfile：表示是否使用sendfile來傳輸文件，若使用，可實現在兩個文件描述符之間直接傳遞數據（完全在內核中操作），從而避免數據在內核緩沖區和用戶緩沖區之間的重復拷貝，提高操作效率，被稱為零拷貝。建議開啟，即sendfile on。

11）tcp_nopush：表示Nginx在一個數據包里發送所有頭文件，而不是一個接一個地發送。建議開啟，即tcp_nopush on。

12）tcp_nodelay：表示Nginx不要緩存數據，而是一段一段地發送。當需要及時發送數據時，就應該給應用設置這個屬性，這樣發送一小塊數據信息時就不能立即得到返回值。建議開啟，即tcp_nodelay on。

13）reset_timeout_connection：關閉不響應的客戶端連接，釋放客戶端占有的內存空間。

14）client_header_buffer_size：表示為請求頭分配一個緩沖區，這樣能減少一次內存分配。當大部分請求頭很大時，建議設置client_header_buffer_size。

15）large_client_header_buffers：表示請求中只有少量請求頭很大，僅需在處理大頭部時分配更多的空間，從而減少無謂的內存浪費。

16）client_body_buffer_size：表示處理客戶端請求體buffer的大小。設置緩沖區buffer大小，可用來處理POST請求數據、上傳文件。緩沖區過小會導致Nginx把內容寫到磁盤，使用臨時文件存儲response，會引起磁盤讀寫I/O。