前言:
深入了解nginx,get到nginx的壹些性能優化方向。除了了解如何保持長連接,也通過本案例學習到開源中間件的壹些常用定位思路和優化方法。
場景描述
HTTP1.1之後,HTTP協議支持持久連接,也就是長連接,優點在於在壹個TCP連接上可以傳送多個HTTP請求和響應,減少了建立和關閉連接的消耗和延遲。如果我們使用了nginx去作為反向代理或者負載均衡,從客戶端過來的長連接請求就會被轉換成短連接發送給服務器端。為了支持長連接,我們需要在nginx服務器上做壹些配置。
要求
到長連接,我們必須做到以下兩點:
i.從client到nginx是長連接
ii.從nginx到server是長連接
對於客戶端而言,nginx其實扮演著server的角色,反之,之於server,nginx就是壹個client。
保持和Client的長連接
我們要想做到Client與Nginx之間保持長連接,需要:
i.Client發送過來的請求攜帶“keep-alive”header。
ii.Nginx設置支持keep-alive。
HTTP配置
默認情況下,nginx已經開啟了對client連接的keepalive 支持。對於特殊場景,可以調整相關參數。
大多數情況下,keepalive_requests = 100也夠用,但是對於 QPS 較高的場景,非常有必要加大這個參數,以避免出現大量連接被生成再拋棄的情況,減少TIME_WAIT。QPS=10000 時,客戶端每秒發送 10000 個請求 (通常建立有多個長連接),每個連接只能最多跑 100 次請求,意味著平均每秒鐘就會有 100 個長連接因此被 nginx 關閉。同樣意味著為了保持 QPS,客戶端不得不每秒中重新新建 100 個連接。因此,如果用netstat命令看客戶端機器,就會發現有大量的TIME_WAIT的socket連接 (即使此時keepalive已經在 Client 和 NGINX 之間生效)。
保持和Server的長連接
想讓Nginx和Server之間維持長連接,最樸素的設置如下:
upstream配置
upstream中,有壹個參數特別的重要,就是 keepalive 。 這個參數和之前http裏面的 keepalive_timeout 不壹樣。這個參數的含義是,連接池裏面最大的空閑連接數量。
不理解?沒關系,我們來舉個例子:
場景:
有壹個HTTP服務,作為upstream服務器接收請求,響應時間為100毫秒。要求性能達到10000 QPS,我們需要在nginx與upstream服務器之間建立大概1000條HTTP請求。(1000/0.1s=10000)
最優情況:
假設請求非常的均勻平穩,每壹個請求都是100ms,請求結束會被馬上放入連接池並置為idle(空閑)狀態。
我們以0.1s為單位:
1. 我們現在keepalive的值設置為10,每0.1s鐘有1000個連接。
2. 第0.1s的時候,我們壹***有1000個請求收到並釋放。
3. 第0.2s的時候,我們又來了1000個請求,在0.2s結束的時候釋放。
請求和應答都比較均勻,0.1s釋放的連接正好夠用,不需要建立新連接,且連接池中沒有idle狀態的連接。
第壹種情況:
應答非常平穩,但是請求不平穩 的時候
1.第0.3s的時候,我們只有500個請求收到,有500個請求因為網絡延遲等原因沒有進來。這個時候,Nginx檢測到連接池中有500個idle狀態的連接,就直接關閉了(500-10)個連接。
2.第0.4s的時候,我們收到了1500個請求,但是現在池裏面只有(500+10)個連接,所以Nginx不得不重新建立了(1500-510)個連接。如果在第4步的時候,沒有關閉那490個連接的話,只需要重新建立500個連接。
第二種情況:
請求非常平穩,但是應答不平穩 的時候
1. 第0.3s的時候,我們壹***有1500個請求收到。但是池裏面只有1000個連接,這個時候,Nginx又創建了500個連接,壹***1500個連接。
2.第0.3s的時候,第0.3s的連接全部被釋放,我們收到了500個請求。 Nginx檢測到池裏面有1000個idle狀態的連接,所以不得不釋放了(1000-10)個連接。造成連接數量反復震蕩的壹個推手,就是這個keepalive 這個最大空閑連接數。上面的兩種情況說的都是 keepalive設置的不合理導致Nginx有多次釋放與創建連接的過程,造成資源浪費。
keepalive 這個參數設置壹定要小心,尤其是對於 QPS 要求比較高或者網絡環境不穩定的場景,壹般根據 QPS 值和 平均響應時間能大致推算出需要的長連接數量。然後將keepalive設置為長連接數量的10%到30%。
location配置
HTTP 協議中對長連接的支持是從 1.1 版本之後才有的,因此最好通過proxy_http_version 指令設置為 1.1。HTTP1.0不支持keepalive特性,當沒有使用HTTP1.1的時候,後端服務會返回101錯誤,然後斷開連接。而“Connection” header 可以選擇被清理,這樣即便是 Client 和 Nginx 之間是短連接,Nginx 和 upstream 之間也是可以開啟長連接的。
另外壹種高級方式
http裏面的map的作用是:讓轉發到代理服務器的 "Connection" 頭字段的值,取決於客戶端請求頭的"Upgrade" 字段值。
如果$http_upgrade沒有匹配,那 "Connection" 頭字段的值會是upgrade。
如果$http_upgrade為空字符串的話,那 "Connection" 頭字段的值會是 close。
補充
NGINX支持WebSocket。對於NGINX將升級請求從客戶端發送到後臺服務器,必須明確設置Upgrade和Connection標題。這也算是上面情況所非常常用的場景。HTTP的Upgrade協議頭機制用於將連接從HTTP連接升級到WebSocket連接,Upgrade機制使用了Upgrade協議頭和Connection協議頭。為了讓Nginx可以將來自客戶端的Upgrade請求發送到後端服務器,Upgrade和Connection的頭信息必須被顯式的設置。
註意
在nginx的配置文件中,如果當前模塊中沒有proxy_set_header的設置,則會從上級別繼承配置。繼承順序為:http, server, location。如果在下壹層使用proxy_set_header修改了header的值,則所有的header值都可能會發生變化,之前繼承的所有配置將會被丟棄。所以,盡量在同壹個地方進行proxy_set_header,否則可能會有別的問題。