PHP7-Kernel-Analyse von CGI und FastCGI

CGI: Es handelt sich um ein Protokoll für den Datenaustausch zwischen Webserver und Webanwendung.

FastCGI: Wie CGI handelt es sich um ein Kommunikationsprotokoll, das jedoch einige Effizienzoptimierungen aufweist als CGI.

PHP-CGI: Es handelt sich um das Schnittstellenprogramm von PHP (Webanwendung) zum vom Webserver bereitgestellten CGI-Protokoll.

PHP-FPM: Es handelt sich um ein Schnittstellenprogramm für das FastCGI-Protokoll, das von PHP (Webanwendung) für den Webserver bereitgestellt wird. Es bietet auch eine relativ intelligente Aufgabenverwaltung

CGI-Workflow

1. Wenn der Client index.html anfordert, findet der Webserver diese Datei im Dateisystem und sendet sie an den Browser.

2. Wenn der Webserver die index.php-Anfrage empfängt, startet er das entsprechende CGI-Programm, das den PHP-Parser darstellt. Als nächstes analysiert der PHP-Parser die Datei php.ini, initialisiert die Ausführungsumgebung, verarbeitet dann die Anforderung, gibt das verarbeitete Ergebnis in dem von CGI angegebenen Format zurück, beendet den Prozess und der Webserver gibt das Ergebnis an den Browser zurück.

FastCGI-Workflow

1. Wenn der Client index.html anfordert, findet der Webserver diese Datei im Dateisystem und sendet sie an den Browser Hier werden statische Daten verteilt.

2. Wenn der Webserver die index.php-Anfrage empfängt, wählt das FastCGI-Programm (FastCGI initialisiert die Ausführungsumgebung beim Start und jeder CGI-Prozesspool teilt die Ausführungsumgebung) ein CGI aus Prozess, um die Anfrage zu verarbeiten, das verarbeitete Ergebnis in dem von CGI angegebenen Format zurückzugeben und weiter auf die nächste Anfrage zu warten.

Grundlegende Implementierung von PHP-FPM

1. Die Implementierung von PHP-FPM besteht darin, einen Master-Prozess zu erstellen, einen Worker-Pool im Master-Prozess zu erstellen und ihn zuzulassen Hören Sie auf den Socket und forken Sie dann mehrere Unterprozesse, und jeder dieser Unterprozesse akzeptiert die Anforderung. Die Verarbeitung des Unterprozesses ist sehr einfach. Wenn eine Anforderung eintrifft, wird sie blockiert. Er beginnt mit dem Lesen der Anforderungsdaten, beginnt mit der Verarbeitung und kehrt dann zurück. In diesem Zeitraum werden keine weiteren Anforderungen empfangen, was bedeutet, dass der Unterprozess von PHP-FPM jeweils nur auf eine Anforderung antworten kann Erst nachdem diese Anfrage verarbeitet wurde, wird die nächste Anfrage angenommen.

2 Es gibt keine direkte Kommunikation zwischen dem PHP-FPM-Masterprozess und dem Workerprozess Gemeinsamer Speicher, z. B. der aktuelle Status des Arbeitsprozesses, die Anzahl der verarbeiteten Anforderungen usw. Wenn der Masterprozess einen Arbeitsprozess beenden möchte, benachrichtigen Sie den Arbeitsprozess durch Senden eines Signals.

3.PHP-FPM kann mehrere Ports gleichzeitig überwachen. Jeder Port entspricht einem Worker-Pool und jeder Pool entspricht mehreren Worker-Prozessen

Worker-Workflow

1. Warten auf die Anfrage: Der Worker-Prozess ist in fcgi_accept_request() blockiert und wartet auf die Anfrage.

2 Die Anfrage wird vom Worker empfangen, nachdem sie angekommen ist. Beginnen Sie dann mit dem Empfangen und Parsen der Anfragedaten, bis die Anfragedaten vollständig eintreffen: Führen Sie php_request_startup() aus. In dieser Phase wird jede Erweiterung aufgerufen: PHP_RINIT_FUNCTION( );

