Pourquoi Nginx est plus rapide qu'Apache

Pourquoi nginx est-il plus rapide qu'Apache ?

Parlons de quelques concepts en général :

1 : nginx est plus rapide qu'Apache en cas de concurrence élevée, et une faible concurrence n'est pas évidente

2 : La raison pour laquelle il est rapide est due au modèle epoll de nginx

Apache est multi-thread ou multi-processus Lorsqu'il travaille, lorsqu'une réponse http arrive, un processus le reçoit (écouter) –>Traitement d'identification—>Requête de retour, pendant ce processus, un processus traite tout, apche lit ou écrit pour les E/S du socket, mais la lecture ou l'écriture est bloquée, le blocage signifie que le processus doit être suspendu et entrer en état de veille.Une fois qu'il y aura de nombreuses connexions, Apache générera inévitablement plus de processus pour répondre à la demande. Une fois qu'il y aura de nombreux processus, le processeur changera fréquemment de processus, ce qui consomme des ressources et du temps, ce qui conduit à Apache. les performances ont diminué. Pour parler franchement, il ne peut pas gérer autant de processus.

Nginx adopte le modèle epoll, qui est asynchrone et non bloquant. Pour Nginx, le traitement complet d'une demande de connexion est divisé en événements, un événement à la fois. Par exemple, accept(), contain(), disk I/O, send(), etc. Chaque partie a un module correspondant à traiter. Une requête complète peut être traitée par des centaines de modules. Le véritable noyau est le module de collecte et de distribution d'événements, qui est au cœur de la gestion de tous les modules.

Seule la planification des modules de base peut permettre aux modules correspondants d'occuper les ressources CPU pour traiter les requêtes. Prenons l'exemple d'une requête HTTP. Enregistrez d'abord l'événement d'écoute qui vous intéresse dans le module de collecte et de distribution d'événements. Après l'enregistrement, revenez directement sans blocage. Vous n'aurez plus à vous en soucier. une connexion arrive (au tour d'epoll). La requête indiquera le processus), et le CPU peut gérer d'autres choses.

Une fois qu'une demande arrive, le contexte correspondant est attribué à l'ensemble de la demande (en fait, il a été attribué à l'avance, de nouveaux événements d'intérêt (fonction de lecture) sont enregistrés de la même manière. les données du client arrivent, le noyau le fera. Le processus est automatiquement informé que les données peuvent être lues. Après avoir lu les données, elles sont analysées et vont sur le disque pour trouver les ressources (E/S). est terminé, le processus est notifié et le processus commence à renvoyer les données au client send(). Après l'appel, attendez simplement que le noyau renvoie le résultat de la notification.

L'ensemble de la demande est divisé en plusieurs étapes. Chaque étape est enregistrée avec de nombreux modules puis traitée, toutes asynchrones et non bloquantes. Asynchrone fait ici référence à faire quelque chose sans attendre que le résultat soit renvoyé. Il vous avertira automatiquement lorsque cela sera terminé.

J'ai trouvé un exemple sur Internet :

Un exemple simple peut être donné pour illustrer le flux de travail d'Apache. Nous allons habituellement au restaurant pour manger. Le mode de fonctionnement du restaurant est qu'un serveur sert le client à tout moment. Le processus est le suivant : Le serveur attend le client à la porte (écouter). Lorsque le client arrive, il salue la table aménagée (accepter). attend que le client commande (demande uri), et se rend en cuisine pour appeler le chef. Passer une commande de cuisine (E/S disque), attendre que la cuisine soit prête (lire), puis servir les plats à. les invités (envoyer). Le serveur (processus) est bloqué à de nombreux endroits.

De cette façon, lorsqu'il y a plus de clients (plus de requêtes HTTP), le restaurant ne peut appeler plus de serveurs pour servir (processus fork), mais parce que les ressources du restaurant sont limitées (CPU), une fois qu'il y en a aussi beaucoup de serveurs, coûts de gestion très élevés (changement de contexte CPU), entrant ainsi dans un goulot d'étranglement.

Voyons comment Nginx gère cela ? Accrochez une sonnette à la porte du restaurant (enregistrez l'écoute du modèle epoll). Une fois qu'un invité (requête HTTP) arrive, un serveur est envoyé pour le recevoir (accepter). Après cela, le serveur va faire autre chose ( comme recevoir à nouveau des invités) et attend cet invité. Après que l'invité ait commandé le repas, il appelle le serveur (les données arrivent en read()). Le serveur vient et apporte le menu à la cuisine (E/S disque). Le serveur va faire autre chose. Lorsque la cuisine est prête, il appelle le serveur (fin disque I/O), le serveur servira les plats aux invités (send()), la cuisine servira un plat. aux invités une fois qu'il est prêt, et les serveurs peuvent faire autre chose au milieu.

L'ensemble du processus est divisé en plusieurs étapes, et chaque étape possède des modules de service correspondants. Pensons-y, pour qu'une fois qu'il y aura plus de convives, le restaurant puisse également accueillir plus de personnes.

Pour plus d'articles techniques sur Nginx, veuillez visiter la colonne Tutoriel d'utilisation de Nginx !

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!