NGINX 1.9.1 新特性：套接字端口共享

英文原文地址：Socket Sharding in NGINX Release 1.9.1
譯者：UPYUN CDN 開發工程師 其實不想走

NGINX 1.9.1 發佈版本中引入了一個新的特性 —— 容許套接字端口共享，該特性適用於大部分最新版本的操做系統，其中也包括 DragonFly BSD 和內核 3.9 之後的 Linux 操做系統。套接字端口共享選項容許多個套接字監聽同一個綁定的網絡地址和端口，這樣一來內核就能夠將外部的請求鏈接負載均衡到這些套接字上來。（對於 NGINX Plus 的用戶來講，該特性將會在年末發佈的版本 7 中獲得支持）

實際上不少潛在的用戶但願使用端口重用功能。其餘服務也能夠簡單的進行熱更新升級「NGINX 支持 多種方式 的熱更新」。對於 NGINX 來講，打開該選項能夠經過在特定場景下減小鏈接鎖競爭而提升性能。

以下圖所示，在該選項沒有生效的前提下，一個單獨的監聽套接字會通知全部的工做進程，每一個進程則會試圖爭搶接管某個鏈接：

當該選項生效時，這個時候對於每一個網絡地址和端口就會有多個監聽套接字，每一個工做進程對應一個套接字，內核會決定由哪一個監聽套接字（也就是決定哪一個工做進程）接管進來的鏈接。這個特性能夠減小進程與進程之間爲接收鏈接產生的鎖競爭而提升多核系統的性能。可是，若是當一個工做進程處於阻塞操做時，這個時候不只會影響已經被該進程接收的鏈接，還會阻塞由系統準備分配給該進程的鏈接請求：

配置套接字共享

以下面配置所示，能夠經過在 listen 指令後添加新的參數 reuseport 來爲 HTTP 或者 TCP（流模塊）打開套接字端口共享功能：

對於套接字來講，添加 reuseport 參數也就等於禁止了 accept_mutex 指令了，由於 mutex 對於 reuseport 來講是多餘的，不過對於那些不但願使用套接字端口共享特性的端口來講，咱們則有必要設置 accept_mutex。

reuseport 性能壓力測試

我經過運行 wrk 壓測工具來壓測一個跑在 36 核亞馬遜實例上並開啓 4 個工做進程的 NGINX。爲了減小網絡對於測試結果的影響，咱們的客戶端和 NGINX 都是運行在本地的，而且 NGINX 只返回 OK 字符串而不返回文件。我對比了三個不一樣的配置，一個是默認的（等同於 accept_mutex on），另外一個是 accept_mutex off，還有一個則是 reuseport。正以下圖所示，使用 reuseport 後每秒能處理的請求數比其餘的兩個增長了 2-3 倍，而且同時減小了平均延遲和平均延遲的標準差。

我還嘗試客戶端和 NGINX 分別運行在不一樣的主機上跑相關的壓力測試，但這一次 NGINX 返回的是一個 HTML 文件。正以下表所示，與上圖的結果相似，使用端口重用能減小請求的處理延遲，而且延遲標準差減小的更加明顯（大概是 10 倍）。其餘結果（並無在下表中顯示）則更加讓人欣喜。經過端口重用，請求的壓力被各個工做進程均衡掉，而在默認條件下（也就是 accept_mutex 打開），一些工做進程會獲得比較高的負載，而在 accept_mutex 關閉的時候，全部的進程都會顯示負載比較高。

在上述的壓力測試中，請求的頻率很高可是每一個請求並不須要複雜的處理。其餘一些初步的測試也代表端口重用特性在網絡流量匹配的時候最能提升性能。（該參數並不能在郵件模塊的上下文監聽指令中生效，由於郵件的網絡流量並不能匹配這個特性）。咱們建議你在使用 reuseport 這個指令前先在你的 NGINX 實例上進行性能測試，而不是所有的 NGINX 實例都使用。對於測試 NGINX 的一些小提示，能夠參考 Konstantin Pavlov 在 2014 NGINX 大會上的演講。

致謝

感謝在英特爾工做的盧英奇和 Sepherosa Ziehau，他們每一個人各自貢獻了使得套接字端口共享生效的解決方案。NGINX 開發小組合並了他們倆的想法從而創造出目前看來比較理想的解決方案。

原文連接：http://io.upyun.com/2015/07/20/nginx-socket-sharding/