NGINX 的性能調優寶典
NGINX 是衆所周知的高性能負載均衡器、緩存和 web 服務器,爲世界上 40% 以上最繁忙的網站供電。對於大多數用例,默認的 NGINX 和 Linux 設置工作得很好,但是要獲得最佳性能有時需要進行一些調整。這篇博客文章討論了在優化系統時要考慮的一些 NGINX 和 Linux 設置。
幾乎可以對任何設置進行優化,但本文將集中討論少數幾個對大多數用戶有利的設置。只有當您對 NGINX 和 Linux 有了深入的瞭解,或者按照我們的支持或專業服務團隊的指導,我們才建議您更改某些設置,這裏不介紹這些設置。專業服務團隊與世界上一些最繁忙的網站合作,優化 NGINX 以獲得最高級別的性能,並可與您一起充分利用 NGINX 或 NGINX Plus 部署。
介紹
假設對 NGINX 架構和配置概念有基本的瞭解。本文並不試圖複製 NGINX 文檔,而是提供了各種選項的概述以及到相關文檔的鏈接。
優化時要遵循的一個好規則是一次更改一個設置,如果更改不能提高性能,則將其設置回默認值。
我們首先討論 Linux 的調優,因爲某些操作系統設置的值決定了如何調優 NGINX 配置。
調整 Linux 配置
現代 Linux 內核(2.6+)中的設置適用於大多數目的,但更改其中的一些設置可能是有益的。檢查內核日誌中指示設置過低的錯誤消息,並根據建議進行調整。在這裏,我們只討論那些在正常工作負載下最有可能從優化中受益的設置。有關調整這些設置的詳細信息,請參閱 Linux 文檔。
積壓隊列(The Backlog Queue)
以下設置與連接及其排隊方式相關。如果傳入連接的速率很高,並且性能水平參差不齊(例如,某些連接似乎處於暫停狀態),則更改這些設置可能會有所幫助。
-
net.core.somaxconn–可排隊等待 NGINX 接受的最大連接數。默認值通常很低,這通常是可以接受的,因爲 NGINX 可以很快接受連接,但如果您的網站遇到大量流量,則可以增加它。如果內核日誌中的錯誤消息指示該值太小,請增大該值,直到錯誤停止。
-
注意:如果將其設置爲大於 512 的值,請將 backlog 參數更改爲 NGINX listen 指令以進行匹配。
-
net.core.netdev_max_backlog–在將數據包交給 CPU 之前,網卡緩衝數據包的速率。增加該值可以提高具有高帶寬的計算機上的性能。檢查內核日誌中是否存在與此設置相關的錯誤,並參考網卡文檔中有關更改此設置的建議。
描述器
文件描述符是用於表示連接和打開的文件等的操作系統資源。NGINX 每個連接最多可以使用兩個文件描述符。例如,如果 NGINX 正在代理,它通常使用一個文件描述符作爲客戶端連接,另一個用於連接到代理服務器,儘管如果使用 HTTP keepalives,這個比率要低得多。對於提供大量連接的系統,可能需要調整以下設置:
- nofile–在 / etc/security/limits.conf 文件中設置的用戶文件描述符限制
短暫的端口(Ephemeral Ports)
當 NGINX 充當代理時,到上游服務器的每個連接都使用一個臨時或短暫的端口。您可能需要更改此設置:
- net.ipv4.ip_local_port_range–端口值範圍的開始和結束。如果發現端口不足,請增大範圍。常見的設置是端口 1024 到 65000。
調整 NGINX 配置
下面是一些可以影響性能的 NGINX 指令。如上所述,我們只討論對您自己調整安全的指令。我們建議您不要在沒有 NGINX 團隊指導的情況下更改其他指令的設置。
工作進程(Worker Processes)
NGINX 可以運行多個工作進程,每個進程都能夠處理大量的同時連接。您可以使用以下指令控制工作進程的數量以及它們如何處理連接:
保持連接(Keepalive Connections)
Keepalive 連接可以減少打開和關閉連接所需的 CPU 和網絡開銷,從而對性能產生重大影響。NGINX 終止所有客戶端連接,並創建到上游服務器的獨立連接。NGINX 支持客戶端和上游服務器的 keepalives。以下指令與客戶端 keepalives 相關:
-
keepalive_requests –客戶端可以通過單個 keepalive 連接發出的請求數。默認值爲 100,但更高的值對於使用負載生成工具進行測試尤其有用,該工具通常從單個客戶端發送大量請求。
-
keepalive_timeout - 空閒 keepalive 連接保持打開的時間。
以下指令與上游保持連接有關:
- keepalive–到上游服務器的空閒 keepalive 連接數,每個工作進程都保持打開狀態。沒有默認值。
要啓用到上游服務器的 keepalive 連接,還必須在配置中包含以下指令:
proxy_http_version 1.1;
proxy_set_header Connection "";
訪問日誌記錄
記錄每個請求會佔用 CPU 和 I/O 週期,減少影響的一種方法是啓用訪問日誌緩衝。使用緩衝,NGINX 不會對每個日誌條目執行單獨的寫操作,而是緩衝一系列條目,並在單個操作中將它們一起寫入文件。
要啓用訪問日誌緩衝,請將 buffer=size 參數包含到 access_log 指令中;NGINX 在緩衝區達到 size 值時將緩衝區內容寫入日誌。要讓 NGINX 在指定時間後寫入緩衝區,請包含 flush=time 參數。當設置了這兩個參數時,NGINX 會在下一個日誌條目無法放入緩衝區或緩衝區中的條目分別早於指定的時間時將條目寫入日誌文件。當工作進程重新打開其日誌文件或關閉時,也會寫入日誌項。要完全禁用訪問日誌記錄,請將 off 參數包含到 access_log 指令中。
發送文件(Sendfile)
操作系統的 sendfile()系統調用將數據從一個文件描述符複製到另一個文件描述符,通常實現零拷貝,這可以加快 TCP 數據傳輸。要使 NGINX 能夠使用它,請在 http 上下文或服務器或位置上下文中包含 sendfile 指令。然後,NGINX 可以將緩存或磁盤上的內容寫入套接字,而無需將任何上下文切換到用戶空間,從而使寫入速度極快,佔用更少的 CPU 週期。但是,請注意,由於使用 sendfile()複製的數據繞過了用戶空間,因此它不受常規 NGINX 處理鏈和更改內容的過濾器(如 gzip)的約束。當配置上下文同時包含 sendfile 指令和激活內容更改篩選器的指令時,NGINX 會自動爲該上下文禁用 sendfile。
限制
您可以設置各種限制,幫助防止客戶端消耗太多資源,這可能會對系統性能以及安全性和用戶體驗造成不利影響。以下是一些相關指令:
-
limit_conn and limit_conn_zone–限制 NGINX 接受的客戶端連接數,例如從單個 IP 地址。設置它們有助於防止單個客戶端打開過多的連接並消耗超過其資源份額的資源。
-
limit_rate–限制每個連接將響應傳輸到客戶端的速率(以便打開多個連接的客戶端可以爲每個連接消耗此數量的帶寬)。設置限制可以防止系統被某些客戶端過載,從而確保所有客戶端的服務質量更加均勻。
-
limit_req and limit_req_zone–限制 NGINX 處理請求的速率,這與設置 limit_rate 有相同的好處。它們還可以提高安全性,特別是登錄頁面的安全性,方法是將請求速率限制爲對人類用戶合理的值,但對於試圖用請求壓倒應用程序的程序(如 DDoS 攻擊中的機器人程序)來說太慢。
-
上游配置塊中服務器指令的 max_conns 參數 - 設置上游組中服務器同時接受的最大連接數。設置一個限制可以幫助防止上游服務器過載。將該值設置爲 0(零,默認值)意味着沒有限制。
-
queue(NGINX Plus)–創建一個隊列,當上遊組中的所有可用服務器都達到最大連接數限制時,將在其中放置請求。此指令設置隊列中請求的最大數量,還可以選擇設置在返回錯誤之前它們等待的最長時間(默認爲 60 秒)。如果省略此指令,則請求不會排隊。
緩存和壓縮可以提高性能
NGINX 可以用來提高 web 應用程序性能的一些附加特性實際上並不屬於優化的範疇,但值得一提的是,它們的影響是相當大的。它們包括緩存和壓縮。
緩存
通過在 NGINX 實例上啓用緩存(NGINX 實例是一組 web 或應用程序服務器的負載平衡),可以顯著提高對客戶端的響應時間,同時顯著減少後端服務器上的負載。緩存本身就是一個主題,我們不會在這裏討論它。請參閱 NGINX Plus 管理指南。
壓縮
壓縮發送到客戶端的響應可以大大減小它們的大小,因此它們使用較少的網絡帶寬。然而,由於壓縮數據會消耗 CPU 資源,因此當確實值得減少帶寬使用時,它是最有用的。需要注意的是,不應爲已壓縮的對象(如 JPEG 文件)啓用壓縮。有關更多信息,請參閱 NGINX Plus 管理指南。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/iNdzDNhDjQ2Tv0g8wA4lCQ