Apache與Nginx的優缺點比較


http://weilei0528.blog.163.com/blog/static/206807046201321810834431/

 

1、nginx相對於apache的優點: 
輕量級,同樣起web 服務,比apache 占用更少的內存及資源 
抗並發,nginx 處理請求是異步非阻塞的,而apache 則是阻塞型的,在高並發下nginx 能保持低資源低消耗高性能 
高度模塊化的設計,編寫模塊相對簡單 
社區活躍,各種高性能模塊出品迅速啊 
apache 相對於nginx 的優點: 

rewrite ,比nginx 的rewrite 強大 

動態頁面

模塊超多,基本想到的都可以找到 
少bug ,nginx 的bug 相對較多 

超穩定 

 

存在就是理由,一般來說, 需要性能的web 服務,用nginx 。如果不需要性能只求穩定,那就apache 吧。 后者的各種功能模塊實現得比前者,例如ssl 的模塊就比前者好,可配置項多。這里要注意一點,epoll(freebsd 上是 kqueue )網絡 IO 模型是nginx 處理性能高的根本理由,但並不是所有的情況下都是epoll 大獲全勝的,如果本身提供靜態服務的就只有寥寥幾個文 件,apache 的select 模型或許比epoll 更高性能。當然,這只是根據網絡IO 模型的原理作的一個假設,真正的應用還是需要實測了再說 的。 

2、作為 Web 服務器:相比 Apache,Nginx 使用更少的資源,支持更多的並發連接,體現更高的效率,這點 使 Nginx 尤其受到虛擬主機提供商的歡迎。在高連接並發的情況下,Nginx是Apache服務器不錯的替代品: Nginx在美國是做虛擬主機生 意的老板們經常選擇的軟件平台之一. 能夠支持高達 50,000 個並發連接數的響應,  感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型. 
Nginx 作為負載均衡服務器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作為 HTTP代理 服務器對外進行 服務. Nginx采用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多. 
作為郵件代理服務器: Nginx 同時也是一個非常優秀的郵件代理服務器(最早開發這個產品的目的之一也是作為郵件代理服務器), Last.fm 描述了成功並且美妙的使用經驗. 
Nginx 是 一個安裝非常的簡單 , 配置文件非常簡潔(還能夠支持perl語法), Bugs 非常少的服務器: Nginx 啟動特別容易, 並且幾乎可以做到 7*24不間斷運行,即使運行數個月也不需要重新啟動. 你還能夠不間斷服務的情況下進行軟件版本的升級 . 

3、Nginx 配置簡潔, Apache 復雜 
Nginx 靜態處理性能比 Apache 高 3倍以上 
Apache 對 PHP 支持比較簡單,Nginx 需要配合其他后端用 
Apache 的組件比 Nginx 多 
現在 Nginx 才是 Web 服務器的首選 

4、最核心的區別在於apache是同步多進程模型,一個連接對應一個進程;nginx是異步的,多個連接(萬級別)可以對應一個進程 

5、nginx處理靜態文件好,耗費內存少.但無疑apache仍然是目前的主流,有很多豐富的特性.所以還需要搭配着來.當然如果能確定nginx就適合需求,那么使用nginx會是更經濟的方式. 

apache有先天不支持多核心處理負載雞肋的缺點,建議使用nginx做前端,後端用apache。大型網站建議用nginx自代的集群功能


6、 從個人過往的使用情況來看,nginx的負載能力比apache高很多。最新的服務器也改用nginx了。而且nginx改完配置能-t測試一下配置有沒 有問題,apache重啟的時候發現配置出錯了,會很崩潰,改的時候都會非常小心翼翼現在看有好多集群站,前端nginx抗並發,后端apache集群, 配合的也不錯。

 


7、 nginx處理動態請求是雞肋,一般動態請求要apache去做,nginx只適合靜態和反向。 

8、從我個人的經驗來看,nginx是很不錯的前端服務器,負載性能很好,在老奔上開nginx,用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好,此外apache有強大的支持網路,發展時間相對nginx更久,

9、 Nginx優於apache的主要兩點:1.Nginx本身就是一個反向代理服務器 2.Nginx支持7層負載均衡;其他的當然,Nginx可能會比 apache支持更高的並發,但是根據NetCraft的統計,2011年4月的統計數據,Apache依然占有62.71%,而Nginx是 7.35%,因此總得來說,Aapche依然是大部分公司的首先,因為其成熟的技術和開發社區已經也是非常不錯的性能。 

