關(guān)于PHP-FPM進(jìn)程池的探索介紹

本篇文章和大家了解一下關(guān)于PHP-FPM進(jìn)程池的探索介紹。有一定的參考價(jià)值，有需要的朋友可以參考一下，希望對(duì)大家有所幫助。

PHP 支持多進(jìn)程而不支持多線程；PHP-FPM 在進(jìn)程池中運(yùn)行多個(gè)子進(jìn)程并發(fā)處理所有連接請(qǐng)求。通過 ps 查看PHP-FPM進(jìn)程池(pm.start_servers = 2)狀態(tài)如下：

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

從列表中可以看出，進(jìn)程池www中有兩個(gè)尚處于空閑狀態(tài)的子進(jìn)程PID 8和 PID 9。注：NLWP指輕量級(jí)進(jìn)程數(shù)量，即線程數(shù)量。

PHP-FPM(FastCGI Process Manager)是什么？PHP-FPM為PHP-CGI提供進(jìn)程管理方式，可以有效控制內(nèi)存和進(jìn)程，可以平滑重載PHP配置，其master process是常駐內(nèi)存的。FastCGI是語言無關(guān)的、可伸縮架構(gòu)的CGI開放擴(kuò)展，其主要行為是將CGI解釋器進(jìn)程保持在內(nèi)存中更長(zhǎng)時(shí)間，不是fork-and-execute，并因此獲得較高的性能。FastCGI支持分布式部署，可以部署在WEB服務(wù)器以外的多個(gè)主機(jī)上。

探秘手段：模擬多線程并發(fā)執(zhí)行

1. 什么是線程：線程有時(shí)又稱輕量級(jí)進(jìn)程(Lightweight Process，LWP)，通常由線程ID、當(dāng)前指令指針(PC）、寄存器集合和堆棧組成，是進(jìn)程中的一個(gè)實(shí)體，是被系統(tǒng)獨(dú)立調(diào)度的基本單位；線程自己不擁有系統(tǒng)資源，只擁有一點(diǎn)兒在運(yùn)行中必不可少的資源，與同屬一個(gè)進(jìn)程的其它線程共享進(jìn)程所擁有的全部資源。 由于線程之間的相互制約，致使線程在運(yùn)行中呈現(xiàn)出間斷性。線程也有就緒、阻塞和運(yùn)行三種基本狀態(tài)。由于進(jìn)程是資源擁有者，創(chuàng)建、撤消與切換開銷過大，在對(duì)稱多處理機(jī)（SMP）上同時(shí)運(yùn)行多個(gè)線程（Threads）才是更合適的選擇。線程的實(shí)體包括程序、數(shù)據(jù)和線程控制塊（Thread Control Block，TCB），TCB包括以下信息：

（1）線程狀態(tài)；

（2）當(dāng)線程不運(yùn)行時(shí)，被保存的現(xiàn)場(chǎng)資源；

（3）一組執(zhí)行堆棧；

（4）存放每個(gè)線程的局部變量主存；

（5）訪問同一個(gè)進(jìn)程中的主存和其它資源。

但使用多個(gè)進(jìn)程會(huì)使得應(yīng)用程序在出現(xiàn)進(jìn)程池內(nèi)的進(jìn)程崩潰或被攻擊的情況下變得更加健壯。

2. 模擬多線程：

<?php
/**
 * PHP 只支持多進(jìn)程不支持多線程。
 *
 * PHP-FPM 在進(jìn)程池中運(yùn)行多個(gè)子進(jìn)程并發(fā)處理所有連接，
 * 同一個(gè)子進(jìn)程可先后處理多個(gè)連接請(qǐng)求，但同一時(shí)間
 * 只能處理一個(gè)連接請(qǐng)求，未處理連接請(qǐng)求將進(jìn)入隊(duì)列等待處理
 *
 */

class SimulatedThread
{
 //模擬線程
 private $thread;

 //主機(jī)名
 private $host = 'tcp://172.17.0.5';

 //端口號(hào)
 private $port = 80;

 public function __construct()
 {
  //采用當(dāng)前時(shí)間給線程編號(hào)
  $this->thread = microtime(true);
 }

 /**
  * 通過socket發(fā)送一個(gè)新的HTTP連接請(qǐng)求到本機(jī)，
  * 此時(shí)當(dāng)前模擬線程既是服務(wù)端又是模擬客戶端
  *
  * 當(dāng)前(程序)子進(jìn)程sleep(1)后會(huì)延遲1s才繼續(xù)執(zhí)行，但其持有的連接是繼續(xù)有效的，
  * 不能處理新的連接請(qǐng)求，故這種做法會(huì)降低進(jìn)程池處理并發(fā)連接請(qǐng)求的能力，
  * 類似延遲處理還有time_nanosleep()、time_sleep_until()、usleep()。
  * 而且sleep(1)這種做法并不安全，nginx依然可能出現(xiàn)如下錯(cuò)誤：
  * “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['run'] ?? 0;
  if ($run++ < 9) {//最多模擬10個(gè)線程
   $fp = fsockopen($this->host, $this->port);
   fputs($fp, "GET {$_SERVER['PHP_SELF']}?run={$run}\r\n\r\n");
   sleep(1);//usleep(500)
   fclose($fp);
  }

  $this->log();
 }

 /**
  * 日志記錄當(dāng)前模擬線程運(yùn)行時(shí)間
  *
  * @return void
  */
 private function log()
 {
  $fp = fopen('simulated.thread', 'a');
  fputs($fp, "Log thread {$this->thread} at " . microtime(true) . "(s)\r\n");

  fclose($fp);
 }
}

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

探秘匯總：本人通過運(yùn)行上述腳本后，發(fā)現(xiàn)一些可預(yù)料但卻不是我曾想到的結(jié)果

1. PHP-FPM配置項(xiàng)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)

