php-FPM進程池探秘的詳解

下面小編就為大家帶來一篇基於PHP-FPM進程池探秘。小編覺得蠻不錯的，現在就分享給大家，也給大家做個參考。一起跟著小編過來看看吧

PHP 支援多進程而不支援多執行緒；PHP-FPM 在進程池中執行多個子程序並發處理所有連線請求。透過ps 查看PHP-FPM進程池(pm.start_servers = 2)狀態如下：

root@d856fd02d2fe:~# ps aux -L
USER  PID LWP %CPU NLWP %MEM VSZ RSS TTY  STAT START TIME COMMAND
root   1  1 0.0 1 0.0 4504 692 ?  Ss 13:10 0:00 /bin/sh /usr/local/php/bin/php-fpm start
root   7  7 0.0 1 0.4 176076 19304 ?  Ss 13:10 0:00 php-fpm: master process (/usr/local/php/etc/php-fpm.conf)
www-data  8  8 0.0 1 0.2 176076 8132 ?  S 13:10 0:00 php-fpm: pool www
www-data  9  9 0.0 1 0.2 176076 8132 ?  S 13:10 0:00 php-fpm: pool www
root  10 10 0.0 1 0.0 18376 3476 ?  Ss 14:11 0:00 bash
root  66 66 0.0 1 0.0 34420 2920 ?  R+ 15:13 0:00 ps aux -L

從列表中可以看出，進程池www中有兩個尚處於空閒狀態的子程序PID 8和PID 9。註：NLWP指輕量級進程數量，即執行緒數量。

PHP-FPM(FastCGI Process Manager)是什麼？ PHP-FPM為PHP-CGI提供進程管理方式，可以有效控制記憶體和進程，可以平滑重載PHP配置，其master process是常駐記憶體的。 FastCGI是語言無關的、可伸縮架構的CGI開放擴展，其主要行為是將CGI解釋器進程保持在記憶體中更長時間，而不是fork-and-execute，並因此獲得較高的效能。 FastCGI支援分散式部署，可部署在WEB伺服器以外的多個主機上。

探針手段：模擬多執行緒並發執行

