為什麼我們使用Nginx而不是Apache

我們大多數的客戶在他們的服務器上使用Apache作為Web服務器,尤其是部署在一個基於PHP系統的前端並且使用mod-PHP。鑑於擴張性和性能方面的原因,我們通常會建議他們改用Nginx和FPM。

Apache是​​非常強大的Web服務器,模塊化結構,也是Web服務端的鼻祖。除了捆綁一些其他的工具外,Apache已經成為了世上最廣泛部署的開源系統,直到最近,世界上大多數網站仍運行著Apache系統。

但是,Apache並不是完美的,並且不再適合大規模系統。為什麼?因為他的進程模式雖然簡單而靈活,但並不適合大規模尤其是當要處理像PHP這種需要佔用大量內存應用程序代碼時。

一個典型的網絡應用服務器由兩部分組成。客戶端連接部分負責用戶瀏覽器與HTTP連接,保持長時間的TCP/IP協議,通常是1到2分鐘。對於一個大型的系統,服務器可能要同時承擔和處理數以萬計的並發連接。

這直接與Apache只有500條進程即500個HTTP連接的處理能力上限相衝突。而現今的瀏覽器讓這個問題更加嚴重, 因為現在的瀏覽器平均每個主機會打開六個網站鏈接(幾年前是兩個網站鏈接)。所以當超過100個用戶同時訪問時,Apache就已經滿負荷了。

第二部分是應用程序處理部分,這部分承擔了代碼運算。在大多數係統中,這部分工作是最消耗RAM和CPU資源的,因此進程數量必須被嚴格限制,通常是大約每1GB的內存10個進程,或者每個CPU核心兩個進程。因此一台4GB RAM、16內核的服務器最多只能運行32個應用程序進程。

但是,問題的關鍵是,Apache直接連接前端客戶端通訊組件與後端應用程序進程組件。如此一來,前端部分往往保持長時間的連接,常常達到幾分鐘,這導致後端部分將持續消耗內存和CPU資源。目前還沒有直接的方法能夠在大型系統中找到前後端服務的平衡,因此他們必須被分離開來。

目前有兩個主要的解決方法。第一個方法,也是現有系統上最容易的方法,就是在Apache前端安裝負載均衡服務器或者Nginx來處理客戶端連接部分。負載均衡服務器,像HAProxy或者Nginx能輕鬆處理成千上萬條並發的連接,並使Apache能夠真正的僅作為後端應用程序工作,來處理32個或是更多的進程。

第二種方案,也是最通用的辦法就是用Nginx替換Apache,同時使用PHP-PFM作為應用服務器。就像之前所提到的,這將分割前端客戶端通信部分和後端應用程序部分。 Nginx處理HTTP通訊協議,同時FPM處理後端應用程序部分,和那32個進程進行交互。

然而這幾種方法仍然還存在一些問題,主要是如何加載服務器的RPC調用,以及如何釋放已經完成的RPC調用。這兩個問題都會在後繼的博客中加以詳解。

另外,只使用Nginx的解決方法會給那些嚴重依賴於Apache功能的應用程序帶來問題,尤其是特別依賴rewrite rules, .htaccess, 或者mod_security等一些可選組件的應用程序。在這種情況下,在Apache前端增加安裝Nginx是最好的方法。

通常來說,所有新的系統都應該使用Nginx和PHP-FPM來部署。這能提供高性能增長特性,並且是平衡用戶和內存,CPU資源的最佳選擇。已存在的系統可以在前端使用Nginx或者HAProxy以達到同樣的效果,以便在當今現代網絡環境中為用戶提供更優質的服務。

轉自IT经理网

发表评论

电子邮件地址不会被公开。 必填项已用*标注