Erkundung des PHP-FPM-Prozesspools

PHP unterstützt Multiprozess, aber kein Multithreading; PHP-FPM führt mehrere Unterprozesse im Prozesspool aus, um alle Verbindungsanfragen gleichzeitig zu verarbeiten. Sehen Sie sich den Status des PHP-FPM-Prozesspools (pm.start_servers = 2) über ps wie folgt an:

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

Wie zu sehen ist Aus der Liste geht hervor, dass der Prozess Es gibt zwei untergeordnete Prozesse, PID 8 und PID 9, die sich noch im Pool www befinden. 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, die Speicher und Prozesse effektiv steuern und die PHP-Konfiguration reibungslos neu laden kann. 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.

Erkundungsmethoden: Simulieren Sie die gleichzeitige Ausführung mehrerer Threads

---

1. Was ist ein Thread?: Threads, manchmal Lightweight Process (LWP), bestehen normalerweise aus Thread-ID, aktuellem Befehlszeiger (PC), Registersatz und Stapel, sind eine Einheit im Prozess und die vom System unabhängig geplante Grundeinheit Ressourcen verfügen nur über wenige Ressourcen, die für den Betrieb unerlässlich sind, und teilen alle dem Prozess gehörenden Ressourcen mit anderen Threads, die zum selben Prozess gehören. 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. Zu den Thread-Entitäten gehören Programme, Daten und Thread-Kontrollblöcke (TCB). TCB enthält die folgenden Informationen:

(1) Thread-Status

(2) Wenn der Thread nicht ausgeführt wird, wird er gespeichert -Site-Ressourcen;

(3) eine Reihe von Ausführungsstapeln

(4) Speicherung lokaler Variablen jedes Threads

(5) Zugriff auf Main Speicher 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 Erkundung : Nachdem ich das obige Skript ausgeführt hatte, fand ich einige vorhersehbare, aber nicht die Ergebnisse, an die ich gedacht hatte

---

1 PHP-FPM-Konfigurationselement pm.max_children = In 5 lautet der Datensatz „simulated.thread“ 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 aufgrund der rot markierten Eintragsposition Gleichzeitige Verbindungsverarbeitung des Prozesspools Die Fähigkeitsobergrenze beträgt 5 und kann daher nur in Artikel 6 und höher 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 (Simulations-)Threads, der durch den grünen Eintrag dargestellt wird, und des (Simulations-)Threads, der durch den roten Eintrag dargestellt wird, sind Dasselbe bedeutet, dass die beiden (Simulations-) Threads gleichzeitig ausgeführt werden.

2. PHP-FPM-Konfigurationselement pm.max_children = 10, simulierter.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)

Aufgrund der gleichzeitigen Verbindung Verarbeitungsfähigkeit des Servers Die Obergrenze liegt bei bis zu 10, sodass die zuletzt erzeugte (simulierte) Thread-Registrierung überall erscheinen kann.

3. Führen Sie die Verzögerung von usleep(500) aus. Der simulierte Thread-Datensatz lautet wie folgt:

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 Protokolldatensatzsequenz lautet wird vom (simulierten) Thread generiert. Die Reihenfolge ist konsistent. Die Grundeinheit der USleep-Verzögerung ist Mikrosekunden (us, 1 s = 1000000 us).

Wie aus den obigen Datensätzen ersichtlich ist:

1) Diese (simulierten) Threads werden automatisch nach der ersten Anforderung zur Ausführung des Skripts generiert, einem (simulierten) Der -Thread erstellt dann einen weiteren (Simulation) -Thread

2) Einige dieser (Simulations-)Threads befinden sich im selben Unterprozess Raum erzeugt und ausgeführt;

3) Das Zeitintervall zwischen der Erzeugung benachbarter (Simulations-)Threads ist sehr klein, fast gleichzeitig, oder letzterer (Simulation) Der Thread wird generiert, bevor die Ausführung des vorherigen (simulierten) Threads abgeschlossen und beendet wurde

4) Mehrere (simulierte) 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, es kann jedoch nur eine Verbindungsanfrage gleichzeitig verarbeitet werden. Unverarbeitete Verbindungsanfragen werden in die Warteschlange gestellt und warten auf die Verarbeitung. Mit anderen Worten: Derselbe untergeordnete Prozess ist nicht in der Lage, Verbindungsanfragen gleichzeitig zu verarbeiten.

PHP-FPM-Pool-Konfiguration : Es können mehrere Pools definiert werden, und jeder Pool kann verschiedene Konfigurationselemente definieren. Das Folgende ist nur eine Liste anderer Konfigurationselemente, auf die ich während meiner Erkundung geachtet habe

---

1. listen: Die Adresse, an der FastCGI-Anfragen angenommen werden sollen. Es werden zwei Kommunikationsprotokolle unterstützt: TCP-Socket und Unix-Socket. Sie können listen = [::]:9000 festlegen.

2. listen.allowed_clients: Liste der Adressen (IPv4/IPv6) von FastCGI-Clients, die eine Verbindung herstellen dürfen, z. B as listen .allowed_clients = 127.0.0.1,172.17.0.5.

3. pm: 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 OnDemand Drei Typen.

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 Eine Obergrenze für die Anzahl der von einem Unterprozess verarbeiteten Anforderungen, nützlich für den Umgang mit Speicherlecks in Bibliotheken von Drittanbietern.

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

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