介紹

眾所周知，NGINX 採用非同步、事件驅動的方式處理連線。意味著無需對每個請求建立專門的程序或執行緒，它用一個工作程序（worker process）處理多個連線和請求。為了達到這個目的，NGINX採用非阻塞模式的 socket，並利用諸如 epoll 和 kqueue 的高效方法。

全量程序（full-weight process）數很少（通常是一個 CPU 核只有一個）而且恆定、記憶體開銷少、CPU 週期不會浪費在任務切換上。此方法的優勢因為NGINX而廣為人知。它能同時處理成千上萬請求，而且容易擴充套件。

每個程序消耗額外的記憶體，程序之間的每次切換都會消耗 CPU 週期和丟棄 CPU 快取

不過非同步、事件驅動方式依然存在一個問題，或者可以說是敵人。其名字就是：阻塞。不幸的是，許多第三方模組採用阻塞方式呼叫，使用者（有時甚至這些模組的開發者）都沒有意識到這個缺陷。阻塞操作會毀掉 NGINX 效能，必須採取一切手段避免這樣的問題。

甚至在當前 NGINX 官方程式碼中，也無法在每個例子中避免阻塞操作，為了解決這個問題，NGINX 1.7.11 版實現了新的執行緒池機制。它是什麼，如何使用？我會在後面說明。我們先看看我們的敵人。

問題

首先，為了更好的理解問題，我們先簡單看看NGINX是如何工作的。

總體來說，NGINX 是一個事件處理器，一個從核心接收所有發生在連線上的事件資訊的控制器，然後給作業系統釋出命令。實際上，NGINX 通過編排作業系統做了全部的辛苦工作，作業系統則做了讀位元組和傳送位元組等日常工作。可見 NGINX 快速及時響應是如此重要。

工作程序監聽、處理來自核心中的事件。

事件可能是某個超時，或者socket準備讀取或者寫入的通知，或者錯誤發生的通知。NGINX 接收一串事件，接著挨個處理，做一些必要的動作。這些處理都線上程佇列的簡單迴圈中完成。NGINX 從佇列中放出一個事件，接著做出反應，例如寫或者讀一個 socket。在許多案例中，這非常快（也許只需要很少的CPU 週期就可以將資料複製到記憶體中），並且 NGINX  會立即處理佇列中所有的事件。

所有處理是在一個簡單的迴圈中由某個執行緒完成的

但是如果遇到某些又長又重操作，又會怎樣呢？整個事件處理週期可能會卡在那裡等待此操作結束。

我們說的“阻塞操作”是指會讓處理迴圈明顯停止一段時間的操作。阻塞的原因多種多樣。比如，NGINX忙於漫長的 CPU 密集型處理，或者不得不等待獲取某個資源，比如硬體驅動、某個互斥鎖、庫函式以同步方式呼叫資料庫響應。最關鍵的是處理諸如此類的操作，工作程序就沒有辦法做其他的事情，處理其他的事件，即使系統有更多可用資源可供佇列中某些事件使用。

試想商店裡售貨員，面前排著一個很長的佇列。排第一的顧客需要的貨物在倉庫，不是在店裡，售貨員去倉庫搬運貨物。為此整個佇列需要等待幾個小時，等待的人都會不高興的。你能想象人們的反應麼？佇列中每個人等待時間因為這幾個小時而增加，但他們想買的貨物或許就在商店裡。

佇列中的每一個人不得不等待第一個人的訂單

幾乎同樣的場景發生在 NGINX 中，需要讀取一個檔案，但它沒有快取在記憶體，不得不從硬碟中讀取。硬碟很慢（特別是旋轉的機械硬碟），然而佇列中其他等待的請求即使無需讀取硬碟，也被迫等待。結果增加了延遲，系統資源沒有被充分利用。

僅僅一個阻塞操作就能長時間地延遲接下來所有的操作

某些作業系統（比如 FreeBSD）提供了一個讀檔案和傳送檔案的非同步介面，NGINX可以呼叫這個介面（見 aio 指令）。不幸的是，Linux 並非都如此。儘管 Linux系統也提供了讀取檔案的非同步介面，但它有兩個重大缺陷。其一是檔案讀取和快取時需要對齊，不過 NGINX 能處理地很好。第二個問題更糟，非同步介面需要在檔案描述符上作 O_DIRECT 標記，這樣任何獲取檔案的操作越過記憶體級的快取，增加了硬碟負載。在很多例子中，這真不是一個好的選擇。

