資訊專欄INFORMATION COLUMN
摘要：套接字端口共享選項允許多個套接字監(jiān)聽同一個綁定的網(wǎng)絡(luò)地址和端口，這樣一來內(nèi)核就可以將外部的請求連接負載均衡到這些套接字上來。致謝感謝在英特爾工作的盧英奇和，他們每個人各自貢獻了使得套接字端口共享生效的解決方案。
英文原文地址：Socket Sharding in NGINX Release 1.9.1
譯者：UPYUN CDN 開發(fā)工程師 其實不想走
NGINX 1.9.1 發(fā)布版本中引入了一個新的特性 —— 允許套接字端口共享，該特性適用于大部分最新版本的操作系統(tǒng)，其中也包括 DragonFly BSD 和內(nèi)核 3.9 以后的 Linux 操作系統(tǒng)。套接字端口共享選項允許多個套接字監(jiān)聽同一個綁定的網(wǎng)絡(luò)地址和端口，這樣一來內(nèi)核就可以將外部的請求連接負載均衡到這些套接字上來。（對于 NGINX Plus 的用戶來說，該特性將會在年底發(fā)布的版本 7 中得到支持）
實際上很多潛在的用戶希望使用端口重用功能。其他服務(wù)也可以簡單的進行熱更新升級「NGINX 支持 多種方式 的熱更新」。對于 NGINX 來說，打開該選項可以通過在特定場景下減少連接鎖競爭而提高性能。
如下圖所示，在該選項沒有生效的前提下，一個多帶帶的監(jiān)聽套接字會通知所有的工作進程，每個進程則會試圖爭搶接管某個連接：
當(dāng)該選項生效時，這個時候?qū)τ诿總€網(wǎng)絡(luò)地址和端口就會有多個監(jiān)聽套接字，每個工作進程對應(yīng)一個套接字，內(nèi)核會決定由哪個監(jiān)聽套接字（也就是決定哪個工作進程）接管進來的連接。這個特性可以減少進程與進程之間為接收連接產(chǎn)生的鎖競爭而提高多核系統(tǒng)的性能。但是，如果當(dāng)一個工作進程處于阻塞操作時，這個時候不僅會影響已經(jīng)被該進程接收的連接，還會阻塞由系統(tǒng)準(zhǔn)備分配給該進程的連接請求：
配置套接字共享如下面配置所示，可以通過在 listen 指令后添加新的參數(shù) reuseport 來為 HTTP 或者 TCP（流模塊）打開套接字端口共享功能：
對于套接字來說，添加 reuseport 參數(shù)也就等于禁止了 accept_mutex 指令了，因為 mutex 對于 reuseport 來說是多余的，不過對于那些不希望使用套接字端口共享特性的端口來說，我們則有必要設(shè)置 accept_mutex。
reuseport 性能壓力測試我通過運行 wrk 壓測工具來壓測一個跑在 36 核亞馬遜實例上并開啟 4 個工作進程的 NGINX。為了減少網(wǎng)絡(luò)對于測試結(jié)果的影響，我們的客戶端和 NGINX 都是運行在本地的，并且 NGINX 只返回 OK 字符串而不返回文件。我對比了三個不同的配置，一個是默認的（等同于 accept_mutex on），另一個是 accept_mutex off，還有一個則是 reuseport。正如下圖所示，使用 reuseport 后每秒能處理的請求數(shù)比其他的兩個增加了 2-3 倍，并且同時減少了平均延遲和平均延遲的標(biāo)準(zhǔn)差。
我還嘗試客戶端和 NGINX 分別運行在不同的主機上跑相關(guān)的壓力測試，但這一次 NGINX 返回的是一個 HTML 文件。正如下表所示，與上圖的結(jié)果類似，使用端口重用能減少請求的處理延遲，并且延遲標(biāo)準(zhǔn)差減少的更加明顯（大概是 10 倍）。其他結(jié)果（并沒有在下表中顯示）則更加讓人欣喜。通過端口重用，請求的壓力被各個工作進程均衡掉，而在默認條件下（也就是 accept_mutex 打開），一些工作進程會得到比較高的負載，而在 accept_mutex 關(guān)閉的時候，所有的進程都會顯示負載比較高。
在上述的壓力測試中，請求的頻率很高但是每個請求并不需要復(fù)雜的處理。其他一些初步的測試也表明端口重用特性在網(wǎng)絡(luò)流量匹配的時候最能提高性能。（該參數(shù)并不能在郵件模塊的上下文監(jiān)聽指令中生效，因為郵件的網(wǎng)絡(luò)流量并不能匹配這個特性）。我們建議你在使用 reuseport 這個指令前先在你的 NGINX 實例上進行性能測試，而不是全部的 NGINX 實例都使用。對于測試 NGINX 的一些小提示，可以參考 Konstantin Pavlov 在 2014 NGINX 大會上的演講。
致謝感謝在英特爾工作的盧英奇和 Sepherosa Ziehau，他們每個人各自貢獻了使得套接字端口共享生效的解決方案。NGINX 開發(fā)小組合并了他們倆的想法從而創(chuàng)造出目前看來比較理想的解決方案。
原文鏈接：http://io.upyun.com/2015/07/20/nginx-socket-sharding/
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/39186.html
摘要：反向代理反向代理反向代理負載均衡鑒權(quán)限流等邏輯架構(gòu)在邏輯上分為入口層，模塊化的功能處理層，系統(tǒng)調(diào)用層。多個共同監(jiān)聽事件并處理，反向代理會把請求轉(zhuǎn)發(fā)給后端服務(wù)。 一.概述 本文將深入剖析nginx的架構(gòu)。 第一部分介紹nginx現(xiàn)有框架，用典型的4+1視圖闡述，包括邏輯架構(gòu)，開發(fā)架構(gòu)，運行架構(gòu)，物理架構(gòu)，功能用例，nginx為單機服務(wù)，不考慮物理架構(gòu)。其中功能用例概述nginx功能；邏輯...
摘要：反向代理反向代理反向代理負載均衡鑒權(quán)限流等邏輯架構(gòu)在邏輯上分為入口層，模塊化的功能處理層，系統(tǒng)調(diào)用層。多個共同監(jiān)聽事件并處理，反向代理會把請求轉(zhuǎn)發(fā)給后端服務(wù)。 一.概述 本文將深入剖析nginx的架構(gòu)。 第一部分介紹nginx現(xiàn)有框架，用典型的4+1視圖闡述，包括邏輯架構(gòu)，開發(fā)架構(gòu)，運行架構(gòu)，物理架構(gòu)，功能用例，nginx為單機服務(wù)，不考慮物理架構(gòu)。其中功能用例概述nginx功能；邏輯...
摘要：常規(guī)的網(wǎng)絡(luò)應(yīng)用設(shè)計都是為每個連接分配一個線程或進程。深入理解進程每個進程都是用配置進行初始化的，并且由主進程提供了一組監(jiān)聽套接字。套接字上發(fā)生事件后，進程開始進行處理監(jiān)聽套接字上的事件意味著有個客戶端發(fā)起了一盤新的象棋游戲。 NGINX在web性能上的表現(xiàn)尤為出眾，這完全得益于其設(shè)計方式，許多web和應(yīng)用服務(wù)器都是基于線程或進程這種簡單的架構(gòu)，NGINX用了一種精妙的事件驅(qū)動架構(gòu)，在現(xiàn)...
摘要：而對于堆內(nèi)存，通常需要程序員進行管理。我們通常說的內(nèi)存管理亦是只堆空間內(nèi)存管理。內(nèi)存管理整體可以分為個部分，第一部分是常規(guī)的內(nèi)存池，用于進程平時所需的內(nèi)存管理第二部分是共享內(nèi)存的管理。將內(nèi)存塊按照的整數(shù)次冪進行劃分最小為最大為。 施洪寶 一. 概述 應(yīng)用程序的內(nèi)存可以簡單分為堆內(nèi)存，棧內(nèi)存。對于棧內(nèi)存而言，在函數(shù)編譯時，編譯器會插入移動棧當(dāng)前指針位置的代碼，實現(xiàn)?？臻g的自管理。而對于...
摘要：而對于堆內(nèi)存，通常需要程序員進行管理。二內(nèi)存池管理說明本部分使用的版本為具體源碼參見文件實現(xiàn)使用流程內(nèi)存池的使用較為簡單可以分為步，調(diào)用函數(shù)獲取指針。將內(nèi)存塊按照的整數(shù)次冪進行劃分最小為最大為。 運營研發(fā)團隊 施洪寶 一. 概述 應(yīng)用程序的內(nèi)存可以簡單分為堆內(nèi)存，棧內(nèi)存。對于棧內(nèi)存而言，在函數(shù)編譯時，編譯器會插入移動棧當(dāng)前指針位置的代碼，實現(xiàn)?？臻g的自管理。而對于堆內(nèi)存，通常需要程序...
閱讀 1060·2021-11-22 15:33
閱讀 3373·2021-11-08 13:20
閱讀 1388·2021-09-22 10:55
閱讀 2058·2019-08-29 11:08
閱讀 780·2019-08-26 12:24
閱讀 3077·2019-08-23 17:15
閱讀 2239·2019-08-23 16:12
閱讀 1944·2019-08-23 16:09
