Optimiser les performances de NGINX

Rick NelsonVice-président régional, ingénierie des solutions

NGINX est réputé pour être un répartiteur de charge à hautes performances, un système de mise en cache et un serveur web qui alimente plus de 40 % des sites web les plus fréquentés au monde. Dans la plupart des cas d’utilisation, les paramètres par défaut de NGINX et de Linux conviennent parfaitement, mais quelques ajustements sont parfois nécessaires pour obtenir des performances optimales. Cet article de blog présente certains paramètres de NGINX et de Linux à prendre en compte lors de l’optimisation d’un système.

Vous pouvez ajuster presque tous les paramètres, mais cet article se concentre sur les quelques paramètres dont l’optimisation profite au plus grand nombre d’utilisateurs. Nous vous recommandons de ne modifier certains paramètres que si vous possédez une connaissance approfondie de NGINX et de Linux, ou sur les conseils de nos équipes Support ou Services professionnels. Nous ne les abordons donc pas ici. L’équipe Services professionnels a collaboré avec certains des sites web les plus fréquentés au monde afin d’optimiser NGINX pour atteindre un niveau de performances maximal. Elle peut également vous accompagner pour tirer le meilleur parti de votre déploiement NGINX ou NGINX Plus.

Introduction

Une connaissance de base de l’architecture de NGINX et des concepts de configuration est requise. Cet article n’a pas vocation à reproduire la documentation de NGINX, mais présente les différentes options et fournit des liens vers la documentation correspondante.

Une bonne règle à suivre lors de l’optimisation consiste à ne modifier qu’un seul paramètre à la fois et à rétablir sa valeur par défaut si ce changement n’améliore pas les performances.

Nous commençons par aborder l’optimisation de Linux, car la valeur de certains paramètres du système d’exploitation détermine la manière dont vous devez optimiser votre configuration NGINX.

Optimisation de votre configuration Linux

Les paramètres des noyaux Linux modernes (2.6 et versions ultérieures) conviennent à la plupart des usages, mais il peut être utile d’en modifier certains. Consultez le journal du noyau pour repérer les messages d’erreur indiquant qu’une valeur est trop faible, puis ajustez-la conformément aux recommandations. Nous abordons ici uniquement les paramètres dont l’optimisation est la plus susceptible d’être bénéfique dans le cadre de charges de travail normales. Pour savoir comment modifier ces paramètres, veuillez consulter votre documentation Linux.

La file d’attente des connexions en attente

Les paramètres suivants concernent les connexions et leur mise en file d’attente. Si vous recevez un grand nombre de connexions entrantes et constatez des performances irrégulières (par exemple, si certaines connexions semblent bloquées), la modification de ces paramètres peut vous aider.

• net.core.somaxconn – Nombre maximal de connexions pouvant être mises en file d’attente avant d’être acceptées par NGINX. La valeur par défaut est souvent très faible, ce qui est généralement acceptable, car NGINX accepte les connexions très rapidement. Il peut toutefois être utile de l’augmenter si votre site web connaît un trafic important. Si des messages d’erreur dans le journal du noyau indiquent que cette valeur est trop faible, augmentez-la jusqu’à ce que les erreurs cessent.Remarque : Si vous définissez cette valeur sur un nombre supérieur à 512, modifiez le paramètre backlog de la directive NGINX listen afin qu’il corresponde à cette valeur.
• net.core.netdev_max_backlog – Vitesse à laquelle les paquets sont mis en mémoire tampon par la carte réseau avant d’être transmis au processeur. L’augmentation de cette valeur peut améliorer les performances des machines disposant d’une bande passante élevée. Consultez le journal du noyau pour rechercher les erreurs liées à ce paramètre et reportez-vous à la documentation de la carte réseau pour savoir comment le modifier.

Descripteurs de fichiers

