百萬併發下的Nginx優化，看這一篇就夠了！

本文做者主要分享在 Nginx 性能方面的實踐經驗，但願能給你們帶來一些系統化思考，幫助你們更有效地去作 Nginx。

優化方法論

我重點分享以下兩個問題：

• 保持併發鏈接數，怎麼樣作到內存有效使用。
• 在高併發的同時保持高吞吐量的重要要點。

實現層面主要是三方面優化，主要聚焦在應用、框架、內核。

硬件限制可能有的同窗也都聽過，把網卡調到萬兆、10G 或者 40G 是最好的，磁盤會根據成本的預算和應用場景來選擇固態硬盤或者機械式硬盤，關注 IOPS 或者 BPS。

CPU 是咱們重點看的一個指標。實際上它是把操做系統的切換代價換到了進程內部，因此它從一個鏈接器到另一個鏈接器的切換成本很是低，它性能很好，協程 Openresty 實際上是同樣的。

資源的高效使用，下降內存是對咱們增大併發性有幫助的，減小 RTT、提高容量。

Reuseport 都是圍繞着提高 CPU 的機核性。還有 Fast Socket，由於我以前在阿里雲的時候還作過阿里雲的網絡，因此它可以帶來很大的性能提高，可是問題也很明顯，就是把內核自己的那套東西繞過去了。

請求的「一輩子」

下面我首先會去聊一下怎麼看「請求」，瞭解完這個之後再去看怎麼優化就會很清楚了。

說這個以前必須再說一下 Nginx 的模塊結構，像 Nginx 之外，任何一個外部框架都有個特色，若是想造成整個生態必須容許第三方的代碼接進來，構成一個序列，讓一個請求挨個被模塊共同處理。

那 Nginx 也同樣，這些模塊會串成一個序列，一個請求會被挨個的處理。在覈心模塊裏有兩個，分別是 Steam 和 NGX。

請求到來

一個鏈接開始剛剛創建請求到來的時候會發生什麼事情？先是操做系統內核中有一個隊列，等着咱們的進程去系統調用，這時候由於有不少工做進程，誰會去調用呢，這有個負載均衡策略。

如今有一個事件模塊，調用了 Epoll Wait 這樣的接口，Accept 創建好一個新鏈接，這時會分配到鏈接內存池，這個內存池不一樣於全部的內存池，它在鏈接剛建立的時候會分配，何時會釋放呢？

只有這個鏈接關閉的時候纔會去釋放。接下來就到了 NGX 模塊，這時候會加一個 60 秒的定時器。

就是在創建好鏈接之後 60 秒以內沒有接到客戶端發來的請求就自動關閉，若是 60 秒過來以後會去分配內存，讀緩衝區。什麼意思呢？

如今操做系統內核已經收到這個請求了，可是個人應用程序處理不了，由於沒有給它讀到用戶態的內存裏去，因此這時候要分配內存。

從鏈接內存池這裏分配，那要分配多大呢？會擴到 1K。

收到請求

當收到請求之後，接收 Url 和 Header，分配請求內存池，這時候 Request Pool Size 是 4K，你們發現是否是和剛纔的有一個 8 倍的差距，這是由於利用態的內存是很是消耗資源的。

再看爲何會消耗資源，首先會用狀態機解去形容，所謂狀態機解就是把它當作一個序列，一個支節一個支節往下解，若是發現換行了那就是請求行解完了。

但若是這個請求特別長的時候，就會去再分配更大的，剛剛 1K 不夠用了，爲何是 4 乘 8K 呢？

就是由於當 1K 不夠了不會一次性分配 32K，而是一次性分配 8K。若是 8K 之後尚未解析到剛纔的標識符，就會分配第二個 8K。

我以前收到的全部東西都不會釋放，只是放一個指針，指到 Url 或者指到那個協議，標識它有多長就能夠了。

接下來解決 Header，這個流程如出一轍的沒有什麼區別，這時候還會有一個不夠用的狀況，當我接收完全部的 Header 之後，會把剛剛的定時器給移除，移除後接下來作 11 個階段的處理。

也就是說剛剛全部的外部服務器都是經過不少的模塊串成在一塊兒處理一個請求的。

像剛剛兩頁 PPT 都在說藍色的區域，那麼請求接下來 11 個階段是什麼意思呢？這個黃色的、綠色的，還有右邊這個都是在 11 階段之中。

這 11 個階段你們也不用記，很是簡單，只要掌握三個關鍵詞就能夠。

剛剛讀完 Header 要作處理，因此這時候第一階段是 Post-Read。接下來會有 Rewrite，還有 Access 和 Preaccess。

先看左手邊，當咱們下載完 Nginx 源碼編之後會有一個 Referer，全部的第三方數據都會在這裏呈現有序排列。

這些序列中並非簡單的一個請求給它再給它，先是分爲 11 個階段，每一個階段以內你們是有序一個個日後來的，但在 11 個階段中是按階段來的。

