Cet article sera expliqué de manière table par table! Donner d'abord les avantages et les inconvénients de Nginx et Apache, puis analyser les raisons de l'architecture et du mode
Analyse des avantages et des inconvénients
1.
Avantages
de Nginx : 1. Nginx a une bonne concurrence. Nginx utilise epoll comme modèle événementiel sous Linux. La façon de traiter les demandes est asynchrone et non bloquante. La capacité de charge est beaucoup plus élevée qu'Apache et Apache bloque. Dans le cas d'une concurrence élevée, Nginx peut facilement maintenir une faible consommation de ressources et de hautes performances, et Apache a tendance à augmenter le nombre de processus lorsque le traitement PHP est lent ou la pression frontale est élevée, refusant ainsi le service
2. Les performances de nginx pour le traitement des fichiers statiques sont meilleures que celles d'Apache
3. Nginx implique un haut degré de modularité, l'écriture des modules est relativement simple
4. La configuration de nginx est concise, vous pouvez utiliser -t pour tester la configuration une fois la configuration terminée.
5. Nginx peut être utilisé comme équilibreur de charge, prenant en charge une charge à 7 couches
6. nginx lui-même est un serveur proxy inverse et peut être utilisé comme un très bon serveur proxy de messagerie
7.nginx peut réaliser un redémarrage à chaud
Inconvénients:
1. La capacité de Nginx à traiter des fichiers dynamiques, c'est-à-dire à interagir avec le serveur PHP principal est moyenne, et Apache est très efficace dans le traitement des demandes dynamiques
À propos de la dégradation détaillée de nginx, vous pouvez vous référer à un autre article de l'auteur pour obtenir une compréhension initiale de Nginx
II.
Avantages d' Apache :
1. La réécriture d' Apache est plus forte que Nginx. Dans le cas d'une réécriture fréquente, utilisez Apache
2. Parce qu'Apache apparaît plus longtemps que Nginx, il peut avoir moins de bugs et être plus stable
3. Le support PHP d'Apache est relativement simple, car PHP était même un module dans l'architecture Apache, et Nginx doit être utilisé avec d'autres backends (comme FastCGI)
4. La capacité d'Apache à gérer les requêtes dynamiques est relativement forte, nginx ne se porte pas bien à cet égard
Inconvénients:
1. Apache est plus volumineux que nginx, et sa capacité à faire face à une concurrence élevée est plus faible que nginx
3. Résumé
Les avantages et les inconvénients de Nginx et Apache sont présentés sous la forme d'un tableau pour votre comparaison.
| Comparer des objets | nginx | apache |
|---|---|---|
| Capacité à faire face à une concurrence élevée | Fort | Moyenne |
| Capacité à gérer les demandes statiques | Fort | Moyenne |
| Capacité à gérer les demandes dynamiques | Moyenne | Fort |
| La stabilité | Moyenne | Fort |
| Fonctions étendues | Moins | Beaucoup |
| Utilisation des ressources (performances) | Mieux | Moyenne |
| Prise en charge du processeur multicœur | Bon effet | Effet moyen |
La différence entre une page Web statique et une page Web dynamique Veuillez lire cet article La différence entre une page Web statique et une page Web dynamique
Analyse d'architecture
Nous analysons principalement l'architecture de Nginx et Apache sur la simultanéité et les performances élevées! ! !
La différence entre Nginx et Apache est principalement due au fait que le mode de travail de Nginx est asynchrone et non bloquant, tandis que le mode de travail d'Apache bloque de manière synchrone
Implémentation liée à la concurrence
1. Mode de travail (méthode de traitement des requêtes Web, synchrone ou asynchrone)
1.
L'implémentation du mode de travail de Nginx ----- asynchrone nginx consiste à créer d'abord un processus maître par ngxin, puis à créer un processus de travail par le processus maître. Le rôle est de créer et d'arrêter des processus enfants et de transférer les demandes des utilisateurs vers le processus de travail, c'est-à-dire que le processus de travail est réellement traité par la demande de l'utilisateur. Comme son mode de communication est une architecture asynchrone, un processus de travail peut gérer plusieurs demandes de l'utilisateur
2 .Apache ----- Synchrone
Aapache a plusieurs modes de fonctionnement, mais ses méthodes de communication réseau sont la communication synchrone, c'est-à-dire que chaque processus ou thread ne peut gérer que la demande d'un utilisateur , similaire à nginx, Apache est également composé d'un Le contrôle de processus principal génère de nombreux processus de travail (il peut y avoir de nombreux threads de travail sous le processus de travail), la charge du processus principal crée des processus enfants et planifie les demandes des utilisateurs, et c'est le processus de travail (ou fil de travail) qui est réellement responsable du traitement des demandes des utilisateurs.
Voici trois modes de travail d'Apache, qui sont des diagrammes schématiques du mode préfork, du mode de travail et du mode d'événement, qui sont tous des modes de communication synchrones, c'est-à-dire que chaque processus ou thread ne peut traiter qu'une seule demande d'utilisateur en même temps! Cependant, chaque mode a son scénario d'utilisation correspondant, donc je ne le répéterai pas ici.
Après avoir comparé les méthodes de requête Web, nous pouvons généralement comprendre pourquoi Nginx est meilleur qu'Apache. Permettez-moi de résumer mon Afficher
Étant donné que chaque processus de travail de Nginx peut gérer les demandes de plusieurs utilisateurs, le nombre de changements de processus Nginx sera très faible, et donc le changement de contexte sera moindre, de sorte que le système consomme moins de ressources. Et Apache doit changer fréquemment de processus, de sorte que les ressources consommées par la commutation de processus entravent l'amélioration des performances. Deuxièmement, face à une concurrence élevée, Apache doit créer plusieurs processus ou threads. La création de processus et de threads consomme également des ressources système, donc face à une concurrence élevée, nginx peut facilement y faire face, tandis qu'Apache est confronté à une concurrence élevée. Difficile
Implémentation liée aux performances
Deux. Modèle piloté par les événements (appel d'un processus local pour gérer le mode d'E / S, bloquant ou non bloquant) pour
entreprendre la manière susmentionnée de traiter les demandes Web, lorsque le serveur reçoit la demande Web, le processus principal enverra la demande et l'affectera au correspondant processus de travail. À ce stade, le processus de travail commence à traiter les demandes Web. Si l'utilisateur demande du contenu dans un fichier, le processus de travail effectuera des opérations d'E / S.
En ce qui concerne les opérations d'E / S, mentionnons brièvement ici, bloquant et non bloquant. Tout d'abord, le blocage dont nous parlons ici est le blocage des opérations d'E / S
: lorsqu'un processus appelle une opération d'E / S, il doit attendre que l'opération d'E / S termine le résultat renvoyé. S'il ne fait rien pendant la période d'attente Faites, attendez simplement la fin de l'opération d'E / S, puis il est dit que le processus de blocage est
non bloquant: lorsqu'un processus appelle l'opération d'E / S, il n'a pas besoin d'attendre la fin de l'opération d'E / S pour revenir et peut immédiatement traiter d'autres Chose, c'est un processus non bloquant
En conséquence, les E / S de Nginx ne bloquent pas et les E / S d'Apache bloquent
Permettez-moi de parler brièvement de mes vues: le
non-blocage fonctionne toujours avec asynchrone (Nginx) et le blocage fonctionne toujours avec synchrone (Apache).
Étant donné que Nginx communique de manière asynchrone, ses E / S non bloquantes sont significatives (car asynchrones peuvent gérer plusieurs demandes en même temps, lorsqu'une opération d'E / S demandée est effectuée, le processus de travail peut traiter d'autres demandes ).
Étant donné qu'Apache communique de manière synchrone, ses E / S non bloquantes n'ont aucun sens (en raison de la synchronisation, un processus ne peut traiter qu'une seule demande Web et lorsque l'opération d'E / S demandée est effectuée, le processus n'a pas d'autres demandes. Peut gérer)
D'accord, après avoir parlé des concepts de blocage et de non-blocage, passons à notre modèle topique événementiel
Après avoir demandé une opération d'E / S, comment savons-nous que la demande d'E / S a été effectuée et obtenons le résultat de retour des E / S? Il y a deux idées!
Tout d'abord, le processus de travail marque les opérations d'E / S, puis interroge périodiquement ces marques. Si l'opération d'E / S interrogée est terminée, notre processus traitera les E / S, sinon il ne sera pas traité.
Deuxièmement, le processus de travail ne demande plus activement, mais une fois l'opération d'E / S terminée, le noyau informe le processus que l'opération d'E / S est terminée, puis le processus de travail traite l'opération d'E / S.
De toute évidence, l'efficacité de la deuxième méthode sera plus élevée, car la traversée de toutes les opérations d'E / S gaspillera sans aucun doute les ressources du système, en particulier lorsque la quantité de simultanéité est importante et qu'il existe de nombreuses opérations d'E / S. Est très grand, la réponse aux demandes des utilisateurs sera lente, c'est-à-dire que les performances diminueront
Revenons à Nginx et Apache, Apache utilise le premier modèle, le représentant typique est appelé le modèle select et Nginx utilise le deuxième modèle, l'implémentation sur Linnux est le modèle epoll
Ci-dessous, introduisons brièvement quelques modèles select et epoll
bibliothèque de sélection
Les étapes pour utiliser la bibliothèque de sélection sont les suivantes: tout d'
abord, créez un ensemble de descripteurs pour l'événement d'intérêt (fichier spécifique pour les opérations d'E / S). Pour un descripteur, vous pouvez faire attention à l'événement de lecture (lecture), à l'écriture (écriture) et à l'événement d'exception (exception), vous devez donc créer trois types d'ensembles de descripteurs d'événements, qui sont utilisés pour collecter les descripteurs des événements de lecture, écrire Le descripteur de l'événement et le descripteur de l'événement anormal
appellent la fonction select () sous-jacente et attendent que l'événement se produise. Ensuite, interrogez chaque descripteur d'événement de toutes les collections de descripteurs d'événement, vérifiez s'il existe un événement correspondant et traitez-le s'il existe.
Créez un ensemble de descripteurs pour chaque demande d'E / S, qui contient trois types, puis parcourez ces ensembles régulièrement et renvoyez le résultat de l'appel au processus de travail une fois les E / S terminées.
bibliothèque epoll La bibliothèque
epoll est l'une des bibliothèques événementielles hautes performances prises en charge par le serveur Nginx. L'efficacité de la bibliothèque epoll est très élevée
La bibliothèque de sélection et la bibliothèque de polos sont toutes traitées en créant une liste d'événements en attente, puis en envoyant cette liste au noyau. Lors du retour, vérifiez la liste en interrogeant pour déterminer si un événement s'est produit. De cette façon, lorsqu'il existe de nombreux descripteurs, l'efficacité devient très faible .
Une meilleure pratique consiste à laisser la gestion de la liste des descripteurs au noyau. Une fois que quelque chose se produit, le noyau notifie le processus de la liste des descripteurs de l'événement, ce qui évite d'interroger la liste complète des descripteurs. La bibliothèque est un tel modèle
Tout d'abord, la bibliothèque epoll informe le noyau de créer une liste d'événements avec N descripteurs via des appels associés. Ensuite, définissez les événements d'intérêt pour ces descripteurs et ajoutez-les à la liste d'événements du noyau. Dans le processus de codage spécifique, Vous pouvez également modifier et supprimer les descripteurs de la liste d'événements via des appels associés
Une fois le paramétrage terminé, la bibliothèque epoll commence à attendre que le noyau notifie qu'un événement s'est produit. Après qu'un événement se soit produit, le noyau signale la liste des descripteurs de l'événement à la bibliothèque epoll. Obtenez la bibliothèque epoll de la liste des événements et vous pouvez traiter l'événement
La bibliothèque epoll est efficace sur la plate-forme Linux. Elle prend en charge un processus pour ouvrir un grand nombre de descripteurs d'événements. La limite supérieure est le nombre maximal de fichiers que le système peut ouvrir. En même temps, l'efficacité des E / S de la bibliothèque epoll ne diminue pas linéairement avec l'augmentation du nombre de descripteurs. Il ne fonctionnera que sur les descripteurs "actifs" rapportés par le noyau
Grâce à l'analyse du modèle de traitement des événements, nous pouvons découvrir pourquoi les performances de Nginx sont meilleures que celles d'Apache
car le modèle epoll utilisé par Nginx est plus efficace lors du traitement des demandes, en particulier dans les environnements à concurrence élevée. Ses avantages sont plus importants Étant donné que le modèle sélectionné d'Apache doit parcourir les descripteurs de fichiers, lorsque la concurrence est grande, le temps et la consommation de la traversée sont relativement importants, ce qui entraînera une perte de performances et le modèle epoll est différent. Dans le cas d'une concurrence élevée, elle est toujours causée par Le noyau notifie le processus de travail de l'achèvement des E / S et ne passe pas par celui-ci. Il informe uniquement le processus de travail lorsqu'il est terminé, de sorte que les performances de nginx sous une concurrence élevée n'auront pas beaucoup d'impact, et Apache est sous une concurrence élevée. Les performances seront considérablement réduites
