Réglage des performances de NGINX

NGINX est bien connu comme un équilibreur de charge , un cache et un serveur Web hautes performances, alimentant plus de 40 % des sites Web les plus fréquentés au monde. Pour la plupart des cas d'utilisation, les paramètres NGINX et Linux par défaut fonctionnent bien, mais obtenir des performances optimales nécessite parfois un peu de réglage. Cet article de blog décrit certains des paramètres NGINX et Linux à prendre en compte lors du réglage d'un système.

Vous pouvez régler presque tous les paramètres, mais cet article se concentre sur les quelques paramètres pour lesquels le réglage profite le plus aux utilisateurs. Nous vous recommandons de modifier certains paramètres uniquement si vous avez une connaissance approfondie de NGINX et de Linux, ou selon les instructions de nos équipes de support ou de services professionnels , et nous ne les abordons pas ici. L'équipe des services professionnels a travaillé avec certains des sites Web les plus fréquentés au monde pour optimiser NGINX afin d'obtenir un niveau de performance maximal et est disponible pour travailler avec vous pour tirer le meilleur parti de votre déploiement NGINX ou NGINX Plus.

Introduction

Une compréhension de base de l’architecture NGINX et des concepts de configuration est supposée. Cet article ne tente pas de dupliquer la documentation NGINX, mais fournit un aperçu des différentes options et des liens vers la documentation pertinente.

Une bonne règle à suivre lors du réglage est de modifier un paramètre à la fois et de le rétablir à la valeur par défaut si la modification n'améliore pas les performances.

Nous commençons par une discussion sur le réglage de Linux, car la valeur de certains paramètres du système d’exploitation détermine la manière dont vous ajustez votre configuration NGINX.

Optimiser votre configuration Linux

Les paramètres des noyaux Linux modernes (2.6+) conviennent à la plupart des usages, mais il peut être bénéfique d'en modifier certains. Vérifiez le journal du noyau pour les messages d’erreur indiquant qu’un paramètre est trop bas et ajustez-le comme conseillé. Nous couvrons ici uniquement les paramètres les plus susceptibles de bénéficier d'un réglage dans des charges de travail normales. Pour plus de détails sur le réglage de ces paramètres, veuillez vous référer à votre documentation Linux.

La file d'attente des arriérés

Les paramètres suivants concernent les connexions et la manière dont elles sont mises en file d'attente. Si vous avez un taux élevé de connexions entrantes et que vous obtenez des niveaux de performances inégaux (par exemple, certaines connexions semblent se bloquer), la modification de ces paramètres peut vous aider.

• net.core. somaxconn – Le nombre maximal de connexions qui peuvent être mises en file d'attente pour acceptation par NGINX. La valeur par défaut est souvent très faible et c'est généralement acceptable car NGINX accepte les connexions très rapidement, mais cela peut valoir la peine de l'augmenter si votre site Web connaît un trafic important. Si des messages d’erreur dans le journal du noyau indiquent que la valeur est trop petite, augmentez-la jusqu’à ce que les erreurs cessent.

  Note: Si vous définissez cette valeur sur une valeur supérieure à 512, remplacez le paramètre backlog par la directive d'écoute NGINX pour qu'elle corresponde.

• net.core. netdev_max_backlog – La vitesse à laquelle les paquets sont mis en mémoire tampon par la carte réseau avant d'être transmis au processeur. L’augmentation de la valeur peut améliorer les performances sur les machines avec une bande passante élevée. Vérifiez le journal du noyau pour les erreurs liées à ce paramètre et consultez la documentation de la carte réseau pour obtenir des conseils sur sa modification.

Descripteurs de fichiers

Les descripteurs de fichiers sont des ressources du système d'exploitation utilisées pour représenter les connexions et ouvrir les fichiers, entre autres choses. NGINX peut utiliser jusqu'à deux descripteurs de fichiers par connexion. Par exemple, si NGINX utilise un proxy, il utilise généralement un descripteur de fichier pour la connexion client et un autre pour la connexion au serveur proxy, bien que ce ratio soit beaucoup plus faible si les keepalives HTTP sont utilisés. Pour un système desservant un grand nombre de connexions, les paramètres suivants peuvent devoir être ajustés :

• sys.fs.file -max – La limite à l'échelle du système pour les descripteurs de fichiers
• nofile – La limite du descripteur de fichier utilisateur, définie dans le fichier /etc/security/limits.conf

Ports éphémères

