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

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

 [[67986]]

但是，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以達到同樣的效果，以便在當今現代網絡環境中為用戶提供更優質的服務。