1. 什麼是執行緒：執行緒有時又稱為輕量級進程(Lightweight Process， LWP)，通常由執行緒ID、目前指令指標(PC）、暫存器集合和堆疊組成，是進程中的一個實體，是被系統獨立調度的基本單位；執行緒本身不擁有系統資源，只擁有一點兒在運行中必不可少的資源，與同屬一個進程的其它執行緒共享進程所擁有的全部資源。 由於執行緒之間的相互制約，致使執行緒在運行中呈現出間斷性。線程也有就緒、阻斷和運行三種基本狀態。由於進程是資源擁有者，創建、撤銷與切換開銷過大，在對稱多處理機（SMP）上同時執行多個執行緒（Threads）才是更合適的選擇。執行緒的實體包括程式、資料和執行緒控制區塊（Thread Control Block，TCB），TCB包含以下資訊：

（1）執行緒狀態；

（2）當執行緒不運行時，被保存的現場資源；

（3）一組執行堆疊；

（4）存放每個執行緒的局部變數主存；

（5）存取同一個行程中的主記憶體和其它資源。

但使用多個進程會讓應用程式在出現進程池內的進程崩潰或被攻擊的情況下變得更加健壯。

2. 模擬多執行緒：

#

<?php
/**
 * PHP 只支持多进程不支持多线程。
 *
 * PHP-FPM 在进程池中运行多个子进程并发处理所有连接，
 * 同一个子进程可先后处理多个连接请求，但同一时间
 * 只能处理一个连接请求，未处理连接请求将进入队列等待处理
 *
 */

class SimulatedThread
{
 //模拟线程
 private $thread;

 //主机名
 private $host = &#39;tcp://172.17.0.5&#39;;

 //端口号
 private $port = 80;

 public function __construct()
 {
  //采用当前时间给线程编号
  $this->thread = microtime(true);
 }

 /**
  * 通过socket发送一个新的HTTP连接请求到本机，
  * 此时当前模拟线程既是服务端又是模拟客户端
  *
  * 当前(程序)子进程sleep(1)后会延迟1s才继续执行，但其持有的连接是继续有效的，
  * 不能处理新的连接请求，故这种做法会降低进程池处理并发连接请求的能力，
  * 类似延迟处理还有time_nanosleep()、time_sleep_until()、usleep()。
  * 而且sleep(1)这种做法并不安全，nginx依然可能出现如下错误：
  * “epoll_wait() reported that client prematurely closed connection,
  * so upstream connection is closed too while connecting to upstream”
  *
  * @return void
  */
 public function simulate()
 {
  $run = $_GET[&#39;run&#39;] ?? 0;
  if ($run++ < 9) {//最多模拟10个线程
   $fp = fsockopen($this->host, $this->port);
   fputs($fp, "GET {$_SERVER[&#39;PHP_SELF&#39;]}?run={$run}\r\n\r\n");
   sleep(1);//usleep(500)
   fclose($fp);
  }

  $this->log();
 }

 /**
  * 日志记录当前模拟线程运行时间
  *
  * @return void
  */
 private function log()
 {
  $fp = fopen(&#39;simulated.thread&#39;, &#39;a&#39;);
  fputs($fp, "Log thread {$this->thread} at " . microtime(true) . "(s)\r\n");

  fclose($fp);
 }
}

$thread = new SimulatedThread();
$thread->simulate();
echo "Started to simulate threads...";

探針總結：自己透過執行上述腳本後，發現一些可預料但卻不是我曾想到的結果

1. PHP-FPM配置項pm.max_children = 5，simulated.thread記錄如下：

#

Log thread 1508054181.4236 at 1508054182.4244(s)
Log thread 1508054181.4248 at 1508054182.4254(s)
Log thread 1508054181.426 at 1508054182.428(s)
Log thread 1508054181.6095 at 1508054182.6104(s)
Log thread 1508054182.4254 at 1508054183.4262(s)
Log thread 1508054183.4272 at 1508054183.4272(s)
Log thread 1508054182.4269 at 1508054183.4275(s)
Log thread 1508054182.4289 at 1508054183.43(s)
Log thread 1508054182.6085 at 1508054183.6091(s)
Log thread 1508054182.611 at 1508054183.6118(s)

最新產生的(模擬)執行緒登記出現在紅色標示條目位置是因為進程池的並發連接處理能力上限為5，因此它只可能出現在第六條以後的位置。

Log thread 1508058075.042 at 1508058076.0428(s)
Log thread 1508058075.0432 at 1508058076.0439(s)
Log thread 1508058075.0443 at 1508058076.045(s)
Log thread 1508058075.6623 at 1508058076.6634(s)
Log thread 1508058076.0447 at 1508058077.0455(s)
Log thread 1508058076.046 at 1508058077.0466(s)
Log thread 1508058077.0465 at 1508058077.0466(s)
Log thread 1508058076.0469 at 1508058077.0474(s)
Log thread 1508058076.6647 at 1508058077.6659(s)
Log thread 1508058076.6664 at 1508058077.6671(s)

有意思的是綠色條目代表的(模擬)線程和紅色條目代表的(模擬)線程的登記時間是一樣的，說明兩個(模擬)線程是並發執行的。

2. PHP-FPM配置項目pm.max_children = 10，simulated.thread記錄如下：

Log thread 1508061169.7956 at 1508061170.7963(s)
Log thread 1508061169.7966 at 1508061170.7976(s)
Log thread 1508061169.7978 at 1508061170.7988(s)
Log thread 1508061170.2896 at 1508061171.2901(s)
Log thread 1508061170.7972 at 1508061171.7978(s)
Log thread 1508061171.7984 at 1508061171.7985(s)
Log thread 1508061170.7982 at 1508061171.7986(s)
Log thread 1508061170.7994 at 1508061171.8(s)
Log thread 1508061171.2907 at 1508061172.2912(s)
Log thread 1508061171.2912 at 1508061172.2915(s)

由於服務端並發連線處理能力上限達到10，因此最新產生的(模擬)執行緒登記可出現在任何位置。

3. 執行usleep(500)延遲，simulated.thread記錄如下：

Log thread 1508059270.3195 at 1508059270.3206(s)
Log thread 1508059270.3208 at 1508059270.3219(s)
Log thread 1508059270.322 at 1508059270.323(s)
Log thread 1508059270.323 at 1508059270.324(s)
Log thread 1508059270.3244 at 1508059270.3261(s)
Log thread 1508059270.3256 at 1508059270.3271(s)
Log thread 1508059270.3275 at 1508059270.3286(s)
Log thread 1508059270.3288 at 1508059270.3299(s)
Log thread 1508059270.3299 at 1508059270.331(s)
Log thread 1508059270.3313 at 1508059270.3314(s)

可見日誌記錄順序與(模擬)執行緒產生的順序一致。 usleep延遲的基本單位是微妙(us， 1 s = 1000000 us)。

從以上的記錄可以看出：

#1）這些(模擬)執行緒是第一次請求執行腳本後就自動生成的，一個(模擬)線程緊接著創建了另一個(模擬)線程；

2）這些(模擬)線程中有的是在同一個子進程空間中產生並運行的；

3）前後相鄰(模擬)執行緒產生時間間隔很小，幾乎是同時產生，或後一個(模擬)執行緒在前一個(模擬)執行緒尚未執行結束並退出之前產生；

4）多個(模擬)線程之間可以並發執行。

所以，上述模擬多執行緒並發的實作是成功的。 PHP-FPM進程池中同一個子進程可先後處理多個連線請求，但同一時間只能處理一個連線請求，未處理連線請求將進入佇列等待處理。換句話說，同一個子進程不具有並發處理連線請求的能力。

PHP-FPM Pool配置：它允許定義多個池，每個池可定義不同的配置項目。以下只是列舉了我在探秘過程中還關注過的其他部分配置項目

#

1、 listen：The address on which to accept FastCGI requests.它支援TCP Socket和unix socket兩種通訊協定。可設定listen = [::]:9000。

2、listen.allowed_clients：List of addresses (IPv4/IPv6) of FastCGI clients which are allowed to connect. 此設定項為逗號分隔的列表，如listen.allowed_clients = 127.0.0.1,172.17.0. 。

3、pm：Choose how the process manager will control the number of child processes. 此設定項設定FPM管理流程池的方式，包括static、dynamic、ondemand三種。

4、pm.max_requests：The number of requests each child process should execute before respawning. This can be useful to work around memory leaks in 3rd party libraries.設定每個子程序處理請求數的上限，對於處理請求數的上限，對於處理請求數的上限，對於處理請求數的上限，對於處理請求數第三方庫中的記憶體洩漏很有用。

5、pm.status_path：The URI to view the FPM status page.

以上是php-FPM進程池探秘的詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！