Lorsque NGINX agit comme un proxy, chaque connexion à un serveur en amont utilise un port temporaire ou éphémère . Vous souhaiterez peut-être modifier ce paramètre :

• net.ipv4. ip_local_port_range – Le début et la fin de la plage de valeurs de port. Si vous constatez que vous manquez de ports, augmentez la portée. Un paramètre courant est les ports 1024 à 65000.

Réglage de votre configuration NGINX

Voici quelques directives NGINX qui peuvent avoir un impact sur les performances. Comme indiqué ci-dessus, nous discutons uniquement des directives que vous pouvez ajuster vous-même en toute sécurité. Nous vous recommandons de ne pas modifier les paramètres d’autres directives sans l’avis de l’équipe NGINX.

Processus de travail

NGINX peut exécuter plusieurs processus de travail, chacun capable de traiter un grand nombre de connexions simultanées. Vous pouvez contrôler le nombre de processus de travail et la manière dont ils gèrent les connexions avec les directives suivantes :

• worker_processes – Le nombre de processus de travail NGINX (la valeur par défaut est 1). Dans la plupart des cas, l’exécution d’un processus de travail par cœur de processeur fonctionne bien, et nous vous recommandons de définir cette directive sur auto pour y parvenir. Il peut arriver que vous souhaitiez augmenter ce nombre, par exemple lorsque les processus de travail doivent effectuer de nombreuses E/S sur disque.
• worker_connections – Le nombre maximal de connexions que chaque processus de travail peut gérer simultanément. La valeur par défaut est 512, mais la plupart des systèmes disposent de suffisamment de ressources pour prendre en charge un nombre plus important. Le paramètre approprié dépend de la taille du serveur et de la nature du trafic, et peut être découvert par des tests.

Connexions Keepalive

Les connexions Keepalive peuvent avoir un impact majeur sur les performances en réduisant la charge CPU et réseau nécessaire pour ouvrir et fermer les connexions. NGINX met fin à toutes les connexions client et crée des connexions séparées et indépendantes aux serveurs en amont. NGINX prend en charge les keepalives pour les clients et les serveurs en amont. Les directives suivantes concernent les keepalives des clients :

• keepalive_requests – Le nombre de requêtes qu'un client peut effectuer sur une seule connexion keepalive. La valeur par défaut est 100, mais une valeur beaucoup plus élevée peut être particulièrement utile pour les tests avec un outil de génération de charge, qui envoie généralement un grand nombre de requêtes à partir d'un seul client.
• keepalive_timeout – Durée pendant laquelle une connexion keepalive inactive reste ouverte.

La directive suivante concerne les keepalives en amont :

• keepalive – Le nombre de connexions keepalive inactives vers un serveur en amont qui restent ouvertes pour chaque processus de travail. Il n'y a pas de valeur par défaut.

Pour activer les connexions keepalive aux serveurs en amont, vous devez également inclure les directives suivantes dans la configuration :

proxy_http_version 1.1; proxy_set_header Connexion "";

Journalisation des accès

La journalisation de chaque requête consomme à la fois du processeur et des cycles d’E/S, et une façon de réduire l’impact est d’activer la mise en mémoire tampon du journal d’accès. Avec la mise en mémoire tampon, au lieu d'effectuer une opération d'écriture distincte pour chaque entrée de journal, NGINX met en mémoire tampon une série d'entrées et les écrit ensemble dans le fichier en une seule opération.

Pour activer la mise en mémoire tampon du journal d'accès, incluez le paramètre buffer= size à la directive access_log ; NGINX écrit le contenu du tampon dans le journal lorsque le tampon atteint la valeur de taille . Pour que NGINX écrive le tampon après un laps de temps spécifié, incluez le paramètre flush= time . Lorsque les deux paramètres sont définis, NGINX écrit des entrées dans le fichier journal lorsque l'entrée de journal suivante ne rentre pas dans la mémoire tampon ou que les entrées dans la mémoire tampon sont plus anciennes que l'heure spécifiée, respectivement. Les entrées de journal sont également écrites lorsqu'un processus de travail rouvre ses fichiers journaux ou s'arrête. Pour désactiver complètement la journalisation des accès, incluez le paramètre off dans la directive access_log .

Envoyer un fichier

