Ⅰ 伺服器程序源代碼分析之二：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部署工具，我再也不黑它了
Ⅱ PHP8、FPM及部分擴展編譯安裝
本著能懶則懶的原則，之前我都是寶塔、lnmp腳本等「一鍵」
再不濟也得來個 apt/yum install php
什麼？源碼 make install ？ 編譯參數一言難盡，勸退勸退...我只是想要個開發環境而已
沒關系！我來整理一下常用模塊以及參數！環境為 ubuntu/debian
檢查壓縮包的完整性，與官網 sha256比較
安裝以下包
官方的拓展分類
根據需要的模塊添加其後對應的參數
包含常用模塊，可以直接使用
編譯並安裝後
復制 php.ini 到默認目錄 /usr/local/lib/
檢查 php安裝是否正確
復制 fpm 配置文件、運行服務文件
www.conf php-fpm.conf php-fpm.service
修改 fpm 用戶和組，默認為nobody
修改服務文件，取消只讀 不然日誌不能讀寫無法啟動
設置自啟動並運行
本地起服務測試
No package 'libxml-2.0' found
No package 『sqlite3『 found
configure: WARNING: unrecognized options: –with-gd
No package 'zlib' found
No package 'libpng' found
No package 'oniguruma' found
No package 'libcurl' found
No package 'libsystemd' found
No package 'openssl' found
No package 'libzip' found
Ⅲ 如何用supervisor守護php-fpm主進程以實現php-fpm的自動重啟
1. 安裝supervisor
supervisor本身是python實現的，而且是調研階段，故先創建一個新的virtualenv環境，然後用pip安裝好supervisor包。
至此，基本的調研環境搭建完畢。當然，php-fpm和PHP環境以及前端的Nginx是早就ready的。
2. 分析php-fpm.sh腳本
通常編譯安裝PHP後，php-fpm這個2進制的C程序也會被編譯並安裝好，典型路徑在php_install_path/sbin/目錄下。該
目錄下還有個名為php-fpm.sh的腳本用於控制php-fpm進程的start/stop/restart/reload等動作。
./sbin/php-fpm.sh腳本中，」start」操作啟動了php-fpm主進程，其餘的操作都是通過向php-fpm master進程發signal實現的。
<code class="hljs bash">## code segment in php-fpm.sh
case "$1" in
start)
echo -n "Starting php-fpm "
## 下面這行是關鍵命令
$php_fpm_BIN --daemonize $php_opts
if [ "$?" != 0 ] ; then
echo " failed"
exit 1
fi
wait_for_pid created $php_fpm_PID
if [ -n "$try" ] ; then
echo " failed"
exit 1
else
echo " done"
fi
;;</code>
從上面是終端輸入」./sbin/php-fpm.sh
start」時，實際執行的代碼，可以看到，php-fpm進程的啟動參數是–daemonize
$php_opts，而$php_opts的值為」–fpm-config $php_fpm_CONF –pid $php_fpm_PID」。
注意: php-fpm.sh啟動php-fpm master進程時，傳入了daemonize參數，表明php-fpm master process以守護（daemon）方式啟動，而根據supervisor文檔的說明，當用supervisor監護進程時，被監護進程不能是守護進程，這是由於守護進程通常會在fork完子進程後就讓父進程」結束生命」，也即由supervisor創建的父進程退出，此時，supervisor無法再監護已退出進程創建出來的子進程。關於daemon process的行為，可以參考Linux Daemon Writing HOWTO一文來理解。
根據上面的分析，我們知道，只要supervisor啟動php-fpm進程時，不傳入daemonize參數即可。
3. 實現php-fpm主進程守護功能的supervisor配置文件
上面的分析已經告訴我們應該怎麼解決問題了，下面直接上驗證可用的配置文件。文件位於php-fpm.conf同級目錄下（典型路徑為php_install_path/etc/）。
<code class="hljs bash"><code class="hljs vhdl">
[inet_http_server] ; inet (TCP) server disabled by default
port=127.0.0.1:9015 ; (ip_address:port specifier, *:port for all iface)
[supervisord]
logfile=./var/log/supervisord.log ; (main log file;default $CWD/supervisord.log)
logfile_maxbytes=50MB ; (max main logfile bytes b4 rotation;default 50MB)
logfile_backups=2 ; (num of main logfile rotation backups;default 10)
loglevel=info ; (log level;default info; others: debug,warn,trace)
pidfile=./var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
nodaemon=false ; (start in foreground if true;default false)
minfds=1024 ; (min. avail startup file descriptors;default 1024)
minprocs=200 ; (min. avail process descriptors;default 200)
identifier=sup.php-fpm ; (supervisord identifier, default is 'supervisor')
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
[supervisorctl]
serverurl=http://127.0.0.1:9015 ; use an http:// url to specify an inet socket
[program:php-fpm]
command=bash -c "sleep 1 && /home/slvher/tools/php/5.6.11/sbin/php-fpm --fpm-config /home/slvher/tools/php/5.6.11/etc/php-fpm.conf --pid /home/slvher/tools/php/5.6.11/var/run/php-fpm.pid" ; the program (relative uses PATH, can take args)
process_name=%(program_name)s ; process_name expr (default %(program_name)s)
autostart=true ; start at supervisord start (default: true)
autorestart=true ; whether/when to restart (default: unexpected)
startretries=5 ; max # of serial start failures (default 3)
exitcodes=0,2,70 ; 'expected' exit codes for process (default 0,2)
stopsignal=QUIT ; signal used to kill process (default TERM)
stopwaitsecs=2 ; max num secs to wait b4 SIGKILL (default 10)
</code></code>
配置文件結構通過查看supervisor文檔很容易就能掌握，有兩個配置項需要特別注意：
1) command
它指定了supervisor要監控的進程的啟動命令，可以看到，這里我們沒有給php-fpm傳入daemonize參數，其餘參數只是展開了php-fpm.sh中的shell變數而已。
大家已經注意到，command也不是直接調起php-fpm，而是通過bash -c執行了兩個命令，而第一個命令是sleep 1。這是由於php-fpm在stop後，其佔用的埠通常不能立即釋放，此時，supervisor以極快的速度試圖重新拉起進程時，可能會由於報如下錯誤而導致幾次retry均失敗：
<code class="hljs bash"><code class="hljs vhdl"><code class="hljs vbscript">## var/log/php-fpm.error.log
[18-Jul-2015 21:35:28] ERROR: unable to bind listening socket for address '127.0.0.1:9002': Address already in use (98)
[18-Jul-2015 21:35:28] ERROR: FPM initialization failed</code></code></code>
而supervisor目前還不支持delay restart功能，因此，這里只能通過先sleep再啟動的略顯tricky的方法來解決問題，結果表明，療效不錯且無副作用。-_-
2) autorestart
其文檔描述如下：
<code class="hljs bash"><code class="hljs vhdl"><code class="hljs vbscript"><code class="hljs livecodeserver">May be one of false, unexpected, or true. If false, the process will never be autorestarted. If unexpected, the process will be restart when the program exits with an exit code that is not one of the exit codes associated with this process』 configuration (see exitcodes). If true, the process will be unconditionally restarted when it exits, without regard to its exit code.</code></code></code></code>
其默認值是unexpected，表示若被監護進程的exit code異常時，supervisor才會重新拉起進程。這里設置為true，表明任何時候進程退出均會被再次拉起。
這樣配置好後，在本文第1步搭建好的virtualenv環境中，運行如下命令即可完成supervisor對php-fpm master進程的監護：
<code class="hljs bash"><code class="hljs vhdl"><code class="hljs vbscript"><code class="hljs livecodeserver"><code class="hljs avrasm">shell> supervisord -c etc/sup.php-fpm.conf</code></code></code></code></code>
然後，通過ps x | fgrep fpm可以看到，php-fpm主進程已經被拉起了。
然後，kill掉php-fpm主進程，再次ps x | fgrep fpm可以看到，一個新的php-fpm主進程會被supervisor創建出來。
至此，用supervisor守護php-fpm主進程以實現php-fpm的自動重啟的需求已經解決了。
Ⅳ PHP FPM源代碼反芻品味之四：事件處理
FPM master 進程啟動後，會進入函數fpm_event_loop,無限循環.
處理事件.
master 進程所做的的事，總的來說就是兩類：
簡稱timer事件,需按時運行，主要有3個:
簡稱fd事件,需從文件句柄(file descriptor)讀取到指令後，依指令運行．
重復一下，unix 下一切IO, 皆文件，socket ,socketpair,pipe 都返迴文件句柄(fd) 用於通信．
主要的fd有:
對於timer事件，多個事件在事件軸上是依次排列的，只需反復檢查，到時運行．
對於fd事件，需監聽多個fd，需用到我們第二篇講的IO多路復用技術．
如果滿足事件條件，則處理事件內容．
FPM設計上，兩類事件使用同一個結構，並且事件觸發條件和事件處理邏輯放到同一個事件對象里(C語言對象就是結構體)．
舉個例子， 打鈴下課，打鈴是觸發條件，下課是事件內容，兩個同時放到一個事件對象 ，這是一個很好的設計．
fd值: -1
flags值:FPM_EV_PERSIST
which值: FPM_EV_TIMEOUT
fd值: 獲取觸發指令的文件fd
flags值: FPM_EV_EDGE(fd事件底層的邊緣觸發標志,需系統支持)
which值: FPM_EV_READ
兩類事件分別放在兩個事件隊列
static struct fpm_event_queue_s *fpm_event_queue_timer = NULL;
static struct fpm_event_queue_s *fpm_event_queue_fd = NULL;
事件隊列的結構很常見，雙向隊列：
typedef struct fpm_event_queue_s {
struct fpm_event_queue_s *prev;
struct fpm_event_queue_s *next;
struct fpm_event_s *ev;
} fpm_event_queue;
4移除事件 (fpm_event_del -> fpm_event_queue_del)
簡單的出列操作：
static int fpm_event_queue_del(struct fpm_event_queue_s **queue, struct fpm_event_s *ev)
對於fd事件,需在底層事件輪詢機制里移除（如：epoll）
5,運行事件回調函數：
6, 底層事件輪詢模塊結構
不同的操作系統，支持不同的IO事件機制，linux 支持epoll,
windows支持select, freebsd 支持kqueue,這個結構統一操作介面
在函數fpm_event_init_main里 調用mole->init初始化
fpm 里對應的配置
master進程在fpm_event_loop函數里無限循環，處理定時任務和fd事件.
期間會在mole->wait阻塞片刻，對於epoll機制，就是epoll_wait．
Ⅳ php-fpm的工作機制
概括來說，fpm 的實現就是創建一個 master 進程，在 master 進程中創建並監聽 socket，然後 fork 出多個子進程，這些子進程各自 accept 請求，子進程的處理非常簡單，它在啟動後阻塞在 accept 上，有請求到達後開始讀取請求數據，讀取完成後開始處理然後再返回，在這期間是不會接收其它請求的，也就是說 fpm 的子進程同時只能響應一個請求，只有把這個請求處理完成後才會 accept 下一個請求，這一點與 nginx 的事件驅動有很大的區別，nginx 的子進程通過 epoll 管理套接字，如果一個請求數據還未發送完成則會處理下一個請求，即一個進程會同時連接多個請求，它是非阻塞的模型，只處理活躍的套接字。
fpm 的 master 進程與 worker 進程之間不會直接進行通信，master 通過共享內存獲取 worker 進程的信息，比如 worker 進程當前狀態、已處理請求數等，當 master 進程要殺掉一個 worker 進程時則通過發送信號的方式通知 worker 進程。
fpm 可以同時監聽多個埠，每個埠對應一個 worker pool，而每個 pool 下對應多個 worker 進程，類似 nginx 中 server 概念。
在 php-fpm.conf 中通過[pool name]聲明一個 worker pool：
啟動 fpm 後查看進程：
具體實現上 worker pool 通過fpm_worker_pool_s這個結構表示，多個 worker pool 組成一個單鏈表
接下來看下 fpm 的啟動流程，從main()函數開始：
fpm_init()主要有以下幾個關鍵操作：
(1) fpm_conf_init_main():
解析 php-fpm.conf 配置文件，分配 worker pool 內存結構並保存到全局變數中：fpm_worker_all_pools，各 worker pool 配置解析到fpm_worker_pool_s->config中。
(2)fpm_scoreboard_init_main():
分配用於記錄 worker 進程運行信息的共享內存，按照 worker pool 的最大 worker 進程數分配，每個 worker pool 分配一個fpm_scoreboard_s結構，pool 下對應的每個 worker 進程分配一個fpm_scoreboard_proc_s結構。
(3)fpm_signals_init_main():
這里會通過socketpair()創建一個管道，這個管道並不是用於 master 與 worker 進程通信的，它只在 master 進程中使用，具體用途在稍後介紹 event 事件處理時再作說明。另外設置 master 的信號處理 handler，當 master 收到 SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT 這些信號時將調用sig_handler()處理：
(4)fpm_sockets_init_main()
創建每個 worker pool 的 socket 套接字。
(5)fpm_event_init_main():
啟動 master 的事件管理，fpm 實現了一個事件管理器用於管理 IO、定時事件，其中 IO 事件通過 kqueue、epoll、poll、select 等管理，定時事件就是定時器，一定時間後觸發某個事件。
在fpm_init()初始化完成後接下來就是最關鍵的fpm_run()操作了，此環節將 fork 子進程，啟動進程管理器，另外 master 進程將不會再返回，只有各 worker 進程會返回，也就是說fpm_run()之後的操作均是 worker 進程的。
在 fork 後 worker 進程返回了監聽的套接字繼續 main() 後面的處理，而 master 將永遠阻塞在fpm_event_loop()，接下來分別介紹 master、worker 進程的後續操作。
fpm_run()執行後將 fork 出 worker 進程，worker 進程返回main()中繼續向下執行，後面的流程就是 worker 進程不斷 accept 請求，然後執行 PHP 腳本並返回。整體流程如下：
worker 進程一次請求的處理被劃分為 5 個階段：
worker 處理到各個階段時將會把當前階段更新到fpm_scoreboard_proc_s->request_stage，master 進程正是通過這個標識判斷 worker 進程是否空閑的。
接下來我們來看下 master 是如何管理 worker 進程的，首先介紹下三種不同的進程管理方式：
前面介紹到在fpm_run()中 master 進程將進入fpm_event_loop()：
這就是 master 整體的處理，其進程管理主要依賴注冊的幾個事件，接下來我們詳細分析下這幾個事件的功能。
(1)sp[1]管道可讀事件：
在 fpm_init() 階段 master 曾創建了一個全雙工的管道：sp，然後在這里創建了一個 sp[0] 可讀的事件，當 sp[0] 可讀時將交由 fpm_got_signal() 處理，向 sp[1] 寫數據時 sp[0] 才會可讀，那麼什麼時機會向 sp[1] 寫數據呢？前面已經提到了：當 master 收到注冊的那幾種信號時會寫入 sp[1] 端，這個時候將觸發 sp[0] 可讀事件。
這個事件是 master 用於處理信號的，我們根據 master 注冊的信號逐個看下不同用途：
具體處理邏輯在 fpm_got_signal() 函數中，這里不再羅列。
(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():
這是進程管理實現的主要事件，master 啟動了一個定時器，每隔 1s 觸發一次，主要用於 dynamic、ondemand 模式下的 worker 管理，master 會定時檢查各 worker pool 的 worker 進程數，通過此定時器實現 worker 數量的控制，處理邏輯如下：
(3)fpm_pctl_heartbeat():
這個事件是用於限制 worker 處理單個請求最大耗時的，php-fpm.conf 中有一個request_terminate_timeout的配置項，如果 worker 處理一個請求的總時長超過了這個值那麼 master 將會向此 worker 進程發送kill -TERM信號殺掉 worker 進程，此配置單位為秒，默認值為 0 表示關閉此機制，另外 fpm 列印的 slow log 也是在這里完成的。
除了上面這幾個事件外還有一個沒有提到，那就是 ondemand 模式下 master 監聽的新請求到達的事件，因為 ondemand 模式下 fpm 啟動時是不會預創建 worker 的，有請求時才會生成子進程，所以請求到達時需要通知 master 進程，這個事件是在fpm_children_create_initial()時注冊的，事件處理函數為fpm_pctl_on_socket_accept()，具體邏輯這里不再展開，比較容易理解。
原文出處： https://www.fanhao.com/2017/10/internal-php-fpm.html
Ⅵ 了解PHP-FPM
在伺服器上，當我們查看php進程時，全都是php-fpm進程，大家都知道這個就是php的運行環境，那麼，它到底是個什麼東西呢？
PHP-FPM，就是PHP的FastCGI管理器，用於替換PHP FastCGI的大部分附加功能，在PHP5.3.3後已經成為了PHP的標配。
有小夥伴要問了，FastCGI又是什麼鬼？CGI程序又叫做「通用網關介面」，就是讓Web伺服器和你的應用程序進行交互的一個介面。就像nginx中需要配置的fastcgi_pass，一般我們會使用127.0.0.1:9000或者unix:/tmp/php-cgi.sock來配置這個參數。它的意思就是告訴nginx，過來的請求使用tcp:9000埠的監聽程序來處理或者使用unix/socket來處理。它們都是指向的PHP運行程序。
再說得通俗一點，我們運行php腳本用的是
php-fpm就相當於是這個php命令。nginx通過fastcgi_pass來運行php $nginx_root(nginx配置文件中網站根目錄root配置)下的index.php。所以，如果你用的是python或者其他什麼語言，都可以用它們的cgi程序來讓nginx調用。
FastCGI和CGI又有什麼不同呢？FastCGI是啟動一個socket介面，伺服器應用不需要自己去運行php，只需要向這個socket介面提交請求就可以了。
php-fpm在編譯php時需要添加--enable-fpm。一些通用的集成安裝包如lnmp、phpStudy等都會默認編譯並使用php-fpm，畢竟是標配。
上文中說過nginx可以使用127.0.0.1:9000和unix:/tmp/php-cgi.sock這兩種方式來調用php-fpm。它們有什麼區別呢？
前者，一般帶9000埠號的，是tcp形式的調用。也就是php-fpm啟動了一個監聽進程對9000埠進行監聽。它會調起一個tcp/ip服務，nginx在調用的時候會走一次tcp請求流程，也就是3次握手4次揮手，會走到網路七層中的第四層傳輸層。相對來說這種方式性能會稍差一點，啟動php-fpm後使用nestat查看埠中會出現9000埠的佔用。
後者，使用的是unix套接字socket服務，通過sock文件來交換信息，性能相對好一些，因為它沒有tcp連接過程，也不會有9000埠的佔用。
對於高負載大訪問量的網站還是推薦使用unix方式，對於普通小網站來說，無所謂使用哪個都可以，tcp方式反而更容易配置和理解，也是php-fpm.conf中默認的監聽方式。
php-fpm.conf配置中的listen屬性用來配置監聽，這里的配置要和nginx中的一致，使用tcp的就監聽127.0.0.1:9000，使用unix的就設置成/tmp/php-cgi-56.sock。
以下內容摘自官方文檔：
===========
各自媒體平台均可搜索【硬核項目經理】