Pourquoi nginx est-il si rapide ?

Nous savons tous que nginx est célèbre pour ses hautes performances, sa stabilité, ses fonctions riches, sa configuration simple et sa faible consommation de ressources, alors pourquoi nginx est-il si rapide ? Analysons-le à partir des principes sous-jacents.

Modèle de processus Nginx

Serveur Nginx, en fonctionnement normal :

Processus multiples : un processus maître, plusieurs processus de travail.

Processus principal : gère le processus Worker.

Interface externe : recevoir des opérations externes (signaux) ;

Transfert interne : gérer les travailleurs via des signaux en fonction des différentes opérations externes

Surveillance : surveiller le processus Worker en cours ; Dans cet état, une fois le processus Worker terminé anormalement, le processus Worker est automatiquement redémarré.

Processus de travail : tous les processus de travail sont égaux.

Traitement réel : requêtes réseau, gérées par le processus Worker.

Nombre de processus Worker : configuré dans nginx.conf, généralement défini sur le nombre de cœurs pour utiliser pleinement les ressources CPU. En même temps, évitez un nombre excessif de processus, évitez les processus en concurrence pour les ressources CPU, et augmenter la perte de changement de contexte.

Réflexion :

La requête est-elle connectée à Nginx et le processus maître est responsable du traitement et du transfert ?

Comment sélectionner le processus Worker qui gère la demande ?

Le résultat du traitement de la demande doit-il encore passer par le processus principal ?

Le processus d'établissement de la connexion HTTP et de traitement des demandes est le suivant :

Lorsque Nginx démarre, le processus Maître charge le fichier de configuration. Processus maître, initialise le Socket d’écoute. Maîtrisez le processus, débranchez plusieurs processus de travail. Les processus de travail sont en compétition pour de nouvelles connexions. Le gagnant établit une connexion Socket via une négociation à trois et traite la demande.

Nginx hautes performances, haute simultanéité

Pourquoi Nginx a-t-il des performances élevées et prend-il en charge une simultanéité élevée ?

Nginx adopte le mode multi-processus + asynchrone non bloquant (multiplexage IO Epoll). Le processus complet de la demande : établir un lien → lire la demande → analyser la demande → traiter la demande → répondre à la demande. Le processus complet de la requête correspond à la couche inférieure : lecture et écriture des événements Socket.

Modèle de traitement d'événements Nginx

Requête : requête HTTP dans Nginx.

Mode de fonctionnement de base du serveur Web HTTP :

Recevoir la requête : lisez la ligne de requête et l'en-tête de la requête ligne par ligne, et lisez le corps de la requête après avoir jugé que le segment a un corps de requête. Traitez la demande. Réponse de retour : en fonction des résultats du traitement, générez la requête HTTP correspondante (ligne de réponse, en-tête de réponse, corps de réponse).

Nginx suit également cette routine, et le processus global est le même :

Architecture modulaire

Nginx Les modules peuvent essentiellement être divisés dans les types suivants en fonction de leurs fonctions :

①event module : il construit un cadre de mécanisme de traitement d'événements indépendant du système d'exploitation et fournit le traitement d'événements spécifiques. Y compris ngx_events_module, ngx_event_core_module et ngx_epoll_module etc.

Le module de traitement d'événements utilisé par Nginx dépend du système d'exploitation spécifique et des options de compilation.

②gestionnaire de phase : Ce type de module est aussi directement appelé module gestionnaire. Principalement responsable du traitement des demandes des clients et de la génération du contenu auquel il faut répondre, tel que le module ngx_http_static_module, qui est responsable du traitement des demandes de pages statiques des clients et de la préparation des fichiers disque correspondants pour la sortie du contenu de réponse.

③Filtre de sortie : également connu sous le nom de module de filtre, il est principalement responsable du traitement du contenu de sortie et peut modifier la sortie.

Par exemple, vous pouvez ajouter une barre de pied prédéfinie à toutes les pages HTML de sortie, ou remplacer l'URL de l'image de sortie.

④upstream : le module amont implémente la fonction de proxy inverse, transmet la vraie requête au serveur back-end, lit la réponse du serveur back-end et la renvoie au client.

Le module en amont est un type particulier de gestionnaire, sauf que le contenu de la réponse n'est pas réellement généré par lui-même, mais est lu à partir du serveur backend.

⑤load-balancer : module d'équilibrage de charge, qui implémente un algorithme spécifique et sélectionne un serveur parmi de nombreux serveurs back-end comme serveur de transfert pour une certaine requête.

Analyse des problèmes courants :

Nginx vs Apache

Nginx :

Multiplexage IO, Epoll (kqueue sur freebsd) hautes performances et haute concurrence Occupe moins ressources système

Apache :

Le blocage + multi-processus/multi-threading est plus stable, moins de bugs et plus de modules

Nombre maximum de connexions Nginx

Contexte de base :

Nginx est un modèle multi-processus et le processus Worker est utilisé pour traiter les demandes. Le nombre de connexions (descripteur de fichier fd) d'un seul processus a une limite supérieure (nofile) : ulimit -n. Configurez le nombre maximum de connexions pour un seul processus Worker sur Nginx : la limite supérieure de worker_connections est nofile. Configurez le nombre de processus Worker sur Nginx : worker_processes.