最新生成的(模擬)線程登記出現(xiàn)在紅色標(biāo)示條目位置是因?yàn)檫M(jìn)程池的并發(fā)連接處理能力上限為5，因此它只可能出現(xiàn)在第六條以后的位置。

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)

有意思的是綠色條目代表的(模擬)線程和紅色條目代表的(模擬)線程的登記時(shí)間是一樣的，說明兩個(gè)(模擬)線程是并發(fā)執(zhí)行的。

2. PHP-FPM配置項(xiàng)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)

由于服務(wù)端并發(fā)連接處理能力上限達(dá)到10，因此最新生成的(模擬)線程登記可出現(xiàn)在任何位置。

3. 執(zhí)行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）這些(模擬)線程是第一次請(qǐng)求執(zhí)行腳本后就自動(dòng)生成的，一個(gè)(模擬)線程緊接著創(chuàng)建了另一個(gè)(模擬)線程；

2）這些(模擬)線程中有的是在同一個(gè)子進(jìn)程空間中產(chǎn)生并運(yùn)行的；

3）前后相鄰(模擬)線程生成時(shí)間間隔很小，幾乎是同時(shí)產(chǎn)生，或后一個(gè)(模擬)線程在前一個(gè)(模擬)線程尚未執(zhí)行結(jié)束并退出之前產(chǎn)生；

4）多個(gè)(模擬)線程之間可以并發(fā)執(zhí)行。

所以，上述模擬多線程并發(fā)的實(shí)現(xiàn)是成功的。PHP-FPM進(jìn)程池中同一個(gè)子進(jìn)程可先后處理多個(gè)連接請(qǐng)求，但同一時(shí)間只能處理一個(gè)連接請(qǐng)求，未處理連接請(qǐng)求將進(jìn)入隊(duì)列等待處理。換句話，同一個(gè)子進(jìn)程不具有并發(fā)處理連接請(qǐng)求的能力。

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

1、 listen：The address on which to accept FastCGI requests.它支持TCP Socket和unix socket兩種通訊協(xié)議?？稍O(shè)置listen = [::]:9000。

2、listen.allowed_clients：List of addresses (IPv4/IPv6) of FastCGI clients which are allowed to connect. 該配置項(xiàng)為逗號(hào)分隔的列表，如listen.allowed_clients = 127.0.0.1,172.17.0.5。

3、pm：Choose how the process manager will control the number of child processes. 該配置項(xiàng)設(shè)置FPM管理進(jìn)程池的方式，包括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.設(shè)置每個(gè)子進(jìn)程處理請(qǐng)求數(shù)的上限，對(duì)于處理第三方庫(kù)中的內(nèi)存泄漏很有用。

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

以上就是關(guān)于PHP-FPM進(jìn)程池的探索的簡(jiǎn)略介紹，當(dāng)然詳細(xì)使用上面的不同還得要大家自己使用過才領(lǐng)會(huì)。如果想了解更多，歡迎關(guān)注億速云行業(yè)資訊頻道哦！