Erkundung des Prozesspools basierend auf PHP-FPM

PHP unterstützt Multiprozesse, aber kein Multithreading; PHP-FPM führt mehrere untergeordnete Prozesse im Prozesspool aus, um alle Verbindungsanfragen gleichzeitig zu bearbeiten. Überprüfen Sie den Status des PHP-FPM-Prozesspools (pm.start_servers = 2) über ps wie folgt:

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

Verwandte Lernempfehlungen: php-Programmierung (Video)

Wie aus der dortigen Liste ersichtlich ist Es gibt zwei im Prozesspool www. Es gibt zwei untergeordnete Prozesse, PID 8 und PID 9, die noch inaktiv sind. Hinweis: NLWP bezieht sich auf die Anzahl der Lightweight-Prozesse, also die Anzahl der Threads.

Was ist PHP-FPM (FastCGI Process Manager)? PHP-FPM bietet eine Prozessverwaltungsmethode für PHP-CGI, mit der Speicher und Prozesse effektiv gesteuert und die PHP-Konfiguration reibungslos neu geladen werden können. Der Masterprozess befindet sich im Speicher. FastCGI ist eine sprachunabhängige, skalierbare offene CGI-Architekturerweiterung. Ihr Hauptverhalten besteht darin, den CGI-Interpreterprozess länger im Speicher zu halten, anstatt ihn zu forken und auszuführen, und so eine höhere Leistung zu erzielen. FastCGI unterstützt die verteilte Bereitstellung und kann auf mehreren Hosts außer dem WEB-Server bereitgestellt werden.

Erkundungsmethode: Simulieren Sie die gleichzeitige Ausführung mehrerer Threads

1. Was ist ein Thread:Threads werden manchmal als Lightweight-Prozesse (LWP) bezeichnet und bestehen normalerweise aus Thread-ID, aktuellem Befehlszeiger (PC) und Register besteht aus einer Sammlung und einem Stapel. Er ist eine Einheit im Prozess und stellt die vom System unabhängig geplante Grundeinheit dar. Der Thread selbst besitzt keine Systemressourcen, sondern nur einige für den Betrieb wesentliche Ressourcen Prozess mit anderen Threads, die zum selben Prozess gehören. Alle Ressourcen, die Sie haben. Aufgrund der gegenseitigen Einschränkungen zwischen Threads weisen Threads Diskontinuität in ihrem Betrieb auf. Threads haben außerdem drei Grundzustände: bereit, blockiert und ausgeführt. Da der Prozess der Ressourceneigentümer ist, ist der Aufwand für das Erstellen, Abbrechen und Umschalten zu hoch. Daher ist die gleichzeitige Ausführung mehrerer Threads (Threads) auf einem symmetrischen Multiprozessor (SMP) eine geeignetere Wahl. Thread-Entitäten umfassen Programme, Daten und Thread-Kontrollblöcke (TCB) umfassen die folgenden Informationen:

(1) Thread-Status

(2) Vor-Ort-Ressourcen, die gespeichert werden, wenn der Thread nicht ausgeführt wird;
(3) Eine Reihe von Ausführungsstapeln;

(4) Hauptspeicher, der lokale Variablen jedes Threads speichert;

(5) Zugriff auf den Hauptspeicher und andere Ressourcen im selben Prozess.

Aber die Verwendung mehrerer Prozesse macht die Anwendung robuster für den Fall, dass ein Prozess im Prozesspool abstürzt oder angegriffen wird.

2. Multithreading simulieren:

<?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...";

Zusammenfassung der Untersuchung: Nachdem ich das obige Skript ausgeführt hatte, fand ich einige Ergebnisse, die vorhersehbar waren, aber nicht das, was ich mir vorgestellt hatte

1. PHP-FPM-Konfiguration item pm. max_children = 5, simulierter.Thread-Datensatz lautet wie folgt:

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)

Die zuletzt generierte (simulierte) Thread-Registrierung erscheint an der rot markierten Eintragsposition, da die maximale gleichzeitige Verbindungsverarbeitungskapazität des Prozesspools 5 beträgt Es kann nur in der sechsten Position nach dem Balken erscheinen.

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)