為解決這個問題，NGINX 1.7.11 引入了執行緒池。NGINX Plus 預設狀態下沒有執行緒池，如果你想給 NGINX Plus R6 構建一個執行緒池，請聯絡銷售。

讓我們深入探究什麼是執行緒池、它是如何工作的。

執行緒池

讓我們回到剛才那個可憐的銷售助理，從很遠的倉庫取貨物。但是他變聰明瞭，也或許因為憤怒地顧客鄙視變得聰明瞭？購買了一套配送服務。現在有人想購買遠距離倉庫中的貨物，銷售助理無需前往，只需要將訂單轉給配送服務，後者會處理這個訂單，銷售助理可以繼續為其他顧客服務。由此只有貨物不再商鋪的顧客需要等待貨物提取，其他顧客能夠快速得到服務。

把訂單轉給配送服務，這樣就不會阻塞隊列了

對 NGINX 而言，執行緒池就是充當配送服務的角色，它由一個任務佇列和一組處理佇列的執行緒組成。一旦工作程序需要處理某個可能的長操作，不用自己操作，將其作為一個任務放出執行緒池的佇列，接著會被某個空閒執行緒提取處理。

工作程序把阻塞操作轉給執行緒池

像是擁有了一個新的佇列，不過本例中的佇列侷限於某個特定的資源。從硬碟中讀取資料的速度不會超過硬碟生成資料的速度。硬碟沒有延遲處理其他事件，僅僅需要獲取檔案的請求在等待。

硬碟讀取操作通常就是阻塞操作，不過NGINX中的執行緒池可以用來處理任何在主工作週期不適合處理的任務。

此刻分派給執行緒池的任務主要有兩個：許多作業系統上 read() 方法的系統呼叫，以及 Linux 系統的 sendfile()方法。我們會繼續測試（test）和基準測試（benchmark），未來發布的版本或許將其他的操作分派給執行緒池。

基準測試

I到了從理論到實踐的時候了，為了展示利用執行緒池的效果，我們打算設定一個合成基準模擬最糟糕的阻塞或者非阻塞操作。

資料集不能超出記憶體，在一個 48GB 記憶體機器上，生成 256GB 隨機資料，每個檔案大小 4MB ，接著配置 NGINX 1.9.0 為其提供服務。

配置及其簡單：

正如你所看到的，為了獲得更好的效能，我們做了一些調優：關閉了 loggin 和 accept_mutex，同時開啟了 sendfile()，設定 sendfile_max_chunk 大小為512K。最後面的指令可以減少阻塞方法 sendfile() 呼叫的所花費的最大時間，即 NGINX 每次無需傳送整個檔案，只發送 512KB 的塊資料。

計算機含有兩個英特爾至強 E5645 處理器(Intel Xeon E5645)，以及 10Gbps 網路介面。硬碟子系統由四個西部資料 WD1003FBYX 硬碟按放在一個 RAID10 陣列中。所有硬體由Ubuntu Server 14.04.1 LTS進行管理。

為基準測試，配置 NGINX 和負載生成器

客戶端由兩個配置相同的計算機組成，其中一臺，wrk 通過用 Lua 指令碼建立負載。指令碼通過  200 個並行連線，隨機向伺服器請求檔案。每一個請求可能導致快取失效、產生一個硬碟阻塞讀操作。姑且稱這種負載叫隨機負載。

在第二臺客戶端計算機上，我們執行另一個 wrk 拷貝，用 50 個並行連線多次訪問同一個檔案。因為檔案高頻訪問，它會一直留在記憶體中。通常，NGINX可以非常快地處理這些請求，不過工作程序一旦阻塞被其他請求阻塞，效能就會下滑。姑且稱這種負載為恆定負載。

利用 ifstat 命令獲取第二臺客戶端的 wrk 結果，來監控伺服器吞吐量，並以此測定伺服器效能。

第一次沒有執行緒池參與的執行，並沒有帶給我們什麼驚喜的結果：