我把它分解一下，第一個 Referer 這階段有不少模塊，後面這是有序的。

這個圖比剛剛的圖多了兩個關鍵點：

• 第一到了某一個模塊能夠決定繼續向這序列後的模塊執行，也能夠說直接跳到下個階段，但不能說跳多個階段。
• 第二是生成了向客戶端反映的響應，這時候要對響應作些處理，這裏是有序的，先作縮略圖再作壓縮，因此它是有嚴格順序的。

請求的反向代理

請求的反向代理，反向代理這塊是咱們 Nginx 的重點應用場景，由於 Nginx 會考慮一種場景，客戶端走的是公網，因此網絡環境很是差，網速很是慢。

若是簡單用一個緩衝區從客戶端收一點發給上游服務器，那上游服務器的壓力會很大，由於上游服務器每每它的效率高，因此都是一個請求被處理完以前不會再處理下一個請求。

Nginx 考慮到這個場景，它會先把整個請求所有收完之後，再向上游服務器創建鏈接，因此是默認第一個配置，就是 Proxy Request Buffering On，存放包體至文件，默認 Size 是 8K。

那創建上游鏈接的時候會放 Time Out，60 秒，添加超時定時器，也是 60 秒的。

發出請求（讀取文體包件），若是向上遊傳一個很大的包體的話，那 Sizk 就是 8K。

默認 Proxy Limit Rate 是打開的，咱們會先把這個請求所有緩存到端來，因此這時候有個 8×8K，若是關掉的話，也就是從上游發一點就往下游發一點。

知道這個流程之後，再說這裏的話你們能夠感受到這裏的內存消耗仍是蠻大的。

返回響應

返回響應，這裏面其實內容蠻多的，我給你們簡化一下，仍是剛剛官方的那個包，這也是有順序的從下往上看，若是有大量第三方模塊進來的話，數量會很是高。

第一個關鍵點是上面的 Header Filter，上面是 Write Filter，下面是 Postpone Filter，這裏還有一個 Copy Filter，它又分爲兩類，一類是須要處理，一類是不須要處理的。

OpenResty 的指令，第一代碼是在哪裏執行的，第二個是 SDK。

應用層優化

協議

作應用層的優化咱們會先看協議層有沒有什麼優化，好比說編碼方式、Header 每次都去傳用 Nginx 的架構，以致於浪費了不少的流量。咱們能夠改善 Http2，有不少這樣的協議會大幅度提高它的性能。

固然若是你改善 Http2 了，會帶來其餘的問題，好比說 Http2 必須走這條路線。

這條路線又是一個很大的話題，它涉及到安全性和性能，是互相沖突的東西。

壓縮

咱們但願「商」越大越好，壓縮這裏會有一個重點提出來的動態和靜態，好比說咱們用了拷貝，好比說能夠從磁盤中直接由內核來發網卡，但一旦作壓縮的話就不得不先把這個文件讀到 Nginx，交給後面的極內核去作一下處理。

Keepalive 長鏈接也是同樣的，它也涉及到不少東西，簡單來看這也就是附用鏈接。

由於鏈接有一個慢啓動的過程，一開始它的窗口是比較小，一次可能只傳送很小的 1K 的，但後面可能會傳送幾十K，因此你每次新建鏈接它都會從新開始，這是很慢的。

固然這裏還涉及到一個問題，由於 Nginx 內核它默認打開了一個鏈接空閒的時候，長鏈接產生的做用也會降低。

提升內存使用率

剛剛在說具體的請求處理過程當中已經比較詳細的把這問題說清楚了，這裏再總結一下，在我看來有一個角度，Nginx 對下游只是必需要有的這些模塊，Client Header、Buffer Size：1K，上游網絡 Http 包頭和包體。

CPU 經過緩存去取儲存上東西的時候，它是一批一批取的，每一批目前是 64 字節，因此默認的是 8K。

若是你配了 32 它會給你上升到 64；若是你配了 65 會升到 128，由於它是一個一個序列化重組的。

因此瞭解這個東西之後本身再配的時候就不會再犯問題。紅黑樹這裏用的很是多，由於是和具體的模塊相關。

限速

大部分咱們在作分公司流控的時候，主要在限什麼呢？主要限 Nginx 向客戶端發送響應的速度。

這東西很是好用，由於能夠和 Nginx 定量鏈接在一塊兒。這不是限上游發請求的速度，而是在限從上游接響應的速度。

Worker 間負載均衡

當時我在用 0.6 版本的時候那時候都在默認用這個，這個「鎖」它是在用進程間同步方式去實現負載均衡，這個負載均衡怎麼實現呢？

就是保證全部的 Worker 進程，同一時刻只有一個 Worker 進程在處理距離，這裏就會有好幾個問題，綠色的框表明它的吞吐量，吞吐量不高，因此會致使第二個問題 Requests，也是比較長的，這個方差就很是的大。