Les descripteurs de fichiers sont des ressources du système d’exploitation utilisées notamment pour représenter les connexions et les fichiers ouverts. NGINX peut utiliser jusqu’à deux descripteurs de fichiers par connexion. Par exemple, lorsque NGINX fait office de proxy, il utilise généralement un descripteur de fichier pour la connexion client et un autre pour la connexion au serveur mandataire, bien que ce ratio soit nettement inférieur si des connexions HTTP persistantes sont utilisées. Pour un système gérant un grand nombre de connexions, il peut être nécessaire d’ajuster les paramètres suivants :

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

Ports éphémères

Lorsque NGINX fait office de proxy, chaque connexion à un serveur en amont utilise un port temporaire, ou « éphémère ». Vous pouvez modifier ce paramètre :

• net.ipv4.ip_local_port_range – Les valeurs de début et de fin de la plage de ports. Si vous constatez que vous manquez de ports, élargissez cette plage. Une configuration courante consiste à utiliser les ports 1024 à 65000.

Optimisation de votre configuration NGINX

Voici quelques directives NGINX susceptibles d’avoir une incidence sur les performances. Comme indiqué précédemment, nous abordons uniquement les directives que vous pouvez ajuster vous-même sans risque. Nous vous recommandons de ne pas modifier les paramètres des autres directives sans l’avis de l’équipe NGINX.

Processus de travail

NGINX peut exécuter plusieurs processus de travail, chacun étant 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 à l’aide des 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 donne de bons résultats. Nous vous recommandons donc de définir cette directive sur auto pour obtenir cette configuration. Il peut parfois être utile d’augmenter ce nombre, notamment lorsque les processus de travail doivent effectuer de nombreuses opérations d’E/S sur disque.
• worker_connections – Nombre maximal de connexions que chaque processus de travail peut gérer simultanément. La valeur par défaut est de 512, mais la plupart des systèmes disposent de suffisamment de ressources pour prendre en charge un nombre plus élevé. Le réglage approprié dépend de la taille du serveur et de la nature du trafic, et peut être déterminé au moyen de tests.

Connexions persistantes

Connexions persistantes peuvent avoir un impact majeur sur les performances en réduisant la charge du processeur et du réseau nécessaire à l’ouverture et à la fermeture des connexions. NGINX met fin à toutes les connexions clientes et crée des connexions distinctes et indépendantes vers les serveurs en amont. NGINX prend en charge les connexions persistantes aussi bien pour les clients que pour les serveurs en amont. Les directives suivantes concernent les connexions clientes persistantes :

• keepalive_requests – Nombre de requêtes qu’un client peut effectuer sur une même connexion persistante. La valeur par défaut est de 100, mais une valeur beaucoup plus élevée peut être particulièrement utile pour effectuer des tests avec un outil de génération de charge, qui envoie généralement un grand nombre de requêtes depuis un même client.
• keepalive_timeout – Durée pendant laquelle une connexion persistante inactive reste ouverte.

La directive suivante concerne les connexions persistantes en amont :

• keepalive – Le nombre de connexions persistantes inactives à un serveur en amont qui restent ouvertes pour chaque processus de travail. Il n’existe aucune valeur par défaut.

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

proxy_http_version 1.1;proxy_set_header Connection "";

Journalisation des accès

La journalisation de chaque requête consomme des cycles de processeur et d’E/S. Pour en réduire l’impact, il est possible d’activer la mise en mémoire tampon du journal d’accès. Ainsi, 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, puis les écrit toutes ensemble dans le fichier en une seule opération.

Pour activer la mise en mémoire tampon du journal d’accès, ajoutez le paramètre buffer=size à la directive access_log ; NGINX écrit le contenu de la mémoire tampon dans le journal lorsque celle-ci atteint la valeur size. Pour que NGINX écrive le contenu de la mémoire tampon après un délai donné, ajoutez le paramètre flush=time. Lorsque les deux paramètres sont définis, NGINX écrit les entrées dans le fichier journal lorsque l’entrée suivante ne tient pas dans la mémoire tampon ou lorsque les entrées qu’elle contient sont plus anciennes que le délai spécifié, respectivement. Les entrées du 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, ajoutez le paramètre off à la directive access_log.

Sendfile

