(Analyse du noyau PHP7-1) CGI et FastCGI

CGI : Il s'agit d'un protocole d'échange de données entre le serveur Web et l'application Web.
FastCGI : identique à CGI, c'est un protocole de communication, mais il présente certaines optimisations en termes d'efficacité par rapport à CGI.
PHP-CGI : C'est le programme d'interface de PHP (Web Application) au protocole CGI fourni par Web Server.
PHP-FPM : C'est le programme d'interface du protocole FastCGI fourni par PHP (Web Application) au serveur Web. De plus, il assure également une gestion des tâches relativement intelligente

workflow CGI<.>

1. Si le client demande index.html, alors le serveur Web trouvera ce fichier dans le système de fichiers et l'enverra au navigateur. Ce qui est distribué ici, ce sont des données statiques.

2. Lorsque le serveur Web reçoit la requête index.php, il démarrera le programme CGI correspondant, qui est l'analyseur PHP. Ensuite, l'analyseur PHP analysera le fichier php.ini, initialisera l'environnement d'exécution, puis traitera la demande, renverra le résultat traité au format spécifié par CGI, quittera le processus et le serveur Web renverra le résultat au navigateur.

Flux de travail FastCGI

1. Si le client demande index.html, alors le serveur Web trouvera ce fichier dans le système de fichiers et l'enverra au navigateur. est distribué ici, ce sont des données statiques.

2. Lorsque le serveur Web reçoit la requête index.php, le programme FastCGI (FastCGI initialise l'environnement d'exécution à son démarrage et chaque pool de processus CGI partage l'environnement d'exécution) dans le pool de processus CGI Sélectionnez un CGI. process pour traiter la demande, renvoyer le résultat traité dans le format spécifié par CGI et continuer à attendre la demande suivante.

Implémentation de base de PHP-FPM

1 L'implémentation de PHP-FPM consiste à créer un processus maître, à créer un pool de travailleurs dans le processus maître et à le laisser. écoutez le socket, puis forkez plusieurs sous-processus (travail), et chacun de ces sous-processus accepte la demande. Le traitement du sous-processus est très simple. Il se bloque lors de l'acceptation après le démarrage. il commence à lire les données de la requête. Une fois la lecture terminée, il commence le traitement puis Return, aucune autre requête ne sera reçue pendant cette période, ce qui signifie que le sous-processus de PHP-FPM ne peut répondre qu'à une seule requête à la fois. Ce n'est qu'une fois cette demande traitée que la prochaine demande sera acceptée

2. Il n'y a pas de communication directe entre le processus maître PHP-FPM et le processus de travail. Le maître obtient les informations du processus de travail via. mémoire partagée, telle que l'état actuel du processus de travail, le nombre de requêtes traitées, etc. Lorsque le processus maître veut tuer un processus de travail, avertissez le processus de travail en envoyant un signal.

3.PHP-FPM peut surveiller plusieurs ports en même temps. Chaque port correspond à un pool de travailleurs, et chaque pool correspond à plusieurs processus de travail

Flux de travail

1. En attente de la demande : le processus de travail est bloqué dans fcgi_accept_request() en attente de la demande

2. : Une fois la requête fastcgi arrivée, le travailleur reçoit, puis commence à recevoir et à analyser les données de la requête jusqu'à ce que les données de la requête arrivent complètement

3. Initialisation de la requête : exécutez php_request_startup(), cette étape appellera chaque extension : PHP_RINIT_FUNCTION ; ();
4. Compile, Exécution : La compilation et l'exécution du script PHP sont terminées par php_execute_script();
5. Fermez la requête : Une fois la requête terminée, exécutez php_request_shutdown(). appelez chaque extension : PHP_RSHUTDOWN_FUNCTION(), puis entrez l'étape (1) pour attendre la requête suivante.

Gestion des processus maîtres

1.static : Cette méthode est relativement simple au démarrage, le maître décompte le nombre correspondant de processus de travail en fonction du pm.max_children. configuration, c'est-à-dire travailleur Le nombre de processus est fixe

2.dynamique : Gestion dynamique des processus, initialisez d'abord un certain nombre de travailleurs selon pm.start_servers au démarrage de fpm Pendant le fonctionnement, si le maître le trouve. le nombre de travailleurs inactifs est inférieur au numéro de configuration pm.min_spare_servers (indiquant qu'il y a trop de demandes et que le travailleur ne peut pas les gérer), le processus de travail sera bifurqué, mais le nombre total de travailleurs ne peut pas dépasser pm.max_children Si. le maître constate que le nombre de travailleurs inactifs dépasse pm.max_spare_servers (indiquant qu'il y a trop de travailleurs inactifs) ) tuera certains travailleurs pour éviter de consommer trop de ressources. Le maître contrôle le nombre de travailleurs via ces 4 valeurs <.>

3.ondemand : Cette méthode est généralement rarement utilisée et n'alloue pas de processus de travail au démarrage. Attendez qu'il y ait une demande, puis informez le processus maître de créer le processus de travail. Le nombre total de travailleurs ne dépasse pas. pm.max_children. Le processus de travail ne se terminera pas immédiatement une fois le traitement terminé. Il se terminera lorsque le temps d'inactivité dépasse pm.process_idle_timeout

PHP-FPM Event Manager

1.sp[1] Événement lisible par pipeline : cet événement est utilisé par le maître pour traiter les signaux2.fpm_pctl_perform_idle_server_maintenance_heartbeat() : c'est l'événement principal dans la mise en œuvre de la gestion des processus. Le maître démarre une minuterie. , qui se déclenche toutes les 1 s. Il est principalement utilisé pour la gestion des travailleurs en modes dynamique et à la demande. Le maître vérifiera régulièrement le nombre de processus de travail dans chaque pool de travailleurs et le mettra en œuvre via cette minuterie.

3.fpm_pctl_heartbeat() : Cet événement est utilisé pour limiter le temps maximum nécessaire à un travailleur pour traiter une seule requête. Il existe un élément de configuration request_terminate_timeout dans php-fpm.conf. Le travailleur pour traiter une demande dépasse cette valeur, alors le maître enverra le signal kill -TERM au processus de travail pour tuer le processus de travail. L'unité de configuration est la seconde. La valeur par défaut est 0, ce qui signifie désactiver ce mécanisme. >

4.fpm_pctl_on_socket_accept() : Nouvelle fonction de surveillance du maître en mode à la demande L'événement d'arrivée de la requête, car en mode à la demande, fpm ne pré-créera pas de Workers au démarrage, et un processus enfant ne sera généré que lorsque il y a une demande, donc lorsque la demande arrive, le processus maître doit être notifié

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!