PHP-FPM學習

CGI

common gateway interface (公共網關接口)

請求模式:

Web Brower(瀏覽器) ----(通過http協議傳輸)----> Http Server(服務器nginx/apache) -----> CGI Program -----> Db

Server 與 CGI 通過 STDIN/STDOUT(標準的輸入/輸出)進行數據傳遞
nginx(動態加載模塊) apache(指定加載模塊)

CGI工作原理

每當客戶請求CGI的時候，WEB服務器就請求操作系統生成一個新的CGI解釋器進程(如php-cgi.exe)，
CGI 的一個進程則處理完一個請求後退出，下一個請求來時再創建新進程。

當然，這樣在訪問量很少沒有併發的情況也行。可是當訪問量增大，併發存在，這種方式就不 適合了。於是就有了fastcgi。

FastCGI

像是一個常駐(long-live)型的CGI，它可以一直執行着，只要激活後，
不會每次都要花費時間去fork一次（這是CGI最爲人詬病的fork-and-execute 模式）。

工作流程

Web Server啓動時載入FastCGI進程管理器（IIS ISAPI或Apache Module)
FastCGI進程管理器自身初始化，啓動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web Server的連接。
當客戶端請求到達Web Server時，FastCGI進程管理器選擇並連接到一個CGI解釋器。 Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi。
FastCGI 子進程完成處理後將標準輸出和錯誤信息從同一連接返回Web Server。
  當FastCGI子進程關閉連接時， 請求便告處理完成。
  FastCGI子進程接着等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個連接。 
  在CGI模式中，php-cgi在此便退出了。

php-fpm

php-fpm是 FastCGI 的實現，並提供了進程管理的功能，即php-Fastcgi Process Manager。
進程包含 master 進程和 worker 進程兩種進程。

master 進程只有一個，負責監聽端口，接收來自 Web Server 的請求，
worker 進程則一般有多個(具體數量根據實際需要配置)，

每個進程內部都嵌入了一個 PHP 解釋器，是 PHP 代碼真正執行的地方。

基本實現

簡單來說，fpm的實現就是創建一個master進程，在master進程中創建worker pool並監聽socket，然後fork出多個子進程（work），這些worker在啓動後阻塞在fcgi_accept_request()上，各自accept請求，有請求到達後worker開始讀取請求數據，讀取完成後開始處理然後再返回，在這期間是不會接收其它請求的，也就是說fpm的子進程同時只能響應一個請求，只有把這個請求處理完成後纔會accept下一個請求。
fpm的master進程與worker進程之間不會直接進行通信，master通過共享內存獲取worker進程的信息，比如worker進程當前狀態、已處理請求數等，當master進程要殺掉一個worker進程時則通過發送信號的方式通知worker進程。
fpm可以同時監聽多個端口，每個端口對應一個worker pool，而每個pool下對應多個worker進程，類似nginx中server概念, 在php-fpm.conf中可以配置多個，例如：
[web1]
listen:127.0.0.1:9000
[web2]
listen:127.0.0.1:9001

大致原理如圖：

Worker工作流程

等待請求：fcgi_accept_request()阻塞等待請求
接收請求：fastcgi請求到達後被worker接收並解析，一直到完全接收，然後將method、query、uri等信息保存到worker進程的fpm_scoreboard_proc_s結構中
初始化請求：php_request_startup()執行，此步驟會調用每個擴展的PHP_RINIT_FUNCTION方法，初始化一些操作
處理請求（編譯、執行）：php代碼編譯執行階段，由 php_execute_script方法完成
關閉請求：返回響應，執行php_request_shutdown方法關閉請求，然後進入第一步繼續等待請求，此步驟會執行每個擴展的PHP_RSHUTDOWN_FUNCTION進行一些收尾工作

請求步驟

三種模式

static模式：靜態模式

該模式比較簡單，在啓動時按照配置pm.max_children啓動固定數量的的進程，這些進程阻塞進行請求的接收

方法執行流程：
fpm_run()->fpm_children_create_initial()->fpm_children_make()

啓動fpm的時候會調用fpm_run方法，而fpm_run方法內部會調用子進程初始化方法fpm_children_create_initial，
在該方法內部會調用fpm_children_make方法創建worker進程。

ondemand 模式：按需分配模式

