Ⅰ 如何通俗的解釋cgi，fastcgi，php-fpm之間的關系
這個問題可以分兩個層面討論：
1. PHP 解釋器是否嵌入 Web 伺服器進程內部執行
mod_php 通過嵌入 PHP 解釋器到 Apache 進程中，只能與 Apache 配合使用，而 cgi 和 fast-cgi 以獨立的進程的形式出現，只要對應的Web伺服器實現 cgi 或者 fast-cgi 協議，就能夠處理 PHP 請求。
mod_php 這種嵌入的方式最大的弊端就是內存佔用大，不論是否用到 PHP 解釋器都會將其載入到內存中，典型的就是處理CSS、JS之類的靜態文件是完全沒有必要載入解釋器。
2. 單個進程處理的請求數量
mod_php 和 fast-cgi 的模式在每個進程的生命周期內能夠處理多個請求，而 cgi 的模式處理一個請求就馬上銷毀進程，在高並發的場景下 cgi 的性能非常糟糕。
綜上，如果對性能有極高的要求，可以將靜態請求和動態請求分開，這時 Nginx + php-fpm 是比較好的選擇。
PS: cgi、fastcgi 通常指 Web 伺服器與解釋器通信的協議規范，而 php-fpm 是 fastcgi 協議的一個實現。
Ⅱ 關於FastCGI、php-cgi、php-fpm的區別是什麼，各自有什麼用途，以及相互間的關系是什麼
fastcgi是一個通用網關介面，用於web伺服器(iis, apache)和應用程序通信。
php-cgi是php平台的cgi程序
以上兩個結合，可以使php整合在web服務中
php-fpm是一個獨立的php-fcgi管理軟體，它要整合進web服務中，需要使用代理模式
一般與nginx搭配。也可以與apache搭配
php-fpm一般不直接作為服務容器提供外網訪問，而是通過常用web容器作代理
php作為伺服器端的解析程序，運行模式分很多種，fastcgi, mod_php, proxy(代理)等。
與iis搭配時一般採用fast-cgi模式，iis自帶fast-cgi引擎，配置好php參數即可
與apache搭配，在windows平台下，一般也是fast-cgi模式，在linux系統中一般是mod_php模式，把php作為一個子模塊載入
也可以配置php-fpm 然後在apache中配置代理模式
與nginx搭配，一般就是用php-fpm+代理模式了
Ⅲ php5-cgi和php5-fpm 這兩個東西是什麼意思啊有什麼區別
什麼是PHP-CGI:
PHP-CGI是PHP自帶的FastCGI管理器。
啟動PHP-CGI，使用如下命令：
php-cgi -b 127.0.0.1:9000
PHP-CGI的不足:
1、php-cgi變更php.ini配置後需重啟php-cgi才能讓新的php-ini生效，不可以平滑重啟
2、直接殺死php-cgi進程,php就不能運行了。(PHP-FPM和Spawn-FCGI就沒有這個問題,守護進程會平滑從新生成新的子進程。）
什麼是PHP-FPM
PHP-FPM是一個PHP FastCGI管理器，是只用於PHP的,可以在 http://php-fpm.org/download下載得到.
PHP-FPM其實是PHP源代碼的一個補丁，旨在將FastCGI進程管理整合進PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP後才可以使用。
現在我們可以在最新的PHP 5.3.2的源碼樹里下載得到直接整合了PHP-FPM的分支，據說下個版本會融合進PHP的主分支去。相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，而且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。
PHP5.3.3已經集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP進程管理方式，可以有效控制內存和進程、可以平滑重載PHP配置，比spawn-fcgi具有更多有點，所以被PHP官方收錄了。在./configure的時候帶 –enable-fpm參數即可開啟PHP-FPM。
二者的區別：
php-cgi是被調用的進程，php-fpm是配置和管理進程的。
Ⅳ php教程之php的幾種運行模式
php一共分為五大運行模式：包括cgi 、fast-cgi、cli、isapi、apache 模塊的 DLLCGI
CGI即通用網關介面(Common Gateway Interface)，它是一段程序，通俗的講CGI就象是一座橋，把網頁和WEB伺服器中的執行程序連接起來，它把HTML接收的指令傳遞給伺服器的執 行程序，再把伺服器執行程序的結果返還給HTML頁。CGI 的跨平台性能極佳，幾乎可以在任何操作系統上實現。
CGI方式在遇到連接請求（用戶 請求）先要創建cgi的子進程，激活一個CGI進程，然後處理請求，處理完後結束這個子進程。這就是fork-and-execute模式。所以用cgi 方式的伺服器有多少連接請求就會有多少cgi子進程，子進程反復載入是cgi性能低下的主要原因。都會當用戶請求數量非常多時，會大量擠占系統的資源如內 存，CPU時間等，造成效能低下。CGI-FCGI
fast-cgi 是cgi的升級版本，FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行著，只要激活後，不會每次都要花費時間去fork一 次。PHP使用PHP-FPM(FastCGI Process Manager)，全稱PHP FastCGI進程管理器進行管理。FastCGI的工作原理
1、Web Server啟動時載入FastCGI進程管理器(IIS ISAPI或Apache Mole)
2、FastCGI進程管理器自身初始化，啟動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web Server的連接。
3、當客戶端請求到達Web Server時，FastCGI進程管理器選擇並連接到一個CGI解釋器。Web server將CGI環境變數和標准輸入發送到FastCGI子進程php-cgi。
4、 FastCGI子進程完成處理後將標准輸出和錯誤信息從同一連接返回Web Server。當FastCGI子進程關閉連接時，請求便告處理完成。FastCGI子進程接著等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接。 在CGI模式中，php-cgi在此便退出了。在上述情況中，你可以想像CGI通常有多慢。每一個Web 請求PHP都必須重新解析php.ini、重新載入全部擴展並重初始化全部數據結構。使用FastCGI，所有這些都只在進程啟動時發生一次。一個額外的 好處是，持續資料庫連接(Persistent database connection)可以工作。APACHE2HANDLER
PHP作為Apache模塊，Apache伺服器在系統啟動後，預先生成多個進程副本駐留在內存中，一旦有請求出 現，就立即使用這些空餘的子進程進行處理，這樣就不存在生成子進程造成的延遲了。這些伺服器副本在處理完一次HTTP請求之後並不立即退出，而是停留在計 算機中等待下次請求。對於客戶瀏覽器的請求反應更快，性能較高。
apache模塊的DLL：
該運行模式是我們以前在windows環境下使用apache伺服器經常使用的，而在模塊化(DLL)中，PHP是與Web伺服器一起啟動並運行的。（是apache在CGI的基礎上進行的一種擴展，加快PHP的運行效率）ISAPI:
ISAPI即Internet Server Application Program Interface，是微軟提供的一套面向Internet服務的API介面
一個ISAPI的DLL，可以在被用戶請求激活後長駐內存，等待用戶的另一個請求，還可以在一個DLL里設置多個用戶請求處理函數，此外，
ISAPI的DLL應用程序和WWW伺服器處於同一個進程中，效率要顯著高於CGI。（由於微軟的排他性，只能運行於windows環境)cli:
cli是php的命令行運行模式，大家經常會使用它，但是可能並沒有注意到（例如：我們在linux下經常使用 「php -m」查找PHP安裝了那些擴展就是PHP命令行運行模式；有興趣的同學可以輸入php -h去深入研究該運行模式）總結：
每種運行模式都有自己的優缺點，沒有絕對的好與壞，主要是看大家處理何種環境。
Ⅳ 502 bad gateway nginx怎麼解決
發生原因
1、PHP FastCGI進程數不夠用
當網站並發訪問巨大時，php fastcgi的進程數不有一定的保障，因為cgi是單線程多進程工作的，也就是說cgi需要處理完一個頁面後再繼續下一個頁面。如果進程數不夠，當訪問巨大的時候，cgi按排隊處理之前的請求，之後的請求只有被放棄。這個時候nginx就會不時的出現502錯誤。
2、PHP FastCGI的內存不夠用
當nginx返回靜態頁面時，這個問題一般不會出現，因為nginx不需要php cgi的處理而直接返回靜態頁面。但是當網頁需要處理大量的php復雜操作的時候，例如執行api採集，或者採集頁面的時候，那對php的要求是相當高的，如果配置給他的內存太少，那很容易就會導致php崩潰。
1、首先判斷是不是php fastcgi進程數是否夠用。
netstat -anpo | grep "php-cgi" | wc -l
如果實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，需要增大。 但是要注意計算你的內存是否足夠支撐更多的進程數，如果物理機內存並不足夠大，加大這個進程數是沒有用處的。
2、部分PHP程序的執行時間超過了Nginx的等待時間，可以適當增加nginx.conf配置文件中FastCGI的timeout時間，如下：
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......
php.ini中memory_limit設低了會出錯，修改了php.ini的memory_limit為64M，重啟nginx，發現好了，原來是PHP的內存不足了。
如果以上方法依然不能解決問題，請嘗試優化你的php程序，盡量的減少採集和資料庫操作，加快其反應速度，有時候往往是因為自己的php程序反應速度太慢造成的。
3：目前lnmp一鍵安裝包比較多的問題就是502 Bad Gateway，大部分情況下原因是在安裝php前，腳本中某些lib包可能沒有安裝上，造成php沒有編譯安裝成功。
解決方法：
可以嘗試根據lnmp一鍵安裝包中的腳本手動安裝一下，看看是什麼錯誤導致的，在網上搜索一下，或者把錯誤信息發上來。我們給你分析一下錯誤原因。
4：
在php.ini里，eaccelerator配置項一定要放在Zend Optimizer配置之前，否則也可能引起502 Bad Gateway
第三種原因：
在安裝好使用過程中出現502問題，一般是因為默認php-cgi進程是5個，可能因為phpcgi進程不夠用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 將其中的max_children值適當增加。（一般1個php-cgi佔有20M內存，請依照內存來設定該值）
也有可能是max_requests值不夠用。
5：
php執行超時，修改/usr/local/php/etc/php.ini 將max_execution_time 改為300
第五種原因：
磁碟空間不足，如mysql日誌佔用大量空間
6：
查看php-cgi進程是否在運行
可以通過# top 命令查看。
nginx反向代理解決辦法有點不同
將nginx的error log打開，發現」pstream sent too big header while reading response header from upstream」這樣的錯誤提示，查閱了一下資料，大意是nginx緩沖區有一個bug造成的,我們網站的頁面消耗佔用緩沖區可能過大
apache返回的header 太大nginx處理不過來就導致了。
代碼如下 復制代碼
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
#charset koi8-r;
# access_log off;
location / {
#添加這3行 ，
proxy_buffer_size 64k;
proxy_buffers 32 32k;
proxy_busy_buffers_size 128k;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
set $spider '';
if ( $http_user_agent ~ Baispider) {
set $spider Bai;
}
............
如果是 nginx+PHPcgi 就該
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on
011/01/07 11:12:57 [error] 10770#0: *38585340 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 116.22.131.154, server: *.xywy.com, request: "GET /ysmp/index.php?did=124994 HTTP/1.0", upstream: "http://127.0.0.1:8080/ysmp/index.php?did=124994", host: "xywy.yn16.com"
後來原來那錯誤沒了出了新錯誤了
upstream timed out 超時？
代碼如下 復制代碼
server {
listen 80;
server_name *.xywy.com ;
large_client_header_buffers 4 16k;
client_max_body_size 300m;
client_body_buffer_size 128k;
proxy_connect_timeout 600;
proxy_read_timeout 600;
proxy_send_timeout 600;
proxy_buffer_size 64k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
#charset koi8-r;
# access_log off;
request_terminate_timeout
如果主要是在一些post或者資料庫操作的時候出現502這種情況，而不是在靜態頁面操作中常見，那麼可以查看一下php-fpm.conf設置中的一項：
request_terminate_timeout
這個值是max_execution_time，就是fast-cgi的執行腳本時間。
0s
0s為關閉，就是無限執行下去。（當時裝的時候沒仔細看就改了一個數字）問題解決了，執行很長時間也不會出錯了。優化fastcgi中，還可以改改這個值5s 看看效果。
Ⅵ 護衛神PHP套件出現"FastCGI"等錯誤怎麼解決
錯誤一： 處理程序「FastCGI」在其模塊列表中有一個錯誤模塊「FastCgiMole」。
英文系統提示：Handler 「FastCGI」 has a bad mole 「FastCgiMole」 in its mole list。
原因分析：這個主要是沒有安裝應用程序開發功能。
解決辦法：把應用程序開發功能選擇上就可以了，PHP的CGI版本，CGI的功能是必須選擇的。
錯誤二：模塊IsapiMole通知ExecuteRequestHandler處理程序PHP-Handler錯誤代碼0x800700
或 處理程序「AboMapperCustom-5095705」在其模塊列表中有一個錯誤模塊「IsapiMole」
原因分析：沒有安裝ISAPI擴展。
解決辦法：在IIS安裝ISAPI擴展即可。
錯誤三：The FastCGI Handler was unable to process the request.
原因分析：這種多出現於PHP升級，一般是你升級前的PHP.ini存放在C:\windows\system32\php.ini
解決辦法：刪除C:\windows\system32\php.ini，並重啟IIS。
錯誤四：
解決辦法：這個可能是許可權不足導致的，在網站根目錄的上一級目錄加Users的讀許可權即可。
錯誤五：
錯誤提示：Unable to place a FastCGI process in a JobObject. Try disabling the Application Pool CPU Limit feature
原因分析：IIS開啟了程序池的CPU限制，而FastCGI模式的PHP不支持CPU限制。
解決辦法：取消程序池CPU限制，或使用ISAPI模式的PHP。
錯誤六：
安裝PHP7.0套件出現錯誤「FastCGI進程意外退出」，雙擊「php-cgi.exe」出現提示「無法啟動此程序，因為計算機中丟失 api-ms-win-crt-stdio-l1-1-0.dll。嘗試重新安裝該程序以解決此問題。」，如圖：
原因分析：出現此種情況，是因為伺服器無法安裝VC++ 2015運行庫，導致php運行環境不具備，因此出錯。
解決辦法：據分析，出現此種情況的解決辦法最好就是重裝系統，並且更換操作系統，如果還不行，建議打SP1補丁。
Ⅶ php以fastCGI的方式運行時文件系統許可權問題及解決方法
在IIS7.0上以FastCGI方式配置好PHP運行環境，測試可以正常運行PHP程序後，將PHP程序部署上去，導入程序原來的數據和配置信息。很快就有問題出來啦下面我們就詳細記錄下。
今天准備將一個php
demo放在IIS下運行，網站在IIS下的配置是這樣的：
應用程序池是集成模式下的.net
framework
2.0(2.0或4.0沒什麼關系，因為php以fastCGI的方式在跑),
應用程序池標識配置為IIS內置的NETWORKSERVICE,
使用的認證方式為匿名身份驗證。
打開本地的網站，訪問php頁面,
出現了500錯誤。
好吧，是許可權問題，最簡單的解決辦法是把C:的許可權設成Everyone,
並允許完全控制：
重新訪問php頁面，成功了：
上面的方法是夠簡單，但也太不安全了，平時本地搭個demo這樣做沒問題，真正上線的時候，這樣做遲早出問題的。
於是重新設置，把該目錄下的只讀許可權賦給NETWRORKSERVICE帳號再試一下
不過問題還是沒有解決，訪問的時候，出現了401錯誤
錯誤信息中包括顯示登錄用戶為匿名，檢查了網站下的身份驗證(再點擊
匿名身份驗證->編輯),原來網站默認情況下，在登錄方法為匿名時，使用的默認登錄用戶為IUSR(就是我們看到的匿名登錄用戶了)
那麼解決辦法就是：
1.
將IUSR設置為C:的讀許可權，類似之前對NETWORKSERVICE的設置。
2.
或選擇使用應用程序池標識即可。
經試驗，方法1與2都成功。
Note:NETWORKSERVICE在IIS7中隸屬於iis_iusers用戶組，之前對NETWORKSERVICE的設置也可以改為對iis_iusers的設置，同樣也可以解決問題，只是許可權被進一步放寬了而已。
以上所述就是本文的全部內容了，希望大家能夠喜歡。