Pourquoi nginx est-il si rapide ?

Tout d'abord, nous devons savoir que Nginx utilise un modèle de multiplexage d'E/S multi-processus (un seul thread) et multicanal. Nginx, qui utilise la technologie de multiplexage d'E/S, devient un serveur « piloté par des événements simultanés ».

(Tutoriel recommandé : Tutoriel Nginx)

Mode de travail multi-processus

Après le démarrage de Nginx, il y aura un processus maître et plusieurs processus de travail indépendants. Le maître reçoit des signaux du monde extérieur et envoie des signaux à chaque processus de travail. Chaque processus peut gérer la connexion. Le processus maître peut surveiller l'état d'exécution du processus de travail. Lorsque le processus de travail se termine (dans des circonstances anormales), un nouveau processus de travail sera automatiquement démarré.

Faites attention au nombre de processus de travail, qui est généralement défini en fonction du nombre de cœurs de processeur de la machine. Parce qu'un plus grand nombre de travailleurs ne fera qu'amener les processus à se faire concurrence pour le processeur, ce qui entraînera un changement de contexte inutile.

L'utilisation du mode multi-processus améliore non seulement le taux de concurrence, mais rend également les processus indépendants les uns des autres. Si un processus de travail raccroche, cela n'affectera pas les autres processus de travail.

Troupeau tonitruant

Le processus principal (processus maître) crée d'abord un descripteur de fichier sock via socket() pour écouter, puis forke pour générer des processus enfants (travailleurs) processus), le processus enfant héritera du sockfd (descripteur de fichier socket) du processus parent, puis le processus enfant créera un descripteur connecté (descripteur connecté) après accept(), puis communiquera avec le client via le descripteur connecté.

Ensuite, puisque tous les processus enfants héritent du sockfd du processus parent, lorsqu'une connexion arrive, tous les processus enfants recevront des notifications et « feront la course » pour établir une connexion avec lui. C'est ce qu'on appelle un « groupe tonnerre ». Phénomène". Un grand nombre de processus sont activés et suspendus, et un seul processus peut accepter() la connexion, ce qui bien sûr consomme des ressources système.

Gestion par Nginx du phénomène du troupeau tonitruant

Nginx fournit un accept_mutex, qui est un verrou partagé ajouté pour accepter. Autrement dit, chaque processus de travail doit acquérir le verrou avant d'exécuter accept. S'il ne peut pas l'acquérir, il abandonnera l'exécution de accept(). Avec ce verrou, un seul processus acceptera() en même temps, il n'y aura donc pas de problème de troupeau. accept_mutex est une option contrôlable que nous pouvons désactiver explicitement. Elle est activée par défaut.

Explication détaillée du processus Nginx

Après le démarrage de Nginx, il y aura un processus principal et plusieurs processus de travail.

processus maître

est principalement utilisé pour gérer les processus de travail, notamment :

Recevoir des signaux du monde extérieur et envoyer des signaux à chaque processus de travail pour surveiller les processus de travail. À l'état d'exécution, lorsque le processus de travail se termine (dans des circonstances anormales), un nouveau processus de travail sera automatiquement redémarré

Le processus maître agit comme une interface interactive entre l'ensemble du groupe de processus et l'utilisateur. , et surveille le processus en même temps. Il n'a pas besoin de gérer les événements réseau et n'est pas responsable de l'exécution des activités. Il gère uniquement les processus de travail pour mettre en œuvre des fonctions telles que le redémarrage des services, les mises à niveau fluides, le remplacement des fichiers journaux et la prise en compte des fichiers de configuration en temps réel.

Pour contrôler nginx, il suffit d'envoyer un signal au processus maître via kill. Par exemple, kill -HUP pid indique à nginx de redémarrer nginx correctement. Nous utilisons généralement ce signal pour redémarrer nginx ou recharger la configuration. Parce qu'il redémarre normalement, le service n'est pas interrompu. Que fait le processus maître après avoir reçu le signal HUP ?

Tout d'abord, après avoir reçu le signal, le processus maître rechargera le fichier de configuration, puis démarrera le nouveau processus de travail et enverra des signaux à tous les anciens processus de travail pour leur dire qu'ils peuvent prendre leur retraite honorablement une fois le nouveau travailleur terminé. commencé, commencez à recevoir de nouvelles demandes.

Après avoir reçu le signal du maître, l'ancien travailleur ne recevra plus de nouvelles demandes, et une fois toutes les demandes non traitées dans le processus en cours traitées, quittez à nouveau.

Bien sûr, l'envoi de signaux directement au processus maître est une méthode de fonctionnement plus ancienne. Après la version 0.8 de nginx, il a introduit une série de paramètres de ligne de commande pour faciliter notre gestion. Par exemple, ./nginx -s reload consiste à redémarrer nginx et ./nginx -s stop consiste à arrêter nginx. Comment? Prenons reload comme exemple. Nous voyons que lors de l'exécution de la commande, nous démarrons un nouveau processus nginx, et après que le nouveau processus nginx ait analysé le paramètre reload, nous savons que notre objectif est de contrôler nginx pour recharger le fichier de configuration. enverra un signal au processus maître, puis l'action suivante sera la même que si nous envoyions le signal directement au processus maître.

processus de travail

Les événements réseau de base sont gérés dans le processus de travail. Plusieurs processus de travail sont peer-to-peer. Ils sont en concurrence égale pour les demandes des clients et chaque processus est indépendant les uns des autres. Une demande ne peut être traitée que dans un seul processus de travail, et un processus de travail ne peut pas traiter les demandes provenant d'autres processus. Le nombre de processus de travail peut être défini. Généralement, nous le définirons pour qu'il soit cohérent avec le nombre de cœurs de processeur de la machine. La raison en est indissociable du modèle de processus et du modèle de traitement des événements de nginx.

Les processus de travail sont égaux et chaque processus a la même opportunité de traiter les demandes. Lorsque nous fournissons un service http sur le port 80 et qu'une demande de connexion arrive, chaque processus peut gérer la connexion. Comment faire cela ? Tout d'abord, chaque processus de travail est dérivé du processus maître. Dans le processus maître, le socket (listenfd) qui doit être écouté est d'abord établi, puis plusieurs processus de travail sont dérivés. Le Listenfd de tous les processus de travail deviendra lisible lorsqu'une nouvelle connexion arrive. Pour garantir qu'un seul processus gère la connexion, tous les processus de travail récupèrent accept_mutex avant d'enregistrer l'événement de lecture Listenfd. Le processus qui récupère le mutex enregistre l'événement de lecture Listenfd. accept dans l'événement read pour accepter la connexion. Lorsqu'un processus de travail accepte la connexion, il commence à lire la demande, à analyser la demande, à traiter la demande, à générer des données, puis à les renvoyer au client, et enfin à déconnecter la connexion. Voici à quoi ressemble une demande complète. Nous pouvons voir qu'une demande est entièrement traitée par le processus de travail et n'est traitée que dans un seul processus de travail.

workflow de processus de travail

Lorsqu'un processus de travail accepte () la connexion, il commence à lire la demande, à analyser la demande, à traiter la demande et à générer des données. Revenez ensuite au client, et enfin déconnectez-vous, une requête complète. Une demande est entièrement gérée par le processus de travail et ne peut être traitée que dans un seul processus de travail.

Avantages de cette procédure :

Économie des frais généraux causés par les verrous. Chaque processus de travail est un processus indépendant, ne partage pas de ressources et ne nécessite pas de verrouillage. En même temps, cela sera beaucoup plus pratique lors de la programmation et du dépannage. Des processus indépendants réduisent les risques. L'utilisation de processus indépendants peut empêcher les uns de s'influencer les uns les autres. Après la fin d'un processus, les autres processus fonctionnent toujours et le service ne sera pas interrompu. Le processus maître redémarrera rapidement les nouveaux processus de travail. Bien entendu, le processus de travail peut également se terminer de manière inattendue.

Dans le modèle multi-processus, chaque processus/thread ne peut gérer qu'un seul canal d'E/S. Alors, comment Nginx gère-t-il plusieurs canaux d'E/S ?

Si le multiplexage IO n'est pas utilisé, alors une seule requête peut être traitée dans un processus en même temps, comme l'exécution de accept(). S'il n'y a pas de connexion, le programme bloquera ici jusqu'à ce qu'il y ait un. connexion. Venez ici avant de pouvoir continuer à exécuter vers le bas.

Le multiplexage nous permet de rendre le contrôle au programme uniquement lorsqu'un événement se produit, tandis qu'à d'autres moments, le noyau suspend le processus et est en veille.

Core : Le modèle de multiplexage IO epoll adopté par Nginx

Exemple : Nginx enregistrera un événement : "Si une demande de connexion d'un nouveau client arrive, prévenez-moi à nouveau ", après cela, seulement lorsque la demande de connexion arrive, le serveur exécutera accept() pour recevoir la demande. Pour un autre exemple, lors du transfert d'une requête vers un serveur en amont (tel que PHP-FPM) et en attendant le retour de la requête, le processeur ne bloquera pas ici. Il enregistrera un événement après l'envoi de la requête : "Si le tampon reçoit. data, dites-le-moi et je le lirai à nouveau", le processus devient donc inactif et attend que l'événement se produise.

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!