1. ondemand模式，運行流程和第一步相同，不同之處是在第二個函數中不會分配work進程，而是註冊了一個事件回調函數fpm_pctl_on_socket_accept(),部分代碼如下：

    if (wp->config->pm == PM_STYLE_ONDEMAND) { 
    	wp->ondemand_event = (struct fpm_event_s*)malloc(sizeof(struct fpm_event_s));   
    	......   
    	memset(wp->ondemand_event, 0, sizeof(struct fpm_event_s));    
    	fpm_event_set(wp->ondemand_event,wp->listening_socket,FPM_EV_READ|FPM_EV_EDGE,fpm_pctl_on_socket_		accept, wp);    
    	......
    }
   

2. ondemand模式work進程的創建，回調函數fpm_pctl_on_socket_accept()的部分代碼如下：

    if (wp->running_children >= wp->config->pm_max_children) {   //判斷進程數是否超過最大限制
    ......    
    return;
   }
   
    for (child = wp->children; child; child = child->next) { 
    //fpm_request_is_idle函數返回return proc->request_stage == 		FPM_REQUEST_ACCEPTING
   	 if (fpm_request_is_idle(child)) { 
   		 return;   // FPM_REQUEST_ACCEPTING代表處於等待請求階段
   	}
    }
    ...... 
    fpm_children_make(wp, 1, 1, 1);//創建work進程
   

3. ondemand模式work進程的關閉
   PFM註冊了一個定時事件，fpm_pctl_perform_idle_server_maintenance_heartbeat檢查當前模式下work進程的運行情況，當空閒進程等待請求時間超過pm_process_idle_timeout後，會對最後一個空閒worker進程發出關閉信號，此操作由主進程進行處理，部分代碼如下：

    if (wp->config->pm == PM_STYLE_ONDEMAND) {
        struct timeval last, now;    
        if (!last_idle_child) continue;//最後一個idle進程
         ......
        // last.tv_sec爲上次接收請求的時間
        if (last.tv_sec < now.tv_sec - wp->config->pm_process_idle_timeout) {
            last_idle_child->idle_kill = 1;
            fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT);
        }
        continue;
    }
   

dynamic模式：動態模式

dynamic模式，啓動時分配固定數量的work進程，然後隨着請求的增加會增加進程數，此模式下幾個重要的配置項如下：

max_children 最大進程數
pm_max_spare_servers 允許最大的空閒進程數
min_spare_servers 允許最小的空閒進程數
start_servers 啓動時的進程數

執行過程和ondemand模式類似，啓動時主進程都會創建一個定時事件來定時檢查work的運行狀況，不同的是dynamic模式初始化的時候會創建一定數量的進程，而ondemand模式不會創建，部分代碼如下：

if (idle > wp->config->pm_max_spare_servers && last_idle_child) {//空閒進程數大於配置的允許空閒最大進程數，則關閉進程
    last_idle_child->idle_kill = 1;
    fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT);
    ......
}
if (idle < wp->config->pm_min_spare_servers) {//空閒進程數小於配置允許的最小進程數，則創建進程
    if (wp->running_children >= wp->config->pm_max_children) {//如果達到最大上限，則不再創建
        ......
        continue;
    }
     ......
//此處計算出需要擴充的進程數，從wp->idle_spawn_rate, wp->config->pm_min_spare_servers – idle, wp->config->pm_max_children - wp->running_children三個中選出最小的一個作爲本次要擴充的進程數進行擴充

if (wp->idle_spawn_rate >= 8) {
        zlog(ZLOG_WARNING, "[pool %s] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning %d children, there are %d idle, and %d total children", wp->config->name, wp->idle_spawn_rate, idle, wp->running_children);
    }
    if (wp->idle_spawn_rate < FPM_MAX_SPAWN_RATE) {
        wp->idle_spawn_rate *= 2;//當前進程分配基數小於配置值時候，會以2的倍數進行增長
    }
    ......
}

總結

static模式最簡單，但是靈活性不夠高
ondemand模式相對static模式比較複雜，會根據請求量的增加動態增加，但是處理完請求後不會立即釋放，而是由定時事件定時的檢測空閒到一定時間的進程纔會釋放
dynamic模式類似於ondemand模式，但進程的回收機制不同於ondemand模式，會根據idle數量進行增加和減少worker數量

三種運行方式各有自己的優勢，用哪種方式更合適，要根據自己的業務場景，選擇合適的運行方式

參考：https://zhuanlan.zhihu.com/p/96911584
參考：https://blog.csdn.net/njrclj/article/details/85062459