我們大多數的客戶在他們的服務器上使用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以達到同樣的效果，以便在當今現代網絡環境中爲用戶提供更優質的服務。
（Authored by Steve Mushero / ChinaNetCloud CEO & CTO 本博客英文原文請點此查看）