Par conséquent, le nombre maximum de connexions pour Nginx :

Le nombre maximum de connexions pour Nginx : le nombre de processus Worker x le nombre maximum de connexions pour un seul processus Worker. Ce qui précède correspond au nombre maximum de connexions lorsque Nginx est utilisé comme serveur général. Lorsque Nginx sert de serveur proxy inverse, le nombre maximum de connexions qu'il peut servir : (nombre de processus Worker x nombre maximum de connexions pour un seul processus Worker) / 2. Lorsque le proxy inverse Nginx est utilisé, une connexion au client et une connexion au serveur Web backend seront établies, occupant 2 connexions.

En pensant :

Chaque fois qu'un Socket est ouvert, il occupe un fd ? Pourquoi y a-t-il une limite au nombre de fds qu'un processus peut ouvrir ?

Demande et réponse HTTP

Requête HTTP :

Ligne de requête : méthode, uri, en-tête de la version http corps de la requête

Réponse HTTP :

Ligne de réponse : version http, code d'état en-tête de réponse corps de la réponse

Modèle IO

Lors du traitement de plusieurs requêtes, vous pouvez utiliser : le multiplexage IO ou le blocage IO + multi-threading :

Multiplexage IO : un thread suit l'état de plusieurs sockets, et celui qui est prêt sera lu et écrit. Blocage IO + multi-threading : pour chaque requête, un nouveau thread de service est créé.

Quels sont les scénarios applicables pour le multiplexage IO et le multi-threading ?

Multiplexage IO : il n'y a aucun avantage dans la vitesse de traitement des demandes d'une seule connexion. Grande concurrence : un seul thread est utilisé pour traiter un grand nombre de requêtes simultanées, ce qui réduit la perte de changement de contexte. Il n'est pas nécessaire de prendre en compte les problèmes de concurrence et il peut gérer relativement plus de requêtes. Consomme moins de ressources système (aucune surcharge de planification de thread n’est requise). Convient aux connexions longues (les connexions longues en mode multithread peuvent facilement provoquer trop de threads et entraîner une planification fréquente). Blocage IO + multi-threading : simple à mettre en œuvre et ne repose pas sur des appels système. Chaque fil nécessite du temps et de l'espace. À mesure que le nombre de threads augmente, la surcharge de planification des threads augmente de façon exponentielle.

Select/poll et epoll sont comparés comme suit :

appel système select/poll :

// select 系统调用
int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval *timeout); 
// poll 系统调用
int poll(struct pollfd fds[], nfds_t nfds, int timeout)；

select :

Requête fd_set pour voir s'il y a un fd prêt, vous pouvez définir un délai d'expiration et revenir lorsque fd (descripteur de fichier) est prêt ou expire. fd_set est un peu défini, la taille est une constante lors de la compilation du noyau, la taille par défaut est 1024. Caractéristiques : le nombre de connexions est limité et le nombre de fds que fd_set peut représenter est trop petit ; analyse linéaire : pour déterminer si fd est prêt, vous devez parcourir un côté de la copie des données de fd_set : l'espace utilisateur et l'espace noyau, copier les informations sur l'état de préparation de la connexion.

sondage :

Résolution de la limite de connexion : dans le sondage, fd_set dans select a été remplacé par un tableau pollfd pour résoudre le problème du nombre trop petit de fd. Réplication des données : espace utilisateur et espace noyau, copie des informations sur l'état de préparation de la connexion.

epoll, événement piloté par événement :

Mécanisme d'événement : évitez le balayage linéaire, enregistrez un événement d'écoute pour chaque fd, lorsque fd passe à prêt, ajoutez fd à la liste prête. Nombre de fds : aucune limite (limite au niveau du système d'exploitation, combien de fds peuvent être ouverts par un seul processus).

select, poll, epoll :

Mécanisme de multiplexage E/S. Le multiplexage d'E/S utilise un mécanisme pour surveiller plusieurs descripteurs. Une fois qu'un certain descripteur est prêt (généralement prêt à lire ou à écrire), il peut demander au programme d'effectuer les opérations de lecture et d'écriture correspondantes pour surveiller plusieurs descripteurs de fichiers. Mais select, poll et epoll sont essentiellement des E/S synchrones : le processus utilisateur est responsable de la lecture et de l'écriture (copie de l'espace noyau vers l'espace utilisateur), le processus utilisateur n'est pas bloqué ; exigent que le processus utilisateur soit responsable de la lecture et de l'écriture, les E/S asynchrones seront responsables de la copie de l'espace noyau vers l'espace utilisateur.

Capacités de traitement simultané de Nginx

À propos des capacités de traitement simultané de Nginx : le nombre de connexions simultanées, généralement après optimisation, la valeur maximale peut être maintenue à environ 1~3w. (Le nombre de cœurs de mémoire et de processeur est différent, il y aura de la place pour une optimisation supplémentaire)

Recommandations associées : Tutoriel 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!