若是把這個「鎖」關掉之後，能夠看到吞吐量是上升的，方差也在降低，可是它的時間在上升，爲何會出現這樣的狀況？

由於會致使一個 Worker 可能會很是忙，它的鏈接數已經很是高了，可是還有其餘的 Worker 進程是很閒的。

若是用了 Requests，它會在內核層面上作負載均衡。這是一個專用場景，若是在複雜應用場景下開 Requests 和不開是能看到明顯變化的。

超時

這裏我剛剛說了好多，它是一個紅黑樹在實現的。惟一要說的也就是這裏，Nginx 如今作四層的反向代理也很成熟了。

像 UTP 協議是能夠作反向代理的，但要把有問題的鏈接迅速踢掉的話，要遵循這個原則，一個請求對一個響應。

緩存

只要想提高性能必需要在緩存上下工夫。好比說我之前在阿里雲作雲盤，雲盤緩存的時候就會有個概念叫空間維度緩存，在讀一塊內容的時候可能會把這內容周邊的其餘內容也讀到緩存中。

你們若是熟悉優化的話也會知道有分支預測先把代碼讀到那空間中，這個用的比較少，基於時間維度用的比較多了。

減小磁盤 IO

其實要作的事也很是多，優化讀取，Sendfile 零拷貝、內存盤、SSD 盤。減小寫入，AIO，磁盤是遠大於內存的，當它把你內存消化完的時候還會退化成一個調用。

像 Thread Pool 只用讀文件，當退化成這種模式變多線程能夠防止它的主進程被阻塞住，這時候官方的博客上說是有 9 倍的性能提高。

系統優化

提高容量配置

咱們建鏈接的時候也有，還有些向客戶端發起鏈接的時候會有一個端口範圍，還有一些像對於網卡設備的。

CPU緩存的親和性

CPU緩存的親和性，這看狀況了，如今用 L3 緩存差很少也 20 兆的規模，CPU 緩存的親和性是一個很是大的話題，這裏就再也不展開了。

NUMA 架構的 CPU 親和性

把內存分紅兩部分，一部分是靠近這個核，一部分靠近那個核，若是訪問本核的話就會很快，靠近另外一邊大概會耗費三倍的損耗。對於多核 CPU 的使用對性能提高很大的話就不要在乎這個事情。

網絡快速容錯

由於 TCP 的鏈接最麻煩的是在創建鏈接和關閉鏈接，這裏有不少參數都是在調，每一個地方重發，多長時間重發，重發多少次。

這裏給你們展現的是快啓動，有好幾個概念在裏面，第一個概念在快速啓動的時候是以兩倍的速度。

由於網的帶寬是有限的，當你超出網絡帶寬的時候其中的網絡設備是會被丟包的，也就是控制量在往降低，那再恢復就會比較慢。

TCP 協議優化

TCP 協議優化，原本可能差很少要四個來回才能達到每次的傳輸在網絡中有幾十 K，那麼提早配好的話用增大初始窗口讓它一開始就達到最大流量。

提升資源效率

提升資源效率，這一頁東西就挺多了，好比說先從 CPU 看，TCP Defer Accept，若是有這個的話，實際上會犧牲一些即時性，但帶來的好處是第一次創建好鏈接沒有內容過來的時候是不會激活 Nginx 作切換的。

內存在說的時候是系統態的內存，在內存大和小的時候操做系統作了一次優化，在壓力模式和非壓力模式下爲每個鏈接分配的系統內存能夠動態調整。

網絡設備的核心只解決一個問題，變單個處理爲批量處理，批量處理後吞吐量必定是會上升的。

由於消耗的資源變少了，切換次數變少了，它們的邏輯是同樣的，就這些邏輯和我一直在說的邏輯都是同一個邏輯，只是應用在不一樣層面會產生不一樣的效果。

端口複用，像 Reals 是很好用的，由於它能夠把端口用在上游服務鏈接的層面上，沒有帶來隱患。

提高多 CPU 使用效率

提高多 CPU 使用效率，上面不少東西都說到了，重點就兩個，一是 CPU 綁定，綁定之後緩存更有效。多隊列網卡，從硬件層面上已經可以作到了。

BDP，帶寬確定是知道的，帶寬和時延就決定了帶寬時延積，那吞吐量等於窗口或者時延。

內存分配速度也是咱們關注的重點，當併發量很大的時候內存的分配是比較糟糕的，你們能夠看到有不少它的競品。

PCRE 的優化，這用最新的版本就好。

做者：陶輝

介紹：曾在華爲、騰訊公司作底層數據相關的工做，寫過一本書叫《深刻理解 Nginx：模塊開發與架構解析》，目前在杭州智鏈達做爲聯合創始人擔任技術總監一職，目前專一於使用互聯網技術助力建築行業實現轉型升級。