為什么 Nginx 比 Apache 更牛逼

Nginx才短短幾年，就拿下了Web服務(wù)器大壁江山，眾所周知，Nginx在處理大并發(fā)靜態(tài)請求方面，效率明顯高于Httpd，甚至能輕松解決C10K問(wèn)題。

在高并發(fā)連接的情況下，Nginx是Apache服務(wù)器不錯的替代品。Nginx同時(shí)也可以作為7層負載均衡服務(wù)器來(lái)使用。根據我的測試結果，Nginx + PHP(FastCGI) 可以承受3萬(wàn)以上的并發(fā)連接數，相當于同等環(huán)境下Apache的10倍。

一般來(lái)說(shuō)，4GB內存的服務(wù)器+Apache（prefork模式）一般只能處理3000個(gè)并發(fā)連接，因為它們將占用3GB以上的內存，還得為系統預留1GB的內存。我曾經(jīng)就有兩臺Apache服務(wù)器，因為在配置文件中設置的MaxClients為4000，當Apache并發(fā)連接數達到3800時(shí)，導致服務(wù)器內存和Swap空間用滿(mǎn)而崩潰。

而這臺 Nginx + PHP(FastCGI) 服務(wù)器在3萬(wàn)并發(fā)連接下，開(kāi)啟的10個(gè)Nginx進(jìn)程消耗150M內存（15M*10=150M），開(kāi)啟的64個(gè)php-cgi進(jìn)程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。如果服務(wù)器內存較小，完全可以只開(kāi)啟25個(gè)php-cgi進(jìn)程，這樣php-cgi消耗的總內存數才500M。

在3萬(wàn)并發(fā)連接下，訪(fǎng)問(wèn)Nginx+ PHP(FastCGI) 服務(wù)器的PHP程序，仍然速度飛快。

為什么Nginx在處理高并發(fā)方面要優(yōu)于httpd，我們先從兩種web服務(wù)器的工作原理以及工作模式說(shuō)起。

一、Apache三種工作模式

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

• prefork： 多進(jìn)程，每個(gè)請求用一個(gè)進(jìn)程響應，這個(gè)過(guò)程會(huì )用到select機制來(lái)通知。
• worker： 多線(xiàn)程，一個(gè)進(jìn)程可以生成多個(gè)線(xiàn)程，每個(gè)線(xiàn)程響應一個(gè)請求，但通知機制還是select不過(guò)可以接受更多的請求。event： 基于異步I/O模型，一個(gè)進(jìn)程或線(xiàn)程，每個(gè)進(jìn)程或線(xiàn)程響應多個(gè)用戶(hù)請求，它是基于事件驅動(dòng)（也就是epoll機制）實(shí)現的。

1、prefork的工作原理

如果不用“–with-mpm”顯式指定某種MPM，prefork就是Unix平臺上缺省的MPM。它所采用的預派生子進(jìn)程方式也是 Apache1.3中采用的模式。

prefork本身并沒(méi)有使用到線(xiàn)程，2.0版使用它是為了與1.3版保持兼容性；另一方面，prefork用單獨的子進(jìn)程來(lái)處理不同的請求，進(jìn)程之間是彼此獨立的,這也使其成為最穩定的MPM之一。

2、worker的工作原理

相對于prefork，worker是2.0版中全新的支持多線(xiàn)程和多進(jìn)程混合模型的MPM。由于使用線(xiàn)程來(lái)處理，所以可以處理相對海量的請求，而系統資源的開(kāi)銷(xiāo)要小于基于進(jìn)程的服務(wù)器。

但是，worker也使用了多進(jìn)程,每個(gè)進(jìn)程又生成多個(gè)線(xiàn)程，以獲得基于進(jìn)程服務(wù)器的穩定性，這種MPM的工作方 式將是Apache2.0的發(fā)展趨勢。

3、event 基于事件機制的特性

一個(gè)進(jìn)程響應多個(gè)用戶(hù)請求，利用callback機制，讓套接字復用，請求過(guò)來(lái)后進(jìn)程并不處理請求，而是直接交由其他機制來(lái)處理，通過(guò)epoll機制來(lái)通知請求是否完成；在這個(gè)過(guò)程中，進(jìn)程本身一直處于空閑狀態(tài)，可以一直接收用戶(hù)請求?？梢詫?shí)現一個(gè)進(jìn)程程響應多個(gè)用戶(hù)請求。支持持海量并發(fā)連接數，消耗更少的資源。

二、如何提高Web服務(wù)器的并發(fā)連接處理能力

有幾個(gè)基本條件：

1、基于線(xiàn)程，即一個(gè)進(jìn)程生成多個(gè)線(xiàn)程，每個(gè)線(xiàn)程響應用戶(hù)的每個(gè)請求。

2、基于事件的模型，一個(gè)進(jìn)程處理多個(gè)請求，并且通過(guò)epoll機制來(lái)通知用戶(hù)請求完成。

3、基于磁盤(pán)的AIO（異步I/O）

4、支持mmap內存映射，mmap傳統的web服務(wù)器，進(jìn)行頁(yè)面輸入時(shí)，都是將磁盤(pán)的頁(yè)面先輸入到內核緩存中，再由內核緩存中復制一份到web服務(wù)器上，mmap機制就是讓內核緩存與磁盤(pán)進(jìn)行映射，web服務(wù)器，直接復制頁(yè)面內容即可。不需要先把磁盤(pán)的上的頁(yè)面先輸入到內核緩存去。

剛好，Nginx 支持以上所有特性。所以Nginx官網(wǎng)上說(shuō)，Nginx支持50000并發(fā)，是有依據的。

