我們大多數(shù)的客戶在他們的服務器上使用Apache作為Web服務器，尤其是部署在一個基于PHP系統(tǒng)的前端并且使用mod-PHP。鑒于擴張性和性能方面的原因，我們通常會建議他們改用Nginx和FPM。

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

但是，Apache并不是完美的，并且不再適合大規(guī)模系統(tǒng)。為什么？因為他的進程模式雖然簡單而靈活，但并不適合大規(guī)模尤其是當要處理像PHP這種需要占用大量內(nèi)存應用程序代碼時。

一個典型的網(wǎng)絡應用服務器由兩部分組成�？蛻舳诉B接部分負責用戶瀏覽器與HTTP連接，保持長時間的TCP/IP協(xié)議，通常是1到2分鐘。對于一個大型的系統(tǒng)，服務器可能要同時承擔和處理數(shù)以萬計的并發(fā)連接。

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

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

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

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

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

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

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

通常來說，所有新的系統(tǒng)都應該使用Nginx和PHP-FPM來部署。這能提供高性能增長特性，并且是平衡用戶和內(nèi)存，CPU資源的最佳選擇。已存在的系統(tǒng)可以在前端使用Nginx或者HAProxy以達到同樣的效果，以便在當今現(xiàn)代網(wǎng)絡環(huán)境中為用戶提供更優(yōu)質(zhì)的服務。