Nginx 教程(2):效能
大家好,分享即關愛,我們很樂意和你分享一些新的知識,我們準備了一個 Nginx 的教程,分為三個系列,如果你對 Nginx 有所耳聞,或者想增進 Nginx 方面的經驗和理解,那麼恭喜你來對地方了。
我們會告訴你 Nginx 如何工作及其背後的理念,還有如何優化以加快應用的效能,如何安裝啟動和保持執行。
這個教程有三個部分:
- 基本概念 —— 這部分需要去了解 Nginx 的一些指令和使用場景,繼承模型,以及 Nginx 如何選擇 server 塊,location 的順序。
- 效能 —— 介紹改善 Nginx 速度的方法和技巧,我們會在這裡談及 gzip 壓縮,快取,buffer 和超時。
- SSL 安裝 —— 如何配置伺服器使用 HTTPS
建立這個系列,我們希望,一是作為參考書,可以通過快速查詢到相關問題(比如 gzip 壓縮,SSL 等)的解決方式,也可以直接通讀全文。為了獲得更好的學習效果,我們建議你在本機安裝 Nginx 並且嘗試進行實踐。
tcp_nodelay
, tcp_nopush
和 sendfile
tcp_nodelay
在 TCP 發展早期,工程師需要面對流量衝突和堵塞的問題,其中湧現了大批的解決方案,其中之一是由 John Nagle 提出的演算法。
Nagle 的演算法旨在防止通訊被大量的小包淹沒。該理論不涉及全尺寸 tcp 包(最大報文長度,簡稱 MSS)的處理。只針對比 MSS 小的包,只有當接收方成功地將以前的包(ACK)的所有確認傳送回來時,這些包才會被髮送。在等待期間,傳送方可以緩衝更多的資料之後再發送。
1234567 | if package.size >= MSS.size send(package)elsif acks.all_received? send(package)else # acumulate data |
與此同時,誕生了另一個理論,延時 ACK
在 TCP 通訊中,在傳送資料後,需要接收回應包(ACK)來確認資料被成功傳達。
延時 ACK 旨在解決線路被大量的 ACK 包擁堵的狀況。為了減少 ACK 包的數量,接收者等待需要回傳的資料加上 ACK 包回傳給傳送方,如果沒有資料需要回傳,必須在至少每 2 個 MSS,或每 200 至 500 毫秒內傳送 ACK(以防我們不再收到包)。
1234567 | if packages.any? sendelsif last_ack_send_more_than_2MSS_ago? || 200_ms_timer.finished? sendelse # waitend |
正如你可能在一開始就注意到的那樣 —— 這可能會導致在持久連線上的一些暫時的死鎖。讓我們重現它!
假設:
- 初始擁塞視窗等於 2。擁塞視窗是另一個 TCP 機制的一部分,稱為慢啟動。細節現在並不重要,只要記住它限制了一次可以傳送多少個包。在第一次往返中,我們可以傳送 2 個 MSS 包。在第二次傳送中:4 個 MSS 包,第三次傳送中:8 個MSS,依此類推。
- 4 個已快取的等待發送的資料包:A, B, C, D
- A, B, C是 MSS 包
- D 是一個小包
場景:
- 由於是初始的擁塞視窗,傳送端被允許傳送兩個包:A 和 B
- 接收端在成功獲得這兩個包之後,傳送一個 ACK
- 發件端傳送 C 包。然而,Nagle 卻阻止它傳送 D 包(包長度太小,等待 C 的ACK)
- 在接收端,延遲 ACK 使他無法傳送 ACK(每隔 2 個包或每隔 200 毫秒傳送一次)
- 在 200ms 之後,接收器傳送 C 包的 ACK
- 傳送端收到 ACK 併發送 D 包
在這個資料交換過程中,由於 Nagel 和延遲 ACK 之間的死鎖,引入了 200ms 的延遲。
Nagle 演算法是當時真正的救世主,而且目前仍然具有極大的價值。但在大多數情況下,我們不會在我們的網站上使用它,因此可以通過新增 TCP_NODELAY 標誌來安全地關閉它。
1 | tcp_nodelay on; # sets TCP_NODELAY flag, used on keep-alive connections |
享受這200ms提速吧!
更多的細節,推薦閱讀其他優秀的文章。
sendfile
正常來說,當要傳送一個檔案時需要下面的步驟:
- malloc(3) – 分配一個本地緩衝區,儲存物件資料。
- read(2) – 檢索和複製物件到本地緩衝區。
- write(2) – 從本地緩衝區複製物件到 socket 緩衝區。
這涉及到兩個上下文切換(讀,寫),並使相同物件的第二個副本成為不必要的。正如你所看到的,這不是最佳的方式。值得慶幸的是還有另一個系統呼叫,提升了傳送檔案(的效率),它被稱為:sendfile(2)
(想不到吧!居然是這名字)。這個呼叫在檔案 cache 中檢索一個物件,並傳遞指標(不需要複製整個物件),直接傳遞到 socket 描述符,Netflix 表示,使用 sendfile(2) 將網路吞吐量從 6Gbps 提高到了 30Gbps。
然而,sendfile(2) 有一些注意事項:
- 不可用於 UNIX sockets(例如:當通過你的上游伺服器傳送靜態檔案時)
- 能否執行不同的操作,取決於作業系統(這裡檢視更多)
在 nginx 中開啟它
1 | sendfile on; |
tcp_nopush
tcp_nopush 與 tcp_nodelay 相反。不是為了儘可能快地推送資料包,它的目標是一次性優化資料的傳送量。
在傳送給客戶端之前,它將強制等待包達到最大長度(MSS)。而且這個指令只有在 sendfile 開啟時才起作用。
12 | sendfile on;tcp_nopush on; |
看起來 tcp_nopush 和 tcp_nodelay 是互斥的。但是,如果所有 3 個指令都開啟了,nginx 會:
- 確保資料包在傳送給客戶之前是已滿的
- 對於最後一個數據包,tcp_nopush 將被刪除 —— 允許 TCP 立即傳送,沒有 200ms 的延遲
我應該使用多少程序?
工作程序
worker_process 指令會指定:應該執行多少個 worker。預設情況下,此值設定為 1。最安全的設定是通過傳遞 auto 選項來使用核心數量。
但由於 Nginx 的架構,其處理請求的速度非常快 – 我們可能一次不會使用超過 2-4 個程序(除非你正在託管 Facebook 或在 nginx 內部執行一些 CPU 密集型的任務)。
1 | worker_process auto; |
worker 連線
與 worker_process 直接繫結的指令是 worker_connections。它指定一個工作程序可以一次開啟多少個連線。這個數目包括所有連線(例如與代理伺服器的連線),而不僅僅是與客戶端的連線。此外,值得記住的是,一個客戶端可以開啟多個連線,同時獲取其他資源。
1 | worker_connections 1024; |
開啟檔案數目限制
在基於 Unix 系統中的“一切都是檔案”。這意味著文件、目錄、管道甚至套接字都是檔案。系統對一個程序可以開啟多少檔案有一個限制。要檢視該限制:
12 | ulimit -Sn # soft limitulimit -Hn # hard limit |
這個系統限制必須根據 worker_connections 進行調整。任何傳入的連線都會開啟至少一個檔案(通常是兩個連線套接字以及後端連線套接字或磁碟上的靜態檔案)。所以這個值等於 worker_connections*2 是安全的。幸運的是,Nginx 提供了一個配置選項來增加這個系統的值。要使用這個配置,請新增具有適當數目的 worker_rlimit_nofile 指令並重新載入 nginx。
1 | worker_rlimit_nofile 2048; |
配置
123 | worker_process auto;worker_rlimit_nofile 2048; # Changes the limit on the maximum number of open files (RLIMIT_NOFILE) for worker processes.worker_connections 1024; # Sets the maximum number of simultaneous connections that can be opened by a worker process. |
最大連線數
如上所述,我們可以計算一次可以處理多少個併發連線:
12345 | 最大連線數 = worker_processes * worker_connections---------------------------------------------- (keep_alive_timeout + avg_response_time) * 2 |
keep_alive_timeout (後續有更多介紹) + avg_response_time 告訴我們:單個連線持續了多久。我們也除以 2,通常情況下,你將有一個客戶端開啟 2 個連線的情況:一個在 nginx 和客戶端之間,另一個在 nginx 和上游伺服器之間。
Gzip
啟用 gzip 可以顯著降低響應的(報文)大小,因此,客戶端(網頁)會顯得更快些。
壓縮級別
Gzip 有不同的壓縮級別,1 到 9 級。遞增這個級別將會減少檔案的大小,但也會增加資源消耗。作為標準我們將這個數字(級別)保持在 3 – 5 級,就像上面說的那樣,它將會得到較小的節省,同時也會得到更大的 CPU 使用率。
這有個通過 gzip 的不同的壓縮級別壓縮檔案的例子,0 代表未壓縮檔案。
1 | curl -I -H 'Accept-Encoding: gzip,deflate' https://netguru.co/ |
1234567891011 | ❯ du -sh ./* 64K ./0_gzip 16K ./1_gzip 12K ./2_gzip 12K ./3_gzip 12K ./4_gzip 12K ./5_gzip 12K ./6_gzip 12K ./7_gzip 12K ./8_gzip 12K ./9_gzip |
1234567891011 | ❯ ls -al-rw-r--r-- 1 matDobek staff 61711 3 Nov 08:46 0_gzip-rw-r--r-- 1 matDobek staff 12331 3 Nov 08:48 1_gzip-rw-r--r-- 1 matDobek staff 12123 3 Nov 08:48 2_gzip-rw-r--r-- 1 matDobek staff 12003 3 Nov 08:48 3_gzip-rw-r--r-- 1 matDobek staff 11264 3 Nov 08:49 4_gzip-rw-r--r-- 1 matDobek staff 11111 3 Nov 08:50 5_gzip-rw-r--r-- 1 matDobek staff 11097 3 Nov 08:50 6_gzip-rw-r--r-- 1 matDobek staff 11080 3 Nov 08:50 7_gzip-rw-r--r-- 1 matDobek staff 11071 3 Nov 08:51 8_gzip-rw-r--r-- 1 matDobek staff 11005 3 Nov 08:51 9_gzip |
gzip_http_version 1.1;
這條指令告訴 nginx 僅在 HTTP 1.1 以上的版本才能使用 gzip。我們在這裡不涉及 HTTP 1.0,至於 HTTP 1.0 版本,它是不可能既使用 keep-alive 和 gzip 的。因此你必須做出決定:使用 HTTP 1.0 的客戶端要麼錯過 gzip,要麼錯過 keep-alive。
配置
12345678910111213141516171819 | gzip on; # enable gzipgzip_http_version 1.1; # turn on gzip for http 1.1 and abovegzip_disable "msie6"; # IE 6 had issues with gzipgzip_comp_level 5; # inc compresion level, and CPU usagegzip_min_length 100; # minimal weight to gzip filegzip_proxied any; # enable gzip for proxied requests (e.g. CDN)gzip_buffers 16 8k; # compression buffers (if we exceed this value, disk will be used instead of RAM)gzip_vary on; # add header Vary Accept-Encoding (more on that in Caching section)# define files which should be compressedgzip_types text/plain;gzip_types text/css;gzip_types application/javascript;gzip_types application/json;gzip_types application/vnd.ms-fontobject;gzip_types application/x-font-ttf;gzip_types font/opentype;gzip_types image/svg+xml;gzip_types image/x-icon; |
快取
快取是另一回事,它能提升使用者的請求速度。
管理快取可以僅由 2 個 header 控制:
- 在 HTTP/1.1 中用
Cache-Control
管理快取 - Pragma 對於 HTTP/1.0 客戶端的向後相容性
快取本身可以分為兩類:公共快取和私有快取。公共快取是被多個使用者共同使用的。專用快取專用於單個使用者。我們可以很容易地區分,應該使用哪種快取:
12 | add_header Cache-Control public;add_header Pragma public; |
對於標準資源,我們想儲存1個月:
12345 | location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 1M; add_header Cache-Control public; add_header Pragma public;} |
上面的配置似乎足夠了。然而,使用公共快取時有一個注意事項。
讓我們看看如果將我們的資源儲存在公共快取(如 CDN)中,URI 將是唯一的識別符號。在這種情況下,我們認為 gzip 是開啟的。
有2個瀏覽器:
- 舊的,不支援 gzip
- 新的,支援 gzip
舊的瀏覽器給 CDN 傳送了一個 netguru.co/style 請求。但是 CDN 也沒有這個資源,它將會給我們的伺服器傳送請求,並且返回未經壓縮的響應。CDN 在雜湊裡儲存檔案(為以後使用):
12345 | { ... netguru. |