4 .Kompilierung und Ausführung von PHP-Skripten werden durch php_execute_script(); abgeschlossen

5. Nachdem die Anfrage abgeschlossen ist, führen Sie php_request_shutdown() aus. Zu diesem Zeitpunkt wird jede Erweiterung wie folgt aufgerufen: PHP_RSHUTDOWN_FUNCTION(). Geben Sie dann Schritt (1) ein und warten Sie auf die nächste Anfrage.

Master-Prozessverwaltung

1.static: Diese Methode ist relativ einfach. Beim Start gibt der Master die entsprechende Anzahl von Worker-Prozessen entsprechend den pm.max_children aus Konfiguration, dh Worker Die Anzahl der Prozesse ist festgelegt

2.dynamisch: Dynamische Prozessverwaltung, initialisieren Sie beim Start von fpm zunächst eine bestimmte Anzahl von Workern, wenn der Master dies feststellt Die Anzahl der inaktiven Worker ist niedriger als die Konfigurationsnummer von pm.min_spare_servers (was darauf hinweist, dass zu viele Anforderungen vorliegen und der Worker diese nicht verarbeiten kann). Der Worker-Prozess wird gegabelt, aber die Gesamtzahl der Worker darf pm.max_children nicht überschreiten Der Master stellt fest, dass die Anzahl der inaktiven Arbeiter pm.max_spare_servers überschreitet (was darauf hinweist, dass es zu viele inaktive Arbeiter gibt). Der Master verwendet diese 4 Werte, um die Anzahl zu steuern Anzahl der Worker

3.ondemand: Diese Methode wird im Allgemeinen selten verwendet und weist beim Start keine Worker-Prozesse zu. Warten Sie, bis eine Anforderung vorliegt, und benachrichtigen Sie dann den Master-Prozess, um den Worker-Prozess zu forken überschreitet nicht pm.max_children. Der Arbeitsprozess wird nicht sofort nach Abschluss der Verarbeitung beendet. Er wird beendet, wenn die Leerlaufzeit pm.process_idle_timeout

PHP-FPM Event Manager

1.sp[1] Pipeline-lesbares Ereignis: Dieses Ereignis wird vom Master zum Verarbeiten von Signalen verwendet

2.fpm_pctl_perform_idle_server_maintenance_heartbeat(): Dies ist das Hauptereignis bei der Implementierung des Prozessmanagements Der Master startet einen Timer, der alle 1 Sekunde ausgelöst wird. Er wird hauptsächlich für die Worker-Verwaltung im dynamischen und On-Demand-Modus verwendet. Der Master überprüft regelmäßig die Anzahl der Worker-Prozesse in jedem Worker-Pool und steuert die Anzahl der Worker

3.fpm_pctl_heartbeat(): Dieses Ereignis wird verwendet, um die maximale Zeit zu begrenzen, die ein Worker benötigt, um eine einzelne Anfrage zu verarbeiten. Es gibt ein request_terminate_timeout-Konfigurationselement in php-fpm.conf Wenn der Worker eine Anforderung verarbeitet, sendet er das Signal kill -TERM, um den Worker-Prozess zu beenden. Der Standardwert ist 0, was bedeutet, dass dieser Mechanismus ausgeschaltet ist >

4.fpm_pctl_on_socket_accept(): Neue Überwachungsfunktion des Masters im On-Demand-Modus Das Ereignis des Anforderungseintreffens, da fpm im On-Demand-Modus beim Start keine Worker vorab erstellt und der untergeordnete Prozess nur dann generiert wird Es liegt eine Anfrage vor, daher muss der Masterprozess benachrichtigt werden, wenn die Anfrage eintrifft

Das obige ist der detaillierte Inhalt vonPHP7-Kernel-Analyse von CGI und FastCGI. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!