三、Nginx優(yōu)異之處

傳統上基于進(jìn)程或線(xiàn)程模型架構的Web服務(wù)通過(guò)每進(jìn)程或每線(xiàn)程處理并發(fā)連接請求，這勢必會(huì )在網(wǎng)絡(luò )和I/O操作時(shí)產(chǎn)生阻塞，其另一個(gè)必然結果則是對內存或CPU的利用率低下。

生成一個(gè)新的進(jìn)程/線(xiàn)程需要事先備好其運行時(shí)環(huán)境，這包括為其分配堆內存和棧內存，以及為其創(chuàng )建新的執行上下文等。這些操作都需要占用CPU，而且過(guò)多的進(jìn)程/線(xiàn)程還會(huì )帶來(lái)線(xiàn)程抖動(dòng)或頻繁的上下文切換，系統性能也會(huì )由此進(jìn)一步下降。

另一種高性能web服務(wù)器/Web服務(wù)器反向代理：Nginx，Nginx的主要著(zhù)眼點(diǎn)就是其高性能以及對物理計算資源的高密度利用，因此其采用了不同的架構模型。受啟發(fā)于多種操作系統設計中基于“事件”的高級處理機制，Nginx采用了模塊化、事件驅動(dòng)、異步、單線(xiàn)程及非阻塞的架構，并大量采用了多路復用及事件通知機制。

在Nginx中，連接請求由為數不多的幾個(gè)僅包含一個(gè)線(xiàn)程的進(jìn)程Worker以高效的回環(huán)(run-loop)機制進(jìn)行處理，而每個(gè)Worker可以并行處理數千個(gè)的并發(fā)連接及請求。

四、Nginx 工作原理

Nginx會(huì )按需同時(shí)運行多個(gè)進(jìn)程：一個(gè)主進(jìn)程(master)和幾個(gè)工作進(jìn)程(worker)，配置了緩存時(shí)還會(huì )有緩存加載器進(jìn)程(cache loader)和緩存管理器進(jìn)程(cache manager)等。所有進(jìn)程均是僅含有一個(gè)線(xiàn)程，并主要通過(guò)“共享內存”的機制實(shí)現進(jìn)程間通信。主進(jìn)程以root用戶(hù)身份運行，而worker、cache loader和cache manager均應以非特權用戶(hù)身份運行。

在高連接并發(fā)的情況下，Nginx是Apache服務(wù)器不錯的替代品。

Nginx 安裝非常的簡(jiǎn)單 , 配置文件非常簡(jiǎn)潔（還能夠支持perl語(yǔ)法）,Bugs 非常少的服務(wù)器: Nginx 啟動(dòng)特別容易, 并且幾乎可以做到7*24不間斷運行，即使運行數個(gè)月也不需要重新啟動(dòng). 你還能夠 不間斷服務(wù)的情況下進(jìn)行軟件版本的升級 。

五、Nginx 的誕生主要解決C10K問(wèn)題

最后我們從各自使用的多路復用IO模型來(lái)分析：

1、select模型：（apache使用，由于受模塊等限制，用的不多）；

單個(gè)進(jìn)程能夠 監視的文件描述符的數量存在最大限制；

select()所維護的 存儲大量文件描述符的數據結構 ，隨著(zhù)文件描述符數量的增長(cháng)，其在用戶(hù)態(tài)和內核的地址空間的復制所引發(fā)的開(kāi)銷(xiāo)也會(huì )線(xiàn)性增長(cháng)；

由于網(wǎng)絡(luò )響應時(shí)間的延遲使得大量TCP連接處于非活躍狀態(tài)，但調用select()還是會(huì )對 所有的socket進(jìn)行一次線(xiàn)性?huà)呙?，會(huì )造成一定的開(kāi)銷(xiāo)；

2、poll：poll是unix沿用select自己重新實(shí)現了一遍，唯一解決的問(wèn)題是poll 沒(méi)有最大文件描述符數量的限制；

3、epoll模型：（Nginx使用）

epoll帶來(lái)了兩個(gè)優(yōu)勢，大幅度提升了性能：

1）基于事件的就緒通知方式 ，select/poll方式，進(jìn)程只有在調用一定的方法后，內核才會(huì )對所有監視的文件描述符進(jìn)行掃描，而epoll事件通過(guò)epoll_ctl()注冊一個(gè)文件描述符，一旦某個(gè)文件描述符就緒時(shí)，內核會(huì )采用類(lèi)似call back的回調機制，迅速激活這個(gè)文件描述符，epoll_wait()便會(huì )得到通知

2）調用一次epoll_wait()獲得就緒文件描述符時(shí)，返回的并不是實(shí)際的描述符，而是一個(gè)代表就緒描述符數量的值，拿到這些值去epoll指定的一個(gè)數組中依次取得相應數量的文件描述符即可，這里使用內存映射（mmap）技術(shù)， 避免了復制大量文件描述符帶來(lái)的開(kāi)銷(xiāo)

3）當然epoll也有一定的局限性， epoll只有Linux2.6才有實(shí)現 ，而其他平臺都沒(méi)有，這和apache這種優(yōu)秀的跨平臺服務(wù)器，顯然是有些背道而馳了。

4）簡(jiǎn)單來(lái)說(shuō)epoll是select的升級版，單進(jìn)程管理的文件描述符沒(méi)有最大限制。但epoll只有linux平臺可使用。作為跨平臺的Apache沒(méi)有使用

來(lái)源：

到此這篇關(guān)于為什么 Nginx 比 Apache 更牛逼的文章就介紹到這了,更多相關(guān)Nginx對比 Apache內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！