phpcgi進程數

⑴ 什麼是CGI，FastCGI，php-CGI，PHP-FPM，Spawn-FCGI

什麼是CGI
CGI全稱是「公共網關介面」(Common Gateway Interface)，HTTP伺服器與你的或其它機器上的程序進行「交談」的一種工具，其程序須運行在網路伺服器上。
CGI可以用任何一種語言編寫，只要這種語言具有標准輸入、輸出和環境變數。如php,perl,tcl等
什麼是FastCGI
FastCGI像是一個常駐(long-live)型的CGI，它可以一直執行著，只要激活後，不會每次都要花費時間去fork一次(這是CGI最為人詬病的fork-and-execute 模式)。它還支持分布式的運算, 即 FastCGI 程序可以在網站伺服器以外的主機上執行並且接受來自其它網站伺服器來的請求。
FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行為是將CGI解釋器進程保持在內存中並因此獲得較高的性能。眾所周知，CGI解釋器的反復載入是CGI性能低下的主要原因，如果CGI解釋器保持在內存中並接受FastCGI進程管理器調度，則可以提供良好的性能、伸縮性、Fail- Over特性等等。
FastCGI與CGI特點
1、如CGI，FastCGI也具有語言無關性.
2、如CGI, FastCGI在進程中的應用程序，獨立於核心web伺服器運行,提供了一個比API更安全的環境。(APIs把應用程序的代碼與核心的web伺服器鏈接在一起，這意味著在一個錯誤的API的應用程序可能會損壞其他應用程序或核心伺服器; 惡意的API的應用程序代碼甚至可以竊取另一個應用程序或核心伺服器的密鑰。)
3、FastCGI技術目前支持語言有：C/C++、Java、Perl、Tcl、Python、SmallTalk、Ruby等。相關模塊在Apache, ISS, Lighttpd等流行的伺服器上也是可用的。
4、如CGI，FastCGI的不依賴於任何Web伺服器的內部架構，因此即使伺服器技術的變化, 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)可以工作。
FastCGI的不足
因為是多進程，所以比CGI多線程消耗更多的伺服器內存，PHP-CGI解釋器每進程消耗7至25兆內存，將這個數字乘以50或100就是很大的內存數。

Nginx 0.8.46+PHP 5.2.14(FastCGI)伺服器在3萬並發連接下，開啟的10個Nginx進程消耗150M內存（15M*10=150M），開啟的64個php-cgi進程消耗1280M內存（20M*64=1280M），加上系統自身消耗的內存，總共消耗不到2GB內存。如果伺服器內存較小，完全可以只開啟25個php-cgi進程，這樣php-cgi消耗的總內存數才500M。
什麼是PHP-CGI
PHP-CGI是PHP自帶的FastCGI管理器。
啟動PHP-CGI，使用如下命令：
1

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-FPM來控制PHP-CGI的FastCGI進程
1
2
3
4
5
6
7
8

/usr/local/php/sbin/php-fpm{start|stop|quit|restart|reload|logrotate}

--start 啟動php的fastcgi進程
--stop 強制終止php的fastcgi進程
--quit 平滑終止php的fastcgi進程
--restart 重啟php的fastcgi進程
--reload 重新平滑載入php的php.ini
--logrotate 重新啟用log文件

什麼是Spawn-FCGI
Spawn-FCGI是一個通用的FastCGI管理伺服器，它是lighttpd中的一部份，很多人都用Lighttpd的Spawn-FCGI進行FastCGI模式下的管理工作，不過有不少缺點。而PHP-FPM的出現多少緩解了一些問題，但PHP-FPM有個缺點就是要重新編譯，這對於一些已經運行的環境可能有不小的風險(refer)，在php 5.3.3中可以直接使用PHP-FPM了。
Spawn-FCGI目前已經獨成為一個項目，更加穩定一些，也給很多Web 站點的配置帶來便利。已經有不少站點將它與nginx搭配來解決動態網頁。
最新的lighttpd也沒有包含這一塊了(http://www.lighttpd.net/search?q=Spawn-FCGI)，但可以在以前版本中找到它。在lighttpd-1.4.15版本中就包含了(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz)
目前Spawn-FCGI的下載地址是http://redmine.lighttpd.net/projects/spawn-fcgi，最新版本是http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
註：最新的Spawn-FCGI可以到lighttpd.net網站搜索「Spawn-FCGI」找到它的最新版本發布地址
下面我們就可以使用Spawn-FCGI來控制php-CGI的FastCGI進程了

1

/usr/local/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -C 5 -u www-data -g www-data -f /usr/bin/php-CGI

參數含義如下:
-f 指定調用FastCGI的進程的執行程序位置，根據系統上所裝的PHP的情況具體設置
-a 綁定到地址addr
-p 綁定到埠port
-s 綁定到unix socket的路徑path
-C 指定產生的FastCGI的進程數，默認為5(僅用於PHP)
-P 指定產生的進程的PID文件路徑
-u和-g FastCGI使用什麼身份(-u 用戶 -g 用戶組)運行，Ubuntu下可以使用www-data，其他的根據情況配置，如nobody、apache等
PHP-FPM與spawn-CGI對比測試
PHP-FPM的使用非常方便,配置都是在PHP-FPM.ini的文件內，而啟動、重啟都可以從php/sbin/PHP-FPM中進行。更方便的是修改php.ini後可以直接使用PHP-FPM reload進行載入，無需殺掉進程就可以完成php.ini的修改載入
結果顯示使用PHP-FPM可以使php有不小的性能提升。PHP-FPM控制的進程cpu回收的速度比較慢,內存分配的很均勻。
Spawn-FCGI控制的進程CPU下降的很快,而內存分配的比較不均勻。有很多進程似乎��分配到,而另外一些卻佔用很高。可能是由於進程任務分配的不均勻導致的.而這也導致了總體響應速度的下降。而PHP-FPM合理的分配，導致總體響應的提到以及任務的平均。
PHP-FPM與Spawn-FCGI功能比較
http://php-fpm.org/about/
PHP-FPM、Spawn-FCGI都是守護php-cgi的進程管理器。

⑵ php_cgi進程並行處理問題

php_cgi進程並行處理會引發消耗cpu過多導致機器負責過高的問題。
解決方法是做出以下調整：
1. nginx少開兩個進程：
user nobody nobody;
worker_processes 2;
worker_rlimit_nofile 51200;
2.調整php_cgi的子進程數：
/usr/local/nginx/sbin/spawn-fcgi -a 127.0.0.1 -p 1026 -C 12 -u nobody -f /usr/local/php-fcgi/bin/php-cgi
/usr/local/nginx/sbin/spawn-fcgi -a 127.0.0.1 -p 1027 -C 12 -u nobody -f /usr/local/php-fcgi/bin/php-cg
3.重啟php_cgi和nginx發現效果不佳。查資料發現有可能eAccelerater模塊不兼容。
4.修改/usr/local/php-fcgi/lib/php.ini 禁止eaccelerator模塊 改為apc加速：
extension = "apc.so"
apc.enabled = 1
apc.cache_by_default = on
apc.shm_segments = 1
apc.shm_size = 128M
apc.ttl = 7200
apc.user_ttl = 7200
apc.num_files_hint = 1024
apc.write_lock = On
apc.gc_ttl=3600
apc.ttl=0
apc.mmap_file_mask=/tmp/apc.XXXXXX
5.重啟nginx和php_cgi即可。