10、你對web server的需求決定你的選擇。 大 部分情況下nginx都優於APACHE,比如說靜態文件處理、PHP-CGI的支持、反向代理功能、前端Cache、維持連接等等。在 Apache+PHP(prefork)模式下,如果PHP處理慢或者前端壓力很大的情況下,很容易出現Apache進程數飆升,從而拒絕服務的現象。 

11、可以看一下nginx lua模塊:https://github.com/chaoslaw...apache比nginx多的模塊,可直接用lua實現apache是最流行的,why?大多數人懶得更新到nginx或者學新事物 

12、對於nginx,我喜歡它配置文件寫的很簡潔,正則配置讓很多事情變得簡單運行效率高,占用資源少,代理功能強大,很適合做前端響應服務器 

13、Apache在處理動態有優勢,Nginx並發性比較好,CPU內存占用低,如果rewrite頻繁,那還是Apache吧
 
 
 
 
 
http://linxu2001.blog.163.com/blog/static/54084213201422493738925/

Nginx和Apache區別 

補充
linux下常用的I/O模型
先引入select和epoll概念:
select 和epoll是兩個處理I/O模型的機制,可以加速請求處理,2者處理方式不同:通俗的講,select機制是對沒有處理好的I/O請求在一段時間內進行 檢測,並將其狀態通知給用戶,即有沒有完成都會通知。而epool機制則是在該I/O請求完成后才通知給用戶。
 
在Unix/Linux下共有五種I/O模型,分別是:
1)阻塞I/O
2)非阻塞I/O
3)I/O復用(select和poll)
4)信號驅動I/O(SIGIO)
5)異步I/O(Posix.1的aio_系列函數)
 
對以上模型的比較:
阻塞I/O:
應用程序調用一個IO函數,導致應用程序阻塞,等待數據准備好。 如果數據沒有准備好,一直等待….數據准備好了,從內核拷貝到用戶空間,IO函數返回成功指示
 
非阻塞I/O:
我 們把一個套接口設置為非阻塞就是告訴內核,當所請求的I/O操作無法完成時,不要將進程睡眠,而是返回一個錯誤。這樣我們的I/O操作函數將不斷的測試數 據是否已經准備好,如果沒有准備好,繼續測試,直到數據准備好為止。在這個不斷測試的過程中,會大量的占用CPU的時間。
 
I/O復用(select和poll):
I/O復用模型會用到select或者poll函數,這兩個函數也會使進程阻塞,但是和阻塞I/O所不同的的,這兩個函數可以同時阻塞多個I/O操作。而且可以同時對多個讀操作,多個寫操作的I/O函數進行檢測,直到有數據可讀或可寫時,才真正調用I/O操作函數。
 
信號驅動I/O(SIGIO):
首先我們允許套接口進行信號驅動I/O,並安裝一個信號處理函數,進程繼續運行並不阻塞。當數據准備好時,進程會收到一個SIGIO信號,可以在信號處理函數中調用I/O操作函數處理數據。
 
異步I/O(Posix.1的aio_系列函數):
當一個異步過程調用發出后,調用者不能立刻得到結果。實際處理這個調用的部件在完成后,通過狀態、通知和回調來通知調用者的輸入輸出操作
 
回顧下apache的工作模塊:
prefork:多進程,每個請求用一個進程響應,這個過程會用到select機制來通知。
worker:多進程,一個進程可以生成多個線程,每個線程響應一個請求。
event:一個進程,每個進程響應多個用戶請求,它是基於事件實現的。
 
基於事件機制的特性:
一個進程響應多個用戶請求,利用run-loop機制,讓套接字復用,請求過來后進程並不處理請求,而是直接交由其他機制來處理,通過select或epoll機制來通知請求是否完成;在這個過程中,進程本身一直處於空閑狀態,可以一直接收用戶請求。
 
 
對於高並發請求的實現:
1、基於線程:即一個進程生成多個線程,每個線程響應用戶的每個請求。如worker模型
2、基於事件的模型,一個進程處理多個請求,並且通過epoll機制來通知用戶請求完成。如event模型
 
web服務器工作流程:
我們知道web服務器是工作在用戶空間的,用戶空間通過系統調用來與內核打交道。
用戶請求-->送達用戶空間-->系統調用-->內核空間-->內核到磁盤上讀取網頁資源(在此過程中就牽涉到了以上幾種模型的運用)
 
傳 統上基於進程或線程模型架構的web服務通過每進程或每線程處理並發連接請求,這勢必會在網絡和I/O操作時產生阻塞,其另一個必然結果則是對內存或 CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境,這包括為其分配堆內存和棧內存,以及為其創建新的執行上下文等。這些操作都需要占 用CPU,而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換,系統性能也會由此進一步下降。
 

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM