Analyse du noyau PHP7 1 CGI et FastCGI

Le contenu de cet article présente CGI et FastCGI sur l'analyse du noyau PHP7 1. Maintenant, je le partage avec vous. Les amis dans le besoin peuvent s'y référer

CGI : ce sont les données entre le serveur Web et l'application Web. Un accord d'échange.
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 de PHP (Web Application) au protocole FastCGI fourni par Web Server. De plus, il permet é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 soient complètement arrivées

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. Une fois la requête terminée, exécutez php_request_shutdown(). appellera chaque extension : PHP_RSHUTDOWN_FUNCTION(), puis entrera dans l'étape (1) pour attendre la prochaine requête.

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 utilise ces 4 valeurs pour contrôler le nombre. de travailleurs

3.ondemand : Cette méthode est généralement rarement utilisée et n'attribue 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. 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 signaux

2.fpm_pctl_perform_idle_server_maintenance_heartbeat() : c'est l'événement principal dans la mise en œuvre de la gestion des processus par le maître. démarre une minuterie, qui est déclenchée toutes les 1 s. Elle est principalement utilisée 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 ce minuteur.

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 le processus maître doit être notifié lorsque la demande arrive

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!