Nginx才短短幾年，就拿下了Web伺服器大壁江山，眾所周知，Nginx在處理大並發靜態請求方面，效率明顯高於Httpd，甚至能輕鬆解決C10K問題。在高並發連接的情況下，Nginx是Apache伺服器不錯的替代品。Nginx同時也可以作為7層負載均衡伺服器來使用。根據我的測試結果，Nginx + PHP(FastCGI) 可以承受3萬以上的並發連接數，相當於同等環境下Apache的10倍。一般來說，4GB內存的伺服器+Apache（prefork模式）一般只能處理3000個並發連接，因為它們將佔用3GB以上的內存，還得為系統預留1GB的內存。我曾經就有兩臺Apache伺服器，因為在配置文件中設置的MaxClients為4000，當Apache並發連接數達到3800時，導致伺服器內存和Swap空間用滿而崩潰。而這臺 Nginx + PHP(FastCGI) 伺服器在3萬並發連接下，開啟的10個Nginx進程消耗150M內存（15M*10=150M），開啟的64個php-cgi進程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。如果伺服器內存較小，完全可以只開啟25個php-cgi進程，這樣php-cgi消耗的總內存數才500M。在3萬並發連接下，訪問Nginx+ PHP(FastCGI) 伺服器的PHP程序，仍然速度飛快。為什麼Nginx在處理高並發方面要優於httpd，我們先從兩種web伺服器的工作原理以及工作模式說起。一、Apache三種工作模式我們都知道Apache有三種工作模塊，分別為：prefork、worker、event。prefork：多進程，每個請求用一個進程響應，這個過程會用到select機制來通知。worker：多線程，一個進程可以生成多個線程，每個線程響應一個請求，但通知機制還是select不過可以接受更多的請求。event：基於異步I/O模型，一個進程或線程，每個進程或線程響應多個用戶請求，它是基於事件驅動（也就是epoll機制）實現的。1、prefork的工作原理如果不用「–with-mpm」顯式指定某種MPM，prefork就是Unix平臺上預設的MPM。它所採用的預派生子進程方式也是 Apache1.3中採用的模式。prefork本身並沒有使用到線程，2.0版使用它是為了與1.3版保持兼容性；另一方面，prefork用單獨的子進程來處理不同的請求，進程之間是彼此獨立的,這也使其成為最穩定的MPM之一。2、worker的工作原理相對於prefork，worker是2.0版中全新的支持多線程和多進程混合模型的MPM。由於使用線程來處理，所以可以處理相對海量的請求，而系統資源的開銷要小於基於進程的伺服器。但是，worker也使用了多進程,每個進程又生成多個線程，以獲得基於進程伺服器的穩定性，這種MPM的工作方 式將是Apache2.0的發展趨勢。3、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，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模型來分析：1、select模型：（apache使用，由於受模塊等限制，用的不多）；單個進程能夠 監視的文件描述符的數量存在最大限制；select()所維護的 存儲大量文件描述符的數據結構 ，隨著文件描述符數量的增長，其在用戶態和內核的地址空間的複製所引發的開銷也會線性增長；由於網絡響應時間的延遲使得大量TCP連接處於非活躍狀態，但調用select()還是會對 所有的socket進行一次線性掃描 ，會造成一定的開銷；2、poll：poll是unix沿用select自己重新實現了一遍，唯一解決的問題是poll 沒有最大文件描述符數量的限制；3、epoll模型：（Nginx使用）epoll帶來了兩個優勢，大幅度提升了性能：（1）基於事件的就緒通知方式 ，select/poll方式，進程只有在調用一定的方法後，內核才會對所有監視的文件描述符進行掃描，而epoll事件通過epoll_ctl()註冊一個文件描述符，一旦某個文件描述符就緒時，內核會採用類似call back的回調機制，迅速激活這個文件描述符，epoll_wait()便會得到通知（2）調用一次epoll_wait()獲得就緒文件描述符時，返回的並不是實際的描述符，而是一個代表就緒描述符數量的值，拿到這些值去epoll指定的一個數組中依次取得相應數量的文件描述符即可，這裡使用內存映射（mmap）技術， 避免了複製大量文件描述符帶來的開銷（3）當然epoll也有一定的局限性， epoll只有Linux2.6才有實現 ，而其他平臺都沒有，這和apache這種優秀的跨平臺伺服器，顯然是有些背道而馳了。（4）簡單來說epoll是select的升級版，單進程管理的文件描述符沒有最大限制。但epoll只有linux平臺可使用。作為跨平臺的Apache沒有使用