NGINX 1.9.1 中的 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 { listen 80 reuseport;
server_name localhost;
...
}
}
stream {
server { listen 12345 reuseport;
...
}
}</pre>
引用reuseport參數后，對引用的socket，accept_mutex參數將會無效，因為互斥量（mutex）對reuseport來說是多余的。對沒有使用reuseport的端口，設置accept_mutex仍然是有價值的。
reuseport的基準性能測試
我在一個36核的AWS實例運行wrk基準測試工具測試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 | 26.48 | 10 |
| reuseport | 12.35 | 3.15 | 0.3 |
在這些性能測試中，連接請求的速度是很高的，但是請求不需要大量的處理。其他的基本的測試應該指出——當應用流量符合這種場景時 reuseport 也能大幅提高性能。（reuseport 參數在 mail 上下文環境下不能用在 listen 指令下，例如email，因為email流量一定不會匹配這種場景。）我們鼓勵你先測試而不是直接大規模應用。關于測試NGNIX性能的一些技巧，看看Konstantin Pavlov在nginx2014大會上的演講。
致謝
感謝 Sepherosa Ziehau 和 Yingqi Lu, 他們為NGNIX項目貢獻了一個使用socket選項SO_REUSEPORT 的方案。NGNIX團隊整合他們的貢獻和想法所創建的，我們相信是一個理想的解決方案。