Comment nginx atteint une simultanéité élevée

Pour faire simple, il est asynchrone, non bloquant, utilisant epoll et beaucoup d'optimisation du code sous-jacent.

Plus en détail, il s'agit de la conception du modèle de processus spécial et du modèle d'événement de nginx.

Recommandation de cours vidéo → : "Solution de concurrence de données de niveau dix millions (théorie + combat pratique)"

Modèle de processus

nginx adopte un processus principal et plusieurs processus de travail.

Le processus maître est principalement responsable de la collecte et de la distribution des demandes. Lorsqu'une demande arrive, le maître démarre un processus de travail pour traiter la demande.

Le processus maître est également chargé de surveiller l'état du woker pour garantir une fiabilité élevée

Le processus woker est généralement configuré pour correspondre au nombre de cœurs de processeur. Le processus woker de nginx est différent de celui d'Apache. Le processus Apache ne peut traiter qu'une seule requête à la fois, il ouvrira donc plusieurs processus, des centaines, voire des milliers. Le nombre de requêtes que le processus woker de nginx peut gérer en même temps n'est limité que par la mémoire, il peut donc gérer plusieurs requêtes.

Modèle d'événement

nginx est asynchrone et non bloquant.

Chaque fois qu'une demande arrive, il y aura un processus de travail pour la traiter. Mais il ne s’agit pas de l’ensemble du processus. Processus au cours duquel un blocage peut se produire, comme le transfert de la demande vers le serveur en amont (backend) et l'attente du retour de la demande. Ensuite, le transformateur n'attendra pas si bêtement : après avoir envoyé la demande, il enregistrera un événement : « Si l'amont revient, dites-le-moi et je continuerai. Alors il est allé se reposer. A ce moment, si une autre demande arrive, il peut la traiter rapidement de cette manière. Une fois le serveur en amont revenu, cet événement sera déclenché, le travailleur prendra le relais et la requête continuera à baisser.

La nature opérationnelle du serveur Web détermine que la majeure partie de la durée de vie de chaque requête est en transmission réseau. En fait, peu de temps est passé sur la machine serveur. C’est le secret pour résoudre une concurrence élevée avec seulement quelques processus.

Modèle de multiplexage IO epoll

epoll(), le noyau maintient une liste chaînée, epoll_wait vérifie directement si la liste chaînée est vide pour savoir si un descripteur de fichier est prêt . Le noyau implémente epoll sur la base de la fonction de rappel établie avec le pilote de périphérique sur chaque sockfd. Ensuite, lorsqu'un événement sur un sockfd se produit, sa fonction de rappel correspondante sera appelée pour ajouter ce sockfd à la liste chaînée, et les autres états « inactifs » ne le seront pas.

select(), le noyau utilise la méthode d'entraînement par rotation pour vérifier si fd est prêt. Le sockfd est enregistré dans une structure de données de type tableau fd_set, la clé est fd et la valeur est 0 ou 1. .

poll()

[Résumé] : Le plus grand avantage d'epoll par rapport à select est que l'efficacité ne diminuera pas à mesure que le nombre de sockfd augmente.

Pour plus d'articles techniques liés à Nginx, veuillez visiter la colonne Tutoriel d'utilisation de Nginx pour apprendre !

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!