Nginx伺服器中的Socket切分是什麼

nginx發布的1.9.1版本引入了一個新的特性：允許使用so_reuseport套接字選項，該選項在許多作業系統的新版本中是可用的，包括dragonfly bsd和linux（核心版本3.9及以後）。此套接字選項允許多個套接字監聽相同ip和連接埠的組合。核心能夠在這些套接字中對傳入的連線進行負載平衡。 （對於nginx plus客戶，此功能將在年底發布的版本7中出現）

so_reuseport選項有許多潛在的實際應用。其他服務也可以使用它來簡單實現執行中的滾動升級（nginx已經通過支援了滾動升級）。對於nginx而言，啟用該選項可以減少在某些場景下的鎖定競爭而改善效能。

如下圖描述，當so_reuseport選項有效時，一個單獨的監聽socket通知工作進程接入的連接，並且每個工作線程都試圖獲得連接。

當so_reuseport選項啟用是，存在對每個ip位址和連接埠綁定連接的多個socket監聽器，每一個工作進程都可以分配一個。系統核心決定哪一個有效的socket監聽器（透過隱式的方式，給哪一個工作進程）來獲得連接。這可以減少工作進程之間獲得新連接時的封鎖競爭（譯者註：工作進程請求獲得互斥資源加鎖之間的競爭），同時在多核心系統可以提高效能。然而，這也意味著當一個工作進程陷入阻塞操作時，阻塞影響的不僅是已經接受連接的工作進程，也同時讓核心發送連接請求計劃分配的工作進程因此變為阻塞。

 設定共用socket

為了讓so_reuseport socket選項作用，應為http或tcp（串流模式）通訊選項內的listen項目直接引入新近的reuseport參數，就像下例這樣：
 

複製程式碼 程式碼如下:

http {
     server {         80 reuseport;
          server_name  localhost;
          ...
    2345 reuseport;
          ...
     }
}

引用reuseport參數後，對引用的socket，accept_mutex參數將會無效，因為互斥量（mutex）對reuseport來說是多餘的。對沒有使用reuseport的端口，設定accept_mutex仍然是有價值的。

reuseport的基準效能測試

我在一個36核心的aws實例運行基準測試工具測試4個nginx 工作進程.為了減少網路的影響，客戶端和nginx都運行在本地，並且讓nginx返回ok字串而不是一個檔案。我比較三種nginx配置：預設（等同於accept_mutex on ）,accept_mutex off,和reuseport。如圖所示，reuseport的每秒請求是其餘的兩到三倍，同時延遲和延遲標準差也是減少的。

 我又執行了另一個相關的效能測試－客戶端和nginx分別在不同的機器上且nginx回傳一個html檔。如下表所示，用 reuseport 減少的延遲和先前的效能測試相似，延遲的標準差減少的更為顯著（接近十分之一）。其他結果（沒有顯示在表格中）同樣令人振奮。使用 reuseport ，負載被均勻分離到了worker進程。在預設條件下（等同於 accept_mutex on），一些worker分到了較高百分比的負載，而用 accept_mutex off 所有worker都受到了較高的負載。

複製程式碼 程式碼如下:

latency (ms)  latency stdev (ms)  cpu load

default  15.65  26.59  0.3

accept_mutex off  15.59 516. .3

在這些效能測試中，連線請求的速度是很高的，但是請求不需要大量的處理。其他的基本的測試應該指出——當應用流量符合這種場景時 reuseport 也能大幅提高效能。 （reuseport 參數在 mail 上下文環境下不能用在 listen 指令下，例如email，因為email流量一定不會匹配這種場景。）我們鼓勵你先測試而不是直接大規模應用。

以上是Nginx伺服器中的Socket切分是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！