如下圖描述,當SO_REUSEPORT選項有效時,一個單獨的監聽socket通知工作進程接入的連接,並且每個工作線程都試圖獲得連接。
當SO_REUSEPORT選項啟用是,存在對每一個IP地址和端口綁定連接的多個socket監聽器,每一個工作進程都可以分配一個。系統內核決定哪一 個有效的socket監聽器(通過隱式的方式,給哪一個工作進程)獲得連接。這可以減少工作進程之間獲得新連接時的封鎖競爭(譯者注:工作進程請求獲得互 斥資源加鎖之間的競爭),同時在多核系統可以提高性能。然而,這也意味著當一個工作進程陷入阻塞操作時,阻塞影響的不僅是已經接受連接的工作進程,也同時 讓內核發送連接請求計劃分配的工作進程因此變為阻塞。
為了讓SO_REUSEPORT socket選項起作用,應為HTTP或TCP(流模式)通信選項內的listen項直接引入新近的reuseport參數,就像下例這樣:
http { server { listen 80 reuseport; server_name localhost; ... } } stream { server { listen 12345 reuseport; ... } }引用reuseport參數後,對引用的socket,accept_mutex參數將會無效,因為互斥量(mutex)對reuseport來說是多余的。對沒有使用reuseport的端口,設置accept_mutex仍然是有價值的。
我又運行了另一個相關的性能測試——客戶端和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大會上的演講。