php的phpfpm
們都知道，php是不能直接操作 mysql的，他需要通過擴展提供介面調用，php的mysql擴展也好幾個，只支持面向過程的mysql，既支持面向過程也支持面向對象的mysqli，只支持面向對象的PDO，當然無論是那個擴展，也只是php語法寫法上的區別而已，底層其實是一樣的。
今天我們不講語法這些老掉牙的東西，我們隨便找一個擴展，來分析一下 php底層 和 mysql 之間的通信原理。
首先我們來理解一下 php-fpm 的工作原理，php-fpm 是一個 php-cgi 進程管理器，其實就是一個連接池，它和nginx配合的工作原理如下。
我們先從最簡單的靜態方式入手觀察他的工作原理
vim php-fpm.ini
[www]
pm = static
pm.max_children = 5
pm.max_requests = 2
上面三句話的含義是什麼呢:
1、static 表示靜態以靜態方式生成 php-fpm 進程
2、pm.max_children = 5 表示當 php-fpm 啟動時就啟動 5 個 php-fpm 子進程 等待處理 nginx 發過來的請求
3、pm.max_requests = 2 表示每個 php-fpm 子進程處理 2 個請求就銷毀，當然父進程每次看到有銷毀的自然也就會生成新的子進程
我們來簡單驗證一下這個說法：
首先重啟 php-fpm，讓它復位一下
接下來寫一條簡單的語句輸出當前進程ID
echo "當前 php-fpm 進程ID：".posix_getpid();
不斷刷新瀏覽器觀察輸出變化
當前 php-fpm 進程ID：24548
當前 php-fpm 進程ID：24549
當前 php-fpm 進程ID：24550
當前 php-fpm 進返備程ID：24547
當前 php-fpm 進程ID：24551
當前 php-fpm 進程ID：24548
當前 php-fpm 進程ID：24549
當前 php-fpm 進程ID：24550
當前 php-fpm 進程ID：24547
當前 php-fpm 進程ID：24551
當前 php-fpm 進程ID：24563
當前 php-fpm 進程ID：24564
當前 php-fpm 進程ID：24565
當前 php-fpm 進程ID：24566
當前 php-fpm 進程ID：24567
當前 php-fpm 進程ID：24563
當前 php-fpm 進程ID：24564
當前 php-fpm 進程ID：24565
當前 php-fpm 進程ID：24566
當前 php-fpm 進程ID：24567
當前 php-fpm 進程ID：24568
當前 php-fpm 進程ID：24569
當前 php-fpm 進程ID：24570
當前 php-fpm 進程ID：24571
當前 php-fpm 進程ID：24572
當前 php-fpm 進程ID：24568
當前 php-fpm 進程ID：24569
當前 php-fpm 進程ID：24570
當前 php-fpm 進程ID：24571
當前 php-fpm 進程ID：24572
可以看得出，第一批id不是按照順序執行的，進程id為24547的進程是在第四位處理的，然後從下信轎面開始，所有id都是順序執行的而且每次生成的一批id都是遞增，是不是有種mysql自增主鍵的趕腳呢？
這里需要注意的是，無論是靜態還是下面的動態配置方式，只要沒有設置 max_requests ，那麼進程是不會銷毀的，也就是說當一個進程裡面出現死循環或者內存溢出等導致進程僵死的情況出現的時候，處理的進程就會少一個了
好吧理解了靜態的處理方式，我們其實也很容易知道這個方式的弊端了，當然我們平時伺服器不可能就開5個進程每個進程處理2個請求，我們來做滑世肆一個簡單的加減乘除，看看一個伺服器應該開多少個 php-fpm 合適
首先我們來看看一個簡單的echo需要多少內存：
$size = memory_get_usage();
$unit = array('b','kb','mb','gb','tb','pb');
$memory = @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i];
echo "當前 php-cgi 進程所使用內存：".$memory;
觀察瀏覽器我們可以得到一下數據：
當前 php-cgi 進程所使用內存：227.17 kb
也就是說一個簡單的什麼都不幹的php就已經佔用了200多K的內存，當然這也不算多。
不過進程多了cpu切換進程速度就會變慢，所以這個數還是需要通過ab等測試工具才能測試出具體應該開多少比較合理
我們先從200開始，不斷的增加，架設增加到800的時候，效率和400一樣，那我們就沒必要開800那麼多進程浪費內存了。
那麼問題就來了，如果同一時間請求出超過400呢？有人說會排隊等待，真的會排隊等待嗎？答案明顯是 php-fpm 是沒能力排隊了，因為處理請求的php-fpm子進程都用完了，那麼等待也就只能是在 nginx 等待，通常一個 nginx 也不只是轉發請求給 php-fpm 就完事了，他還要處理靜態文件呢？如果這些php請求導致nginx的請求數過多一直在等待，那麼訪問靜態文件自然也會卡了，這時候我們就需要配置成下面的動態處理方式。
[www]
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 8
;pm.max_requests = 2
上面五句話的含義是什麼呢:
1、dynamic 表示靜態以動態方式生成 php-fpm 進程
2、pm.max_children = 10 同時活動的進程數 10個
3、pm.start_servers = 5 表示當 php-fpm 主進程啟動時就啟動 5 個 php-fpm 子進程
4、pm.min_spare_servers = 2 表示最小備用進程數
5、pm.max_spare_servers = 8 表示最大備用進程數
6、pm.max_requests = 2 上面說過就不說了
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
當前 php-fpm 進程ID：2270
當前 php-fpm 進程ID：2271
當前 php-fpm 進程ID：2272
當前 php-fpm 進程ID：2273
當前 php-fpm 進程ID：2274
⑵ php-fpm比php成為apache模塊好在哪
概述
寫這篇文章的是因為今天要Ubuntu下搭建LNMP環境，Nginx使用的是PHP-FPM，所以對Web伺服器與PHP解釋器的交互方式做了個整理。
眾所周知，PHP是跨平台、跨伺服器的語言，這也是它如此流行的原因之一。但是，很少有人知道PHP解釋器可以以不同的方式運行在Web伺服器中。PHP最常用的方式是以模塊的方式(mod_php)運行在Apache中，也是Apache運行PHP的默認方式。但是在Nginx中，Nginx又使用的是PHP-FPM。
這篇文章就對這些概念做個介紹，如有不對的地方，請多多批評指教。
什麼是PHP處理器(PHP handlers)?
首先需要記住的是，任何一種Web伺服器(Apache、Nginx等)都是被設計成向用戶發送html、圖片等靜態資源的，Web伺服器自身並不能解釋任何動態腳本(PHP、python等)。PHP處理器就是用來解釋Web應用中的PHP代碼，並將它解釋為HTML或其他靜態資源，然後將解析的結果傳給Web伺服器，最後再由Web伺服器發送給用戶。大多數的Web伺服器都不能解析PHP代碼，因此它需要一個能解析PHP代碼的程序，這就是PHP處理器。
mod_php
首先，來看一下以Apache模塊方式運行PHP。mod_php現在在linux各版本的軟體倉庫里都有，因此很容易被安裝。
當PHP以模塊的方式運行在Apache中時，PHP解釋器被「內嵌」在Apache的進程里。Apache不會調用任何外部的PHP進程，因此這種方式使Apache與PHP能更好的通信。但是，當以這種方式運行PHP的時候，哪怕Apache提供的僅僅是靜態的資源(如HTML)，Apache的每個子進程也都會載入 mod_php，導致了比正常情況下更多的內存開銷。
以這種方式運行的另一個缺點是，它僅能與Apache一起配合工作。另外，在小型的VPS和大型的網站中，這種方式也不合適，因為大型網站可能有很多靜態資源，而這些靜態資源是不需要PHP程序解釋的。
優點:
1.易於安裝和更新
2.容配置
缺點:
1.僅能與Apache一起工作
2.增加了Apache子進程內存開銷
3.當更改php.ini文件後，需要重啟Apache
FastCGI
FastCGI是交互程序與Web伺服器通用的協議介面，是早期CGI(Common Gateway Interface)的一個變種。相對於CGI來說，FastCGI減少了和Web伺服器交互的開銷，同時一次可以處理更多的請求。
Apache可以以mod_fcgid的形式使用FastCGI。其他Web伺服器，如lighttpd, nginx, Cherokee，甚至微軟的IIS也都能使用FastCGI。使用FastCGI，可以同時設置多個版本的PHP，這在某些情況下非常有用。
FastCGI還利用suexec來支持不同的用戶用自己的PHP的實例。這個特性對於在共享環境下提高安全性尤其重要。FastCGI在保證性能的同時，也減少了Web伺服器的內存開銷。
優點:
1.兼容多數Web伺服器
2.比mod_php占內存小
3.更多的配置項，包括多版本PHP和suexec
缺點
1.配置復雜
2.不被大家所熟知
PHP-FPM(FastCGI Process Manager)
PHP-FPM是Web伺服器使用PHP的一種最新方式，也是PHP FastCGI的另外一種實現。PHP-FPM對於運行在小型VPS和多伺服器上的Web應用非常應用。同時，它也可以被兼容FastCGI的任何Web伺服器所使用。
PHP-FPM使管理員能夠優雅地停止和啟動PHP工作進程而不丟失任何查詢。這允許我們逐步更新配置和二進制,而不會損失任何查詢。它還允許我們在發生任何意外破壞的情況下，緊急重啟進程。
優點:
1.兼容多數Web伺服器
2.比mod_php占內存小
3.更多的配置項，包括多版本PHP和suexec
缺點
1.配置復雜
2.不被大家所熟知
補充:Apache運行PHP的四種方式
mod_php (DSO，Dynamic Shared Object)
CGI
suPHP
FastCGI
總結
內容相對抽象，理解的不深，記錄下留作以後參考~:)
⑶ PHP涓鐨凢PM鏄鍋氫粈涔堢殑
FPM錛團astCGI 榪涚▼綆＄悊鍣錛夌敤浜庢浛鎹 PHP FastCGI 鐨勫ぇ閮ㄥ垎闄勫姞鍔熻兘錛屽逛簬楂樿礋杞界綉絝欐槸闈炲父鏈夌敤鐨勩傚畠鐨勫姛鑳藉寘鎷錛
鏀鎸佸鉤婊戝仠姝/鍚鍔ㄧ殑楂樼駭榪涚▼綆＄悊鍔熻兘錛
鍙浠ュ伐浣滀簬涓嶅悓鐨 uid/gid/chroot 鐜澧冧笅錛屽苟鐩戝惉涓嶅悓鐨勭鍙ｅ拰浣跨敤涓嶅悓鐨 php.ini 閰嶇疆鏂囦歡錛堝彲鍙栦唬 safe_mode 鐨勮劇疆錛夛紱
stdout 鍜 stderr 鏃ュ織璁板綍;
鍦ㄥ彂鐢熸剰澶栨儏鍐電殑鏃跺欒兘澶熼噸鏂板惎鍔ㄥ苟緙撳瓨琚鐮村潖鐨 opcode;
鏂囦歡涓婁紶浼樺寲鏀鎸;
"鎱㈡棩蹇" - 璁板綍鑴氭湰錛堜笉浠呰板綍鏂囦歡鍚嶏紝榪樿板綍 PHP backtrace 淇℃伅錛屽彲浠ヤ嬌鐢 ptrace鎴栬呯被浼煎伐鍏瘋誨彇鍜屽垎鏋愯繙紼嬭繘紼嬬殑榪愯屾暟鎹錛夎繍琛屾墍瀵艱嚧鐨勫紓甯哥紦鎱;
fastcgi_finish_request() - 鐗規畩鍔熻兘錛氱敤浜庡湪璇鋒眰瀹屾垚鍜屽埛鏂版暟鎹鍚庯紝緇х畫鍦ㄥ悗鍙版墽琛岃楁椂鐨勫伐浣滐紙褰曞叆瑙嗛戣漿鎹銆佺粺璁″勭悊絳夛級錛
鍔ㄦ侊紡闈欐佸瓙榪涚▼浜х敓錛
鍩烘湰 SAPI 榪愯岀姸鎬佷俊鎮錛堢被浼糀pache鐨 mod_status錛夛紱
鍩轟簬 php.ini 鐨勯厤緗鏂囦歡銆
⑷ php中fastcgi和php-fpm是什麼東西
首先要明白CGI是一個協議，方便程序員開發程序的，
而fastcgi是cgi的一個改良版，優化了CGI的性能，
php-fpm是實現了fastcgi的一個程序（當然，被官方收錄了）.
而php-fpm是php的一種工作模式。以服務的形式接收伺服器傳來的php文件，處理返回。
php一般還會以apache模塊的形式工作.
⑸ 啟動php-fpm為什麼有啟動了多個進程
php-fpm的兩種進程管理模式 php-fpm的進程數也是可以根據設置分為動態和靜態的。 一種是直接開啟指定數量的php-fpm進程，不再增加或者減少； 另一種則是開始的時候開啟一定數量的php-fpm進程，當請求量變大的時候，動態的增加php-fpm進程數到上限，當空閑的時候自動釋放空閑的進程數到一個下限。 這兩種不同的執行方式，可以根據伺服器的實際需求來進行調整。 這里先說一下涉及到這個的幾個參數吧，他們分別是pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。 pm表示使用那種方式，有兩個值可以選擇，就是static（靜態）或者dynamic（動態）。 在更老一些的版本中，dynamic被稱作apache-like。這個要注意看配置文件給出的說明了。PHP5.3 php-fpm的默認靜態處理方式會使得php-cgi的進程長期佔用內存而無法釋放，這也是導致nginx出錯的原因之 一，因此可以將php-fpm的處理方式改成apache模式。 下面4個參數的意思分別為： pm.max_children：靜態方式下開啟的php-fpm進程數量。 pm.start_servers：動態方式下的起始php-fpm進程數量。 pm.min_spare_servers：動態方式下的最小php-fpm進程數量。 pm.max_spare_servers：動態方式下的最大php-fpm進程數量。 如果dm設置為static，那麼其實只有pm.max_children這個參數生效。系統會開啟設置的數量個php-fpm進程。 如果dm設置為dynamic，那麼pm.max_children參數失效，後面3個參數生效。系統會在php-fpm運行開始的時候啟動 pm.start_servers個php-fpm進程，然後根據系統的需求動態在pm.min_spare_servers和 pm.max_spare_servers之間調整php-fpm進程數。 那麼，對於我們的伺服器，選擇哪種執行方式比較好呢？事實上，跟Apache一樣，我們運行的PHP程序在執行完成後，或多或少會有內存泄露的問題。 這也是為什麼開始的時候一個php-fpm進程只佔用3M左右內存，運行一段時間後就會上升到20-30M的原因了。所以，動態方式因為會結束掉多餘的進程，可以回收釋放一些內存，所以推薦在內存較少的伺服器或者VPS上使用。具體最大數量根據 內存/20M 得到。比如說512M的VPS，建議pm.max_spare_servers設置為20。至於pm.min_spare_servers，則建議根據伺服器的負載情況來設置，比較合適的值在5~10之間。 然後對於比較大內存的伺服器來說，設置為靜態的話會提高效率。因為頻繁開關php-fpm進程也會有時滯，所以內存夠大的情況下開靜態效果會更好。數量也可以根據內存/30M 得到。比如說2GB內存的伺服器，可以設置為50；4GB內存可以設置為100等。
⑹ 伺服器程序源代碼分析之二：php-fpm
php作為排名top2 互聯網開發工具，非常流行，可以參考：中國最大的25個網站採用技術選型方案
php這個名稱實際上有兩層含義
直接定義：
php-fpm從php5.3.3開始已經進入到php源代碼包，之前是作為patch存在的
很少人會去讀php本身源代碼，我6年前解決php內存泄露問題的時候做了些研究,最近再查看了一番，發現php的開發者很有誠意，這是一款非常出色的伺服器軟體，支持如下
在linux伺服器上，如果不設置 events.mechanism ,那麼默認就是採用epoll，所以
php-fpm的IO模型&並發處理能力和nginx是完全一致
nginx以性能卓越聞名，大部分程序員都認為php效率低下，看了源代碼，才知道這是傳奇啊
在高性能部署的時候，大家往往會針對性的優化nginx 。我自己之前部署php程序也犯了錯誤，8G內存的server，php-fpm的max children都會設置128+，現在看來太多了，參考nginx的部署:
php-fpm配置為 3倍 cpu core number就可以了
php-fpm穩定性比nginx稍差 這是因為php-fpm內置了一個php解析器,php-fpm進程就和php程序捆綁了，如果php腳本寫得不好，有死循環或者阻塞在某個遠端資源上，會拖累載入它的php-fpm進程
而nginx和後端應用伺服器之間通過網路連接，可以設置timeout，不容易堵死的
php-fpm的fastcgi是短連接 我原以為是長連接的，看了代碼才知道也是短連接，處理一個request就關閉掉
php-fpm介面採用fastcgi 非常遺憾，php-fpm和fastcgi完全綁定了，無法獨立使用 。只能部署在支持http-fcgi協議轉換程序背後(nginx）。其實可以考慮在php-fpm代碼包裡面引入http協議支持，這樣php-fpm可以獨立運行，讓nodejs無話可說
php-fpm等同於OpenResty OpenResty是一個國人開發的nginx模塊，就是在nginx引入lua解釋器. 實際上，它和php-fpm的唯一差別就是一個採用php語法，一個用lua，所以OpenResty要作為nginx增強包使用還可以，要選擇它作為一個主要編程工具，沒有任何必要
從架構上來說，php-fpm已經做到最好，超過大多數 python部署工具，我再也不黑它了
⑺ php-fpm設置多少合適
1 那麼，對於我們的伺服器，選擇哪種執行方式比較好呢？事實上，跟Apache一樣，我們運行的PHP程序在執行完成後，或多或少會有內存泄露的問題。這也是為什麼開始的時候一個php-fpm進程只佔用3M左右內存，運行一段時間後就會上升到20-30M的原因了。所以，動態方式因為會結束掉多餘 的進程，可以回收釋放一些內存，所以推薦在內存較少的伺服器或者VPS上使用。具體最大數量根據 內存/20M 得到。比如說512M的VPS，建議pm.max_spare_servers設置為20。至於pm.min_spare_servers，則建議根據伺服器的負載情況來設置，比較合適的值在5~10之間。
2 然後對於比較大內存的伺服器來說，設置為靜態的話會提高效率。因為頻繁開關php-fpm進程也會有時滯，所以內存夠大的情況下開靜態效果會更好。數量也可以根據 內存/30M 得到。比如說2GB內存的伺服器，可以設置為50；4GB內存可以設置為100等