Interessant ist, dass die Registrierungszeit des (simulierten) Threads, der durch den grünen Eintrag dargestellt wird, und des (simulierten) Threads, der durch den roten Eintrag dargestellt wird, gleich ist, was darauf hinweist, dass die beiden (simulierten) Threads gleichzeitig ausgeführt werden.

2. PHP-FPM-Konfigurationselement pm.max_children = 10, der simulierte.thread-Datensatz lautet wie folgt:

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)

Da die Obergrenze der gleichzeitigen Verbindungsverarbeitungskapazität des Servers 10 erreicht, wird der zuletzt generierte (simulierte) ) Thread-Registrierung kann an jedem Ort erscheinen.

3. Führen Sie usleep(500)-Verzögerung und simulierte Thread-Datensätze wie folgt aus:

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)

Es ist ersichtlich, dass die Reihenfolge der Protokolldatensätze mit der Reihenfolge der (simulierten) Thread-Generierung übereinstimmt. Die Grundeinheit der USleep-Verzögerung ist Mikrosekunden (us, 1 s = 1000000 us).

Wie aus den obigen Datensätzen ersichtlich ist: 1) Diese (Simulations-)Threads werden automatisch nach der ersten Anforderung zur Ausführung des Skripts generiert

2) Einige dieser (simulierten) Threads werden im selben Unterprozessraum generiert und ausgeführt.

3) Der Zeitabstand zwischen der Generierung benachbarter (simulierter) Threads ist sehr klein, fast gleichzeitig Die nächsten (Simulations-)Threads werden generiert, bevor die Ausführung des vorherigen (Simulations-)Threads abgeschlossen und beendet wurde.

4) Mehrere (Simulations-)Threads können gleichzeitig ausgeführt werden.

Die obige Implementierung der Simulation der Multithread-Parallelität ist also erfolgreich. Derselbe Unterprozess im PHP-FPM-Prozesspool kann mehrere Verbindungsanfragen nacheinander verarbeiten, jedoch nur eine Verbindungsanfrage gleichzeitig. Unverarbeitete Verbindungsanfragen werden in die Warteschlange gestellt und warten auf die Verarbeitung. Mit anderen Worten: Derselbe untergeordnete Prozess ist nicht in der Lage, Verbindungsanforderungen gleichzeitig zu verarbeiten.

PHP-FPM-Pool-Konfiguration: Ermöglicht die Definition mehrerer Pools, und jeder Pool kann unterschiedliche Konfigurationselemente definieren. Das Folgende ist nur eine Liste einiger anderer Konfigurationselemente, auf die ich während des Erkundungsprozesses geachtet habe. Sie können listen = [::]:9000 festlegen.

2. listen.allowed_clients: Liste der Adressen (IPv4/IPv6) von FastCGI-Clients, die eine Verbindung herstellen dürfen. Dieses Konfigurationselement ist eine durch Kommas getrennte Liste, z. B. listen.0.0.1,172.17.0.5.

3. Uhr: Wählen Sie aus, wie der Prozessmanager die Anzahl der untergeordneten Prozesse steuert. Dieses Konfigurationselement legt die Art und Weise fest, wie FPM den Prozesspool verwaltet, einschließlich statischer, dynamischer und On-Demand-Prozesse.

4. pm.max_requests: Die Anzahl der Anfragen, die jeder untergeordnete Prozess ausführen sollte, bevor er erneut erscheint. Dies kann nützlich sein, um Speicherlecks in Bibliotheken von Drittanbietern zu umgehen. Legen Sie die Obergrenze der Anzahl der von jedem untergeordneten Prozess verarbeiteten Anforderungen fest Verarbeitung in Bibliotheken von Drittanbietern. Nützlich bei Speicherlecks.

5. pm.status_path: Der URI zum Anzeigen der FPM-Statusseite.

Verwandte Lernempfehlungen: Programmiervideo

Das obige ist der detaillierte Inhalt vonErkundung des Prozesspools basierend auf PHP-FPM. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!