我们专注服务于当下互联网基础设施建设与云计算、大数据时代的各种需求!

mod_fastcgi与mod_fastcgid的一些认识

稍微整理我對於 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 兩款授權),是個互惠要求性低且相容性高的授權條款。