從Nginx、Apache工作原理看為什麼Nginx比Apache高效

　　Nginx才短短几年，就拿下了web伺服器大筆江山，眾所周知，Nginx在處理大併發靜態請求方面，效率明顯高於httpd，甚至能輕鬆解決C10K問題。

　　在高併發連線的情況下，Nginx是Apache伺服器不錯的替代品。Nginx同時也可以作為7層負載均衡伺服器來使用。根據我的測試結果，Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 可以承受3萬以上的併發連線數，相當於同等環境下Apache的10倍。

　　一般來說，4GB記憶體的伺服器+Apache（prefork模式）一般只能處理3000個併發連線，因為它們將佔用3GB以上的記憶體，還得為系統預留1GB的記憶體。我曾經就有兩臺Apache伺服器，因為在配置檔案中設定的MaxClients為4000，當Apache併發連線數達到3800時，導致伺服器記憶體和Swap空間用滿而崩潰。

　　而這臺 Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 伺服器在3萬併發連線下，開啟的10個Nginx程式消耗150M記憶體（15M*10=150M），開啟的64個php-cgi程式消耗1280M記憶體（20M*64=1280M），加上系統自身消耗的記憶體，總共消耗不到2GB記憶體。如果伺服器記憶體較小，完全可以只開啟25個php-cgi程式，這樣php-cgi消耗的總記憶體數才500M。

　　在3萬併發連線下，訪問Nginx 0.7.14 + PHP 5.2.6 (FastCGI) 伺服器的PHP程式，仍然速度飛快。

　　為什麼Nginx在處理高併發方面要優於httpd，我們先從兩種web伺服器的工作原理以及工作模式說起。

　　apache三種工作模式

　　我們都知道Apache有三種工作模組，分別為prefork、worker、event。

　　prefork：多程式，每個請求用一個程式響應，這個過程會用到select機制來通知。

　　worker：多執行緒，一個程式可以生成多個執行緒，每個執行緒響應一個請求，但通知機制還是select不過可以接受更多的請求。

　　event：基於非同步I/O模型，一個程式或執行緒，每個程式或執行緒響應多個使用者請求，它是基於事件驅動（也就是epoll機制）實現的。

　　prefork的工作原理

　　如果不用“–with-mpm”顯式指定某種MPM,prefork就是Unix平臺上預設的MPM.它所採用的預派生子程式方式也是 Apache1.3中採用的模式。prefork本身並沒有使用到執行緒，2.0版使用它是為了與1.3版保持相容性；另一方面，prefork用單獨的子程式來處理不同的請求，程式之間是彼此獨立的,這也使其成為最穩定的MPM之一。

　　worker的工作原理

　　相對於prefork，worker是2.0版中全新的支援多執行緒和多程式混合模型的MPM。由於使用執行緒來處理，所以可以處理相對海量的請求，而系統資源的開銷要小於基於程式的伺服器。但是，worker也使用了多程式,每個程式又生成多個執行緒，以獲得基於程式伺服器的穩定性，這種MPM的工作方 式將是Apache2.0的發展趨勢。

　　event 基於事件機制的特性

　　一個程式響應多個使用者請求，利用callback機制，讓套接字複用，請求過來後程式並不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，程式本身一直處於空閒狀態，可以一直接收使用者請求。可以實現一個程式程響應多個使用者請求。支援持海量併發連線數，消耗更少的資源。

　　如何提高Web伺服器的併發連線處理能力

　　有幾個基本條件：

　　1.基於執行緒，即一個程式生成多個執行緒，每個執行緒響應使用者的每個請求。

　　2.基於事件的模型，一個程式處理多個請求，並且通過epoll機制來通知使用者請求完成。

　　3.基於磁碟的AIO（非同步I/O）

　　4.支援mmap記憶體對映，mmap傳統的web伺服器，進行頁面輸入時，都是將磁碟的頁面先輸入到核心快取中，再由核心快取中複製一份到web伺服器上，mmap機制就是讓核心快取與磁碟進行對映，web伺服器，直接複製頁面內容即可。不需要先把磁碟的上的頁面先輸入到核心快取去。