L'appel système sendfile() du système d'exploitation copie les données d'un descripteur de fichier vers un autre, obtenant souvent une copie nulle, ce qui peut accélérer les transferts de données TCP. Pour permettre à NGINX de l'utiliser, incluez la directive sendfile dans le contexte http ou dans un contexte de serveur ou d'emplacement . NGINX peut ensuite écrire le contenu mis en cache ou sur disque sur un socket sans aucun changement de contexte vers l'espace utilisateur, ce qui rend l'écriture extrêmement rapide et consomme moins de cycles CPU. Notez cependant que comme les données copiées avec sendfile() contournent l'espace utilisateur, elles ne sont pas soumises à la chaîne de traitement NGINX habituelle et aux filtres qui modifient le contenu, tels que gzip . Lorsqu'un contexte de configuration inclut à la fois la directive sendfile et des directives qui activent un filtre de modification de contenu, NGINX désactive automatiquement sendfile pour ce contexte.

Limites

Vous pouvez définir différentes limites qui aident à empêcher les clients de consommer trop de ressources, ce qui peut nuire aux performances de votre système ainsi qu'à la sécurité et à l'expérience utilisateur. Voici quelques-unes des directives pertinentes :

• limit_conn et limit_conn_zone – Limitez le nombre de connexions client acceptées par NGINX, par exemple à partir d’une seule adresse IP. Les définir peut aider à empêcher les clients individuels d’ouvrir trop de connexions et de consommer plus que leur part de ressources.
• limit_rate – Limite la vitesse à laquelle les réponses sont transmises à un client, par connexion (afin que les clients qui ouvrent plusieurs connexions puissent consommer cette quantité de bande passante pour chaque connexion). La définition d’une limite peut empêcher que le système soit surchargé par certains clients, garantissant ainsi une qualité de service plus uniforme pour tous les clients.
• limit_req et limit_req_zone – Limitez le taux de requêtes traitées par NGINX, ce qui présente les mêmes avantages que la définition de limit_rate . Ils peuvent également améliorer la sécurité, en particulier pour les pages de connexion, en limitant le taux de requêtes à une valeur raisonnable pour les utilisateurs humains mais trop lente pour les programmes essayant de submerger votre application de requêtes (comme les robots dans une attaque DDoS ).
• Paramètre max_conns de la directive serveur dans un bloc de configuration en amont – Définit le nombre maximal de connexions simultanées acceptées par un serveur dans un groupe en amont. Imposer une limite peut aider à éviter que les serveurs en amont ne soient surchargés. Définir la valeur sur 0 (zéro, la valeur par défaut) signifie qu'il n'y a pas de limite.
• file d'attente (NGINX Plus) – Crée une file d'attente dans laquelle les demandes sont placées lorsque tous les serveurs disponibles dans le groupe en amont ont atteint leur limite max_conns . Cette directive définit le nombre maximal de requêtes dans la file d'attente et, éventuellement, le temps maximal d'attente (60 secondes par défaut) avant qu'une erreur ne soit renvoyée. Les requêtes ne sont pas mises en file d'attente si vous omettez cette directive.

La mise en cache et la compression peuvent améliorer les performances

Certaines fonctionnalités supplémentaires de NGINX qui peuvent être utilisées pour augmenter les performances d’une application Web ne relèvent pas vraiment du réglage, mais méritent d’être mentionnées car leur impact peut être considérable. Ils incluent la mise en cache et la compression.

Mise en cache

En activant la mise en cache sur une instance NGINX qui équilibre la charge d'un ensemble de serveurs Web ou d'applications, vous pouvez considérablement améliorer le temps de réponse des clients tout en réduisant considérablement la charge sur les serveurs principaux. La mise en cache est un sujet à part entière et nous n'essaierons pas de le couvrir ici. Consultez le guide d’administration de NGINX Plus .

Compression

La compression des réponses envoyées aux clients peut réduire considérablement leur taille, de sorte qu'ils utilisent moins de bande passante réseau. Cependant, étant donné que la compression des données consomme des ressources CPU, elle est particulièrement utile lorsqu'il est vraiment utile de réduire l'utilisation de la bande passante. Il est important de noter que vous ne devez pas activer la compression pour les objets déjà compressés, tels que les fichiers JPEG. Pour plus d'informations, consultez le Guide d'administration NGINX Plus .

Pour plus d'informations, voir :

• Analyse comparative de NGINX : Meilleure précision et résultats significatifs (webinaire à la demande)
• Documentation de référence NGINX sur nginx.org
• Comparer les modèles NGINX
• Spécifications techniques de NGINX Plus

Pour essayer NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour une démo.