L’appel système sendfile() du système d’exploitation copie les données d’un descripteur de fichier à un autre, souvent sans aucune copie, ce qui peut accélérer les transferts de données TCP. Pour permettre à NGINX de l’utiliser, ajoutez la directive sendfile dans le contexte http ou dans un contexte server ou location. NGINX peut alors envoyer le contenu mis en cache ou stocké sur disque vers un socket sans aucun basculement de contexte vers l’espace utilisateur, ce qui rend l’écriture extrêmement rapide et réduit le nombre de cycles processeur utilisés. Notez toutefois que, puisque les données copiées avec sendfile() contournent l’espace utilisateur, elles ne sont pas soumises à la chaîne de traitement NGINX habituelle ni aux filtres qui modifient le contenu, tels que gzip. Lorsqu’un contexte de configuration comprend à la fois la directive sendfile et des directives qui activent un filtre modifiant le contenu, NGINX désactive automatiquement sendfile pour ce contexte.

Limites

Vous pouvez définir différentes limites afin d’éviter que les clients ne consomment trop de ressources, ce qui pourrait nuire aux performances de votre système, ainsi qu’à sa sécurité et à l’expérience utilisateur. Voici quelques-unes des directives pertinentes :

• limit_conn et limit_conn_zone – Limitent le nombre de connexions clientes acceptées par NGINX, par exemple depuis une même adresse IP. Leur configuration peut empêcher certains clients d’ouvrir trop de connexions et de consommer plus que leur part de ressources.
• limit_rate – Limite le débit auquel les réponses sont transmises à un client, pour chaque connexion (les clients qui ouvrent plusieurs connexions peuvent donc utiliser cette quantité de bande passante pour chacune d’elles). La définition d’une limite peut empêcher certains clients de surcharger le système et garantir ainsi une qualité de service plus homogène pour tous les clients.
• limit_req et limit_req_zone – Limitent le débit des requêtes traitées par NGINX, ce qui présente les mêmes avantages que la définition de limit_rate. Ces directives peuvent également renforcer la sécurité, notamment pour les pages de connexion, en limitant le débit des requêtes à une valeur raisonnable pour les utilisateurs humains, mais trop faible pour les programmes qui tentent de submerger votre application de requêtes (comme les bots lors d’une attaque DDoS).
• max_conns paramètre de la directive server dans un bloc de configuration upstream – Définit le nombre maximal de connexions simultanées acceptées par un serveur dans un groupe en amont. L’imposition d’une limite peut contribuer à éviter la surcharge des serveurs en amont. Une valeur de 0 (zéro, valeur par défaut) signifie qu’il n’y a aucune limite.
• queue (NGINX Plus) – Crée une file d’attente dans laquelle les requêtes sont placées lorsque tous les serveurs disponibles du 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, leur durée d’attente maximale (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 cette directive est omise.

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

Certaines fonctionnalités supplémentaires de NGINX permettant d’améliorer les performances d’une application web ne relèvent pas vraiment de l’optimisation, mais méritent d’être mentionnées, car leur impact peut être considérable. Il s’agit notamment de la mise en cache et de la compression.

Mise en cache

En activant la mise en cache sur une instance NGINX qui répartit la charge entre plusieurs serveurs web ou serveurs d’applications, vous pouvez considérablement améliorer le temps de réponse pour les clients tout en réduisant fortement la charge sur les serveurs backend. La mise en cache est un sujet à part entière que nous n’aborderons pas ici. Consultez le guide d’administration de NGINX Plus.

Compression

La compression des réponses envoyées aux clients peut considérablement réduire leur taille et, par conséquent, leur utilisation de la bande passante réseau. Toutefois, comme la compression des données consomme des ressources processeur, elle est surtout utile lorsqu’il est réellement pertinent 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 de NGINX Plus.

Pour plus d’informations, consultez :

• Évaluation des performances de NGINX : des résultats plus précis et pertinents (webinaire à la demande)
• Documentation de référence de NGINX sur nginx.org
• Comparer les modèles NGINX
• Spécifications techniques de NGINX Plus

Pour essayer NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour demander une démonstration.

À propos de l’auteur

Rick NelsonVice-président régional, ingénierie des solutions

Autres articles de Rick Nelson