　　剛好，Nginx 支援以上所有特性。所以Nginx官網上說，Nginx支援50000併發，是有依據的。

　　Nginx優異之處

　　傳統上基於程式或執行緒模型架構的web服務通過每程式或每執行緒處理併發連線請求，這勢必會在網路和I/O操作時產生阻塞，其另一個必然結果則是對記憶體或CPU的利用率低下。生成一個新的程式/執行緒需要事先備好其執行時環境，這包括為其分配堆記憶體和棧記憶體，以及為其建立新的執行上下文等。這些操作都需要佔用CPU，而且過多的程式/執行緒還會帶來執行緒抖動或頻繁的上下文切換，系統效能也會由此進一步下降。另一種高效能web伺服器/web伺服器反向代理：Nginx（Engine X），nginx的主要著眼點就是其高效能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啟發於多種作業系統設計中基於“事件”的高階處理機制，nginx採用了模組化、事件驅動、非同步、單執行緒及非阻塞的架構，並大量採用了多路複用及事件通知機制。在nginx中，連線請求由為數不多的幾個僅包含一個執行緒的程式worker以高效的迴環(run-loop)機制進行處理，而每個worker可以並行處理數千個的併發連線及請求。

　　Nginx 工作原理

　　Nginx會按需同時執行多個程式：一個主程式(master)和幾個工作程式(worker)，配置了快取時還會有快取載入器程式(cache loader)和快取管理器程式(cache manager)等。所有程式均是僅含有一個執行緒，並主要通過“共享記憶體”的機制實現程式間通訊。主程式以root使用者身份執行，而worker、cache loader和cache manager均應以非特權使用者身份執行。

　　在高連線併發的情況下，Nginx是Apache伺服器不錯的替代品

　　Nginx 安裝非常的簡單 , 配置檔案非常簡潔（還能夠支援perl語法）,Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到7*24不間斷執行，即使執行數個月也不需要重新啟動. 你還能夠 不間斷服務的情況下進行軟體版本的升級 。

　　Nginx 的誕生主要解決C10K問題

　　最後我們從各自使用的多路複用IO模型來分析：

　　select模型：（apache使用，由於受模組等限制，用的不多）

　　單個程式能夠 監視的檔案描述符的數量存在最大限制

　　select()所維護的 儲存大量檔案描述符的資料結構 ，隨著檔案描述符數量的增長，其在使用者態和核心的地址空間的複製所引發的開銷也會線性增長

　　由於網路響應時間的延遲使得大量TCP連線處於非活躍狀態，但呼叫select()還是會對 所有的socket進行一次線性掃描 ，會造成一定的開銷

　　poll：poll是unix沿用select自己重新實現了一遍，唯一解決的問題是poll 沒有最大檔案描述符數量的限制

　　epoll模型：（nginx使用）

　　epoll帶來了兩個優勢，大幅度提升了效能：

　　基於事件的就緒通知方式 ，select/poll方式，程式只有在呼叫一定的方法後，核心才會對所有監視的檔案描述符進行掃描，而epoll事件通過epoll_ctl()註冊一個檔案描述符，一旦某個檔案描述符就緒時，核心會採用類似call back的回撥機制，迅速啟用這個檔案描述符，epoll_wait()便會得到通知

　　呼叫一次epoll_wait()獲得就緒檔案描述符時，返回的並不是實際的描述符，而是一個代表就緒描述符數量的值，拿到這些值去epoll指定的一個陣列中依次取得相應數量的檔案描述符即可，這裡使用記憶體對映（mmap）技術， 避免了複製大量檔案描述符帶來的開銷

　　當然epoll也有一定的侷限性， epoll只有Linux2.6才有實現 ，而其他平臺都沒有，這和apache這種優秀的跨平臺伺服器，顯然是有些背道而馳了。

　　簡單來說epoll是select的升級版，單程式管理的檔案描述符沒有最大限制。但epoll只有linux平臺可使用。作為跨平臺的Apache沒有使用