稍微整理我對於 mod_fastcgi / mod_fcgid / PHP-FPM 之間的理解。

1. Maintainer and License

mod_fastcgi 是 FastCGI.com 負責的項目，使用的是 FastCGI 授權條款。

mod_fcgid 是 Apache 基金會負責的項目，使用的是 Apache-2.0 授權條款。

因此，不僅主要負責單位不同，其授權方式也不同。

2. License issue

因為 mod_fastcgi 的授權不是標準的自由/開放源碼授權條款，所以顯得與其他授權條款格格不入，再加上 Linux distribution 套件管理政策的因素，使得 mod_fastcgi 難以全面進入所有 Distribution 官方庫。

這點在 Robert J. Brown 的部落格上有說明，「mod_fastcgi SRPM for Fedora, CentOS, RHEL」。

3. mod_fastcgi is not (much) development

有注意兩者關係的人，會發現 mod_fastcgi 幾乎沒有再繼續開發了，因此也使得網路上許多人轉而推薦 mod_fcgid。其實這是最大的誤解。

mod_fastcgi 在其官方網站上有聲明，

There is not much development on FastCGI because it is a very stable protocol / application.

 

But, yes, we are here…

官方說法是，FastCGI protocol 是一個輕量級且成熟的通訊協定，所以不太需要再額外加上新功能，而目前的工作主要在於瑕疵修復，也就幾乎沒有任何開發進展。

4. FastCGI servers design differs

雖然 mod_fastcgi 與 mod_fcgid 都支援 FastCGI protocol，但設計的概念不同。

mod_fcgid 的理念是快速的結束 FastCGI server 並再快速的產生一個。這個方法與 FastCGI protocol 初衷不同，FastCGI protocol 是希望能夠允許 long-running request。

以 PHP 應用為例，為了加速 PHP 效能，通常會使用 bytecode / opcode cache，例如 APC、eAccelerator 或 Xcache 等。但為了共享 cache，意謂著 process / request 必須在同一個 shared cache 中，而無法跨不同的 FastCGI or FCGI process。因此在設計上，只能允許一個 PHP process 啟動，然後由此 spawn 多個 children process，使得 children 能夠享用 parent 的 bytecode / opcode。

這也是為什麼我們常看到使用 mod_fastcgi 或 mod_fcgid 時，會限制 PHP process 僅能有一個的情形。

問題來了，mod_fcgid 一次僅能同時送一個 request，使得 PHP 在同一時間僅能處理一個 request，雖然 mod_fcgid 能夠很快速的產生與釋放資源，但這在處理大量連線的環境中可能還是容易出現阻塞。然而 mod_fastcgi 則能夠同時送多個 request，以致於沒有這個問題。

不過這是 2 年前的研究結果，不確定新的 mod_fcgid 是否有解決這個問題。

但無論如何，PHP 的使用者現在已不需要在 mod_fastcgi 及 mod_fcgid 之間作選擇，因為 PHP 5.3.3 之後提供的 PHP-FPM (PHP FastCGI Process Manager)，能夠更有效率的解決這個問題。況且 PHP-FPM 使用的是標準 BSD-2-Clause License (BSD 兩款授權)，是個互惠要求性低且相容性高的授權條款。