主頁 > 知識庫 > 為什么 Nginx 比 Apache 更牛逼

為什么 Nginx 比 Apache 更牛逼

熱門標(biāo)簽:美圖手機 阿里云 檢查注冊表項 網(wǎng)站建設(shè) 硅谷的囚徒呼叫中心 智能手機 百度競價點擊價格的計算公式 使用U盤裝系統(tǒng)

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

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

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

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

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

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

一、Apache三種工作模式

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

  • prefork: 多進程,每個請求用一個進程響應(yīng),這個過程會用到select機制來通知。
  • worker: 多線程,一個進程可以生成多個線程,每個線程響應(yīng)一個請求,但通知機制還是select不過可以接受更多的請求。event: 基于異步I/O模型,一個進程或線程,每個進程或線程響應(yīng)多個用戶請求,它是基于事件驅(qū)動(也就是epoll機制)實現(xiàn)的。

1、prefork的工作原理

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

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

2、worker的工作原理

相對于prefork,worker是2.0版中全新的支持多線程和多進程混合模型的MPM。由于使用線程來處理,所以可以處理相對海量的請求,而系統(tǒng)資源的開銷要小于基于進程的服務(wù)器。

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

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

一個進程響應(yīng)多個用戶請求,利用callback機制,讓套接字復(fù)用,請求過來后進程并不處理請求,而是直接交由其他機制來處理,通過epoll機制來通知請求是否完成;在這個過程中,進程本身一直處于空閑狀態(tài),可以一直接收用戶請求。可以實現(xiàn)一個進程程響應(yīng)多個用戶請求。支持持海量并發(fā)連接數(shù),消耗更少的資源。

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

有幾個基本條件:

1、基于線程,即一個進程生成多個線程,每個線程響應(yīng)用戶的每個請求。

2、基于事件的模型,一個進程處理多個請求,并且通過epoll機制來通知用戶請求完成。

3、基于磁盤的AIO(異步I/O)

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

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

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

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

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

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

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

四、Nginx 工作原理

Nginx會按需同時運行多個進程:一個主進程(master)和幾個工作進程(worker),配置了緩存時還會有緩存加載器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程,并主要通過“共享內(nèi)存”的機制實現(xiàn)進程間通信。主進程以root用戶身份運行,而worker、cache loader和cache manager均應(yīng)以非特權(quán)用戶身份運行。

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

Nginx 安裝非常的簡單 , 配置文件非常簡潔(還能夠支持perl語法),Bugs 非常少的服務(wù)器: Nginx 啟動特別容易, 并且?guī)缀蹩梢宰龅?*24不間斷運行,即使運行數(shù)個月也不需要重新啟動. 你還能夠 不間斷服務(wù)的情況下進行軟件版本的升級 。

五、Nginx 的誕生主要解決C10K問題

最后我們從各自使用的多路復(fù)用IO模型來分析:

1、select模型:(apache使用,由于受模塊等限制,用的不多);

單個進程能夠 監(jiān)視的文件描述符的數(shù)量存在最大限制;

select()所維護的 存儲大量文件描述符的數(shù)據(jù)結(jié)構(gòu) ,隨著文件描述符數(shù)量的增長,其在用戶態(tài)和內(nèi)核的地址空間的復(fù)制所引發(fā)的開銷也會線性增長;

由于網(wǎng)絡(luò)響應(yīng)時間的延遲使得大量TCP連接處于非活躍狀態(tài),但調(diào)用select()還是會對 所有的socket進行一次線性掃描 ,會造成一定的開銷;

2、poll:poll是unix沿用select自己重新實現(xiàn)了一遍,唯一解決的問題是poll 沒有最大文件描述符數(shù)量的限制;

3、epoll模型:(Nginx使用)

epoll帶來了兩個優(yōu)勢,大幅度提升了性能:

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

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

3)當(dāng)然epoll也有一定的局限性, epoll只有Linux2.6才有實現(xiàn) ,而其他平臺都沒有,這和apache這種優(yōu)秀的跨平臺服務(wù)器,顯然是有些背道而馳了。

4)簡單來說epoll是select的升級版,單進程管理的文件描述符沒有最大限制。但epoll只有l(wèi)inux平臺可使用。作為跨平臺的Apache沒有使用

來源:http://codebay.cn/post/8557.html

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

標(biāo)簽:湖北 賀州 懷化 黃山 湘潭 山南 煙臺 通遼

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《為什么 Nginx 比 Apache 更牛逼》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266