輕松提升nginx性能,Ngnix 1.9.1支持socket分片

As your know, This is a transiation，原文： Socket Sharding in NGINX Release 1.9.1
NGINX發布版1.9.1介紹了新的特性，支持socket的SO_REUSEPORT選項，這個選項在許多操作系統的新版本有效，包括 DragonFly BSD和Linux（3.9+內核）。這個選項允許多個socket監聽同個IP地址和端口的組合。內核負載均衡這些進來的sockets連接，將這些 socket有效的分片。

這個socket的SO_REUSEPORT選項已經有許多現實世界的應用。對Nginx而言，它通過分布進程上的連接以提升性能。

正如下圖所描述的，當SO_REUSEPORT選項沒開啟時，連接進來時監聽socket默認會通知某個進程。如果您包含了accept_mutex off這個指令，此時會喚醒所有的工作進程，它們將為了得到它產生競爭。這就是所謂的驚群現象。
（小解釋下：如果使用epoll且不用鎖，當監聽端口有讀操作時，是會產生驚群現象的）
啟用SO_REUSEPORT選項後，每個進程將有個獨立的監聽socket。內核決定哪個是有效的socket（進程）得到這個連接。
這樣做降低了延遲並提高了工作進程的性能，它也意味著工作進程在准備處理它們前被賦予了新的連接。
配置socket分片
要開啟SO_REUSEPORT選項，將新的參數reuseport加到listen指令的後面，像以下例子這樣：

http {
     server {
          listen       80 reuseport;
          server_name  localhost;
          …
     }
}

包含這個reuseport參數後將禁用這個監聽socket的accept_mutex，因為鎖變得多余了。如果你不想用reuseport在端口上設置accept_mutex仍然是值得做的。

基准測試性能的提升
我在4個NGINX工作進程36核AWS實例上跑了 wrk基准測試，我的客戶端和Nginx都在本地上，並且讓Nginx只返回OK字符串。我比較了3種NGINX配置：accept_mutex on（默認），accept_mutex off，還有reuseport。如圖所現，reuseport每秒提升了2到3倍的請求，同時降低了延遲和stdev指標。
我另外跑了一個更加真實的測試，將客戶端和NGINX分離到不同的主機並且讓NGINX返咽一個HTML頁面文件。正如圖表所顯示的，帶 reuseport的降低的延遲跟上面的測試很接近，並且stdev的也是。其它的測試結果也是很令人鼓舞的。由於reuseport，負載更加均衡的分 配到各工作進程。在默認情況下（accept_mutex on），一些工作進程表現的各加均衡，
accept_mutex off情況下則有些表現的高低不下。

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

致謝
感謝Sepherosa Ziehau和Yingqi Lu，他們在Nginx項目中使用了SO_REUSEPORT選項。NGINX團隊借鑒他們的方法，並在NGINX創建了我們覺得更理想的方案。
原文：http://nglua.com/docs/sharding.html