10 conseils pour multiplier par 10 les performances de vos applications

Floyd SmithDirecteur du marketing de contenu

Améliorer les performances des applications web est plus crucial que jamais. La part de l’activité économique réalisée en ligne ne cesse de croître ; plus de 5 % de l’économie des pays développés repose désormais sur Internet (voir Ressources sur les statistiques d’Internet ci-dessous). Dans notre monde moderne toujours connecté et hyperconnecté, les attentes des utilisateurs sont également plus élevées que jamais. Si votre site ne répond pas instantanément ou si votre application ne fonctionne pas sans délai, les utilisateurs se tournent rapidement vers vos concurrents.

Par exemple, une étude menée par Amazon il y a près de 10 ans a démontré que, déjà à l’époque, une réduction de 100 millisecondes du temps de chargement des pages se traduisait par une hausse de 1 % de son chiffre d’affaires. Une autre étude récente a révélé que plus de la moitié des propriétaires de sites interrogés déclaraient avoir perdu des revenus ou des clients en raison des mauvaises performances de leurs applications.

À quelle vitesse un site web doit-il se charger ? Pour chaque seconde de chargement d’une page, environ 4 % des utilisateurs l’abandonnent. Les meilleurs sites d’e-commerce affichent un délai avant la première interaction compris entre une et trois secondes, ce qui leur permet d’obtenir le taux de conversion le plus élevé. Il est clair que les enjeux liés aux performances des applications web sont importants et qu’ils devraient continuer à croître.

Il est facile de vouloir améliorer les performances, mais obtenir des résultats concrets est plus difficile. Pour vous accompagner dans cette démarche, cet article de blog vous propose dix conseils qui vous aideront à multiplier jusqu’à 10 les performances de votre site web. Il s’agit du premier article d’une série expliquant comment améliorer les performances de votre application grâce à des techniques d’optimisation éprouvées et à un peu d’aide de NGINX. Cette série présente également les améliorations potentielles en matière de sécurité dont vous pourrez bénéficier au passage.

Conseil n° 1 – Accélérez et sécurisez vos applications avec un serveur proxy inverse

Si votre application web s’exécute sur une seule machine, la solution aux problèmes de performances peut sembler évidente : il suffit d’opter pour une machine plus rapide, dotée d’un processeur plus puissant, de davantage de RAM, d’une baie de disques rapide, etc. Cette nouvelle machine pourra alors exécuter votre serveur WordPress, votre application Node.js, votre application Java, etc., plus rapidement qu’auparavant. (Si votre application accède à un serveur de base de données, la solution peut encore sembler simple : opter pour deux machines plus rapides et une connexion plus rapide entre elles.)

Le problème, c’est que la vitesse de la machine n’est peut-être pas en cause. Les applications web sont souvent lentes parce que l’ordinateur passe constamment d’un type de tâche à un autre : interagir avec des utilisateurs via des milliers de connexions, accéder à des fichiers sur le disque et exécuter le code de l’application, entre autres. Le serveur d’applications peut être en situation de saturation : il manque de mémoire, transfère des blocs de mémoire sur le disque et contraint de nombreuses requêtes à attendre l’exécution d’une seule tâche, telle qu’une opération d’entrée/sortie sur disque.

Au lieu de mettre à niveau votre matériel, vous pouvez adopter une approche totalement différente : ajouter un serveur proxy inverse afin de lui déléguer certaines de ces tâches. Un serveur proxy inverse se place devant la machine qui exécute l’application et gère le trafic Internet. Seul le serveur proxy inverse est directement connecté à Internet ; les communications avec les serveurs d’applications passent par un réseau interne rapide.

L’utilisation d’un serveur proxy inverse évite au serveur d’applications d’avoir à attendre que les utilisateurs interagissent avec l’application web et lui permet de se concentrer sur la génération des pages que le serveur proxy inverse transmettra sur Internet. N’ayant plus à attendre les réponses des clients, le serveur d’applications peut fonctionner à des vitesses proches de celles obtenues lors de tests de performance optimisés.

L’ajout d’un serveur proxy inverse apporte également davantage de flexibilité à la configuration de votre serveur web. Par exemple, si un serveur d’un type donné est surchargé, il est facile d’ajouter un autre serveur du même type ; si un serveur est hors service, il peut facilement être remplacé.

Grâce à la flexibilité qu’il offre, un serveur proxy inverse est également indispensable à de nombreuses autres fonctionnalités permettant d’améliorer les performances, telles que :

• Répartition de charge (voir Conseil 2) – Un répartiteur de charge s’exécute sur un serveur proxy inverse afin de répartir uniformément le trafic entre plusieurs serveurs d’applications. Grâce à ce répartiteur, vous pouvez ajouter des serveurs d’applications sans modifier votre application.
• Mise en cache des fichiers statiques (voir Conseil 3) – Les fichiers demandés directement, tels que les fichiers image ou les fichiers de code, peuvent être stockés sur le serveur proxy inverse et envoyés directement au client. Les ressources sont ainsi fournies plus rapidement et le serveur d’applications est moins sollicité, ce qui permet à l’application de s’exécuter plus rapidement.
• Sécurisation de votre site – Le serveur proxy inverse peut être configuré avec un niveau de sécurité élevé et surveillé afin de détecter rapidement les attaques et d’y répondre, tout en protégeant les serveurs d’applications.

Le logiciel NGINX est spécialement conçu pour être utilisé comme serveur proxy inverse, avec les fonctionnalités supplémentaires décrites ci-dessus. NGINX utilise une approche de traitement pilotée par les événements, plus efficace que celle des serveurs traditionnels. NGINX Plus ajoute des fonctionnalités de proxy inverse plus avancées, telles que les contrôles d’intégrité des applications, le routage spécialisé des requêtes, la mise en cache avancée et le support technique.

Conseil n° 2 – Ajoutez un équilibreur de charge

L’ajout d’un répartiteur de charge est une modification relativement simple qui peut améliorer considérablement les performances et la sécurité de votre site. Au lieu d’augmenter la taille et la puissance d’un serveur web principal, vous utilisez un répartiteur de charge pour distribuer le trafic entre plusieurs serveurs. Même si une application est mal conçue ou présente des problèmes de mise à l’échelle, un répartiteur de charge peut améliorer l’expérience utilisateur sans qu’aucune autre modification soit nécessaire.

Un équilibreur de charge est avant tout un serveur proxy inverse (voir Conseil 1) : il reçoit le trafic Internet et transmet les requêtes à un autre serveur. Sa particularité est de prendre en charge au moins deux serveurs d’applications et d’utiliser un choix d’algorithmes pour répartir les requêtes entre les serveurs. La méthode d’équilibrage de charge la plus simple est la répartition à tour de rôle, chaque nouvelle requête étant envoyée au serveur suivant de la liste. D’autres méthodes consistent notamment à envoyer les requêtes au serveur ayant le moins de connexions actives. NGINX Plus offre des fonctionnalités permettant de maintenir la session d’un utilisateur donné sur le même serveur, ce que l’on appelle la persistance de session.

Les répartiteurs de charge peuvent améliorer considérablement les performances, car ils évitent qu’un serveur soit surchargé tandis que d’autres attendent de recevoir du trafic. Ils permettent également d’augmenter facilement la capacité de vos serveurs web, puisque vous pouvez ajouter des serveurs relativement peu coûteux tout en ayant la certitude qu’ils seront pleinement exploités.

Les protocoles pouvant faire l’objet d’un équilibrage de charge comprennent HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI, SCGI, uwsgi, memcached, ainsi que plusieurs autres types d’applications, notamment les applications basées sur TCP et d’autres protocoles de couche 4. Analysez vos applications web afin de déterminer ceux que vous utilisez et de repérer les problèmes de performances.

Le ou les mêmes serveurs utilisés pour l’équilibrage de charge peuvent également assurer plusieurs autres tâches, telles que la terminaison SSL, la prise en charge de HTTP/1.x et de HTTP/2 côté client, ainsi que la mise en cache des fichiers statiques.

NGINX est souvent utilisé pour la répartition de charge. Pour en savoir plus, téléchargez notre livre numérique, Cinq raisons de choisir un répartiteur de charge logiciel. Vous trouverez des instructions de configuration de base dans Répartition de charge avec NGINX et NGINX Plus, partie 1, ainsi que la documentation complète dans le Guide d’administration de NGINX Plus. NGINX Plus est notre produit commercial. Il prend en charge des fonctionnalités de répartition de charge plus spécialisées, telles que l’acheminement des requêtes en fonction du temps de réponse du serveur et la possibilité de répartir la charge avec le protocole NTLM de Microsoft.

Conseil n° 3 – Mettre en cache le contenu statique et dynamique

La mise en cache améliore les performances des applications web en fournissant plus rapidement le contenu aux clients. Elle peut faire appel à plusieurs stratégies : prétraiter le contenu afin de le fournir rapidement lorsque cela est nécessaire, le stocker sur des appareils plus rapides, le stocker plus près du client ou combiner ces différentes approches.

Il existe deux types de mise en cache à prendre en compte :

• Mise en cache du contenu statique – Les fichiers rarement modifiés, tels que les fichiers image (JPEG, PNG) et les fichiers de code (CSS, JavaScript), peuvent être stockés sur un serveur périphérique afin d’être récupérés rapidement depuis la mémoire ou le disque.
• Mise en cache du contenu dynamique – De nombreuses applications Web génèrent un nouveau code HTML à chaque demande de page. En mettant brièvement en cache une copie du code HTML généré, vous pouvez réduire considérablement le nombre total de pages à générer, tout en fournissant un contenu suffisamment récent pour répondre à vos besoins.

Par exemple, si une page est consultée 10 fois par seconde et que vous la mettez en cache pendant 1 seconde, 90 % des requêtes concernant cette page seront servies depuis le cache. Si vous mettez séparément en cache le contenu statique, même les versions nouvellement générées de la page pourront être constituées en grande partie de contenu mis en cache.

Il existe trois principales techniques de mise en cache du contenu généré par les applications web :

• Rapprocher le contenu des utilisateurs – Conserver une copie du contenu à proximité de l’utilisateur réduit son temps de transmission.
• Déplacer le contenu vers des machines plus rapides – Le contenu peut être stocké sur une machine plus rapide afin d’être récupéré plus rapidement.
• Déplacement du contenu hors des machines surchargées – Les machines sont parfois beaucoup moins performantes que ne l’indiquent les tests de référence pour une tâche donnée, car elles sont occupées à exécuter d’autres tâches. La mise en cache sur une autre machine améliore les performances des ressources mises en cache comme de celles qui ne le sont pas, car la machine hôte est moins sollicitée.

La mise en cache des applications web peut être déployée de l’intérieur — le serveur d’applications web — vers l’extérieur. Elle est d’abord utilisée pour le contenu dynamique afin de réduire la charge des serveurs d’applications. Elle est ensuite appliquée au contenu statique (y compris aux copies temporaires de contenus qui seraient autrement dynamiques), ce qui allège davantage la charge des serveurs d’applications. Enfin, la mise en cache est transférée des serveurs d’applications vers des machines plus rapides et/ou plus proches de l’utilisateur, ce qui soulage les serveurs d’applications et réduit les temps de récupération et de transmission.

Une meilleure mise en cache peut considérablement accélérer les applications. Sur de nombreuses pages web, les données statiques, telles que les fichiers image volumineux, représentent plus de la moitié du contenu. Sans mise en cache, la récupération et la transmission de ces données peuvent prendre plusieurs secondes, contre seulement quelques fractions de seconde si elles sont mises en cache localement.

À titre d’exemple d’utilisation pratique de la mise en cache, NGINX et NGINX Plus utilisent deux directives pour configurer la mise en cache : proxy_cache_path et proxy_cache. Vous définissez l’emplacement et la taille du cache, la durée maximale de conservation des fichiers dans le cache, ainsi que d’autres paramètres. À l’aide d’une troisième directive (très populaire), proxy_cache_use_stale, vous pouvez même demander au cache de fournir du contenu obsolète lorsque le serveur chargé de fournir du contenu à jour est occupé ou indisponible, afin que le client reçoive quelque chose plutôt que rien. Du point de vue de l’utilisateur, cela peut considérablement améliorer la disponibilité de votre site ou de votre application.

NGINX Plus dispose de fonctionnalités avancées de mise en cache, notamment la prise en charge de la purge du cache et l’affichage de l’état du cache dans un tableau de bord pour surveiller l’activité en temps réel.

Pour plus d’informations sur la mise en cache avec NGINX, consultez la documentation de référence et le guide d’administration de NGINX Plus.

Remarque : La mise en cache transcende les frontières organisationnelles entre les personnes qui développent des applications, celles qui prennent les décisions d’investissement et celles qui exploitent les réseaux en temps réel. Les stratégies de mise en cache sophistiquées, comme celles évoquées ici, illustrent bien la valeur d’une approche DevOps, qui réunit les points de vue des développeurs d’applications, des architectes et des équipes d’exploitation afin d’atteindre les objectifs en matière de fonctionnalités du site, de temps de réponse, de sécurité et de résultats commerciaux, tels que les transactions finalisées ou les ventes.

Conseil n° 4 – Compresser les données

La compression peut considérablement améliorer les performances. Il existe notamment des normes de compression soigneusement conçues et très efficaces pour les photos (JPEG et PNG), les vidéos (MPEG‑4) et la musique (MP3). Chacune de ces normes permet de diviser la taille des fichiers par dix, voire davantage.

Les données textuelles – notamment le HTML (qui comprend du texte brut et des balises HTML), le CSS et le code tel que JavaScript – sont souvent transmises sans compression. La compression de ces données peut avoir un impact considérable sur les performances perçues des applications web, en particulier pour les utilisateurs disposant de connexions mobiles lentes ou limitées.

En effet, les données textuelles suffisent souvent à permettre à un utilisateur d’interagir avec une page, tandis que les données multimédias jouent plutôt un rôle complémentaire ou décoratif. Une compression intelligente du contenu peut réduire de 30 % ou plus les besoins en bande passante du HTML, de Javascript, du CSS et d’autres contenus textuels, tout en diminuant d’autant le temps de chargement.

Si vous utilisez SSL, la compression réduit la quantité de données à encoder en SSL, ce qui compense en partie le temps processeur nécessaire à la compression des données.

Les méthodes de compression des données textuelles varient. Par exemple, consultez le conseil 6 pour découvrir un nouveau schéma de compression de texte dans SPDY et HTTP/2, spécialement adapté aux données d’en-tête. Autre exemple de compression de texte : vous pouvez activer la compression GZIP dans NGINX. Après avoir précompressé les données textuelles sur vos services, vous pouvez diffuser directement le fichier compressé .gz à l’aide de la directive gzip_static.

Conseil n° 5 – Optimisez SSL/TLS

Le protocole Secure Sockets Layer (SSL) et son successeur, le protocole Transport Layer Security (TLS), sont utilisés sur un nombre croissant de sites web. SSL/TLS chiffre les données transmises des serveurs d’origine aux utilisateurs afin de renforcer la sécurité des sites. Cette tendance s’explique peut-être en partie par le fait que Google considère désormais la présence de SSL/TLS comme un facteur favorable au classement dans les moteurs de recherche.

Malgré sa popularité croissante, l’impact de SSL/TLS sur les performances reste un point de blocage pour de nombreux sites. SSL/TLS ralentit les performances des sites web pour deux raisons :

1. La négociation initiale requise pour établir les clés de chiffrement à chaque ouverture d’une nouvelle connexion. Le fait que les navigateurs utilisant HTTP/1.x établissent plusieurs connexions par serveur multiplie cette perte de performances.
2. Surcharge permanente liée au chiffrement des données sur le serveur et à leur déchiffrement sur le client.

Afin d’encourager l’utilisation de SSL/TLS, les auteurs de HTTP/2 et de SPDY (décrit dans le conseil suivant) ont conçu ces protocoles de sorte que les navigateurs n’aient besoin que d’une seule connexion par session. Cela réduit considérablement l’une des deux principales sources de surcharge liée à SSL. Toutefois, il est aujourd’hui possible d’aller encore plus loin pour améliorer les performances des applications fournies via SSL/TLS.

Le mécanisme d’optimisation de SSL/TLS varie selon le serveur web. Par exemple, NGINX utilise OpenSSL, exécuté sur du matériel standard courant, pour offrir des performances comparables à celles de solutions matérielles dédiées. Les performances SSL de NGINX sont bien documentées et réduisent au minimum le temps et les ressources processeur nécessaires au chiffrement et au déchiffrement SSL/TLS.

En outre, consultez cet article de blog pour en savoir plus sur les moyens d’améliorer les performances SSL/TLS. En résumé, voici les techniques à utiliser :

• Mise en cache des sessions – Utilise la directive ssl_session_cache pour mettre en cache les paramètres employés lors de la sécurisation de chaque nouvelle connexion avec SSL/TLS.
• Tickets ou identifiants de session – Ils stockent des informations sur des sessions SSL/TLS spécifiques dans un ticket ou un identifiant afin qu’une connexion puisse être réutilisée de manière fluide, sans nouvelle négociation.
• Agrafage OCSP – Réduit le temps de négociation en mettant en cache les informations du certificat SSL/TLS.

NGINX et NGINX Plus peuvent être utilisés pour la terminaison SSL/TLS, afin de gérer le chiffrement et le déchiffrement du trafic client tout en communiquant en clair avec les autres serveurs. Pour configurer NGINX ou NGINX Plus afin de gérer la terminaison SSL/TLS, consultez les instructions relatives aux connexions HTTPS et aux connexions TCP chiffrées.

Conseil n° 6 – Implémentez HTTP/2 ou SPDY

Pour les sites qui utilisent déjà SSL/TLS, HTTP/2 et SPDY sont très susceptibles d’améliorer les performances, car la connexion unique ne nécessite qu’une seule négociation. Pour les sites qui n’utilisent pas encore SSL/TLS, HTTP/2 et SPDY compensent la baisse de performances normalement liée au passage à SSL/TLS, du point de vue de la réactivité.

Google a lancé SPDY en 2012 afin d’améliorer les performances par rapport à HTTP/1.x. HTTP/2 est la norme récemment approuvée par l’IETF et basée sur SPDY. SPDY est largement pris en charge, mais sera bientôt abandonné au profit de HTTP/2.

La principale caractéristique de SPDY et de HTTP/2 est l’utilisation d’une connexion unique plutôt que de plusieurs connexions. Cette connexion unique est multiplexée, ce qui lui permet de transporter simultanément des fragments de plusieurs requêtes et réponses.

En exploitant au maximum une seule connexion, ces protocoles évitent la surcharge liée à l’établissement et à la gestion de plusieurs connexions, qu’impose la manière dont les navigateurs implémentent HTTP/1.x. L’utilisation d’une connexion unique est particulièrement avantageuse avec SSL, car elle réduit au minimum les longues négociations nécessaires à SSL/TLS pour établir une connexion sécurisée.

Le protocole SPDY imposait l’utilisation de SSL/TLS ; HTTP/2 ne l’impose pas officiellement, mais jusqu’à présent, tous les navigateurs prenant en charge HTTP/2 ne l’utilisent que si SSL/TLS est activé. Autrement dit, un navigateur prenant en charge HTTP/2 ne l’utilise que si le site web utilise SSL et que son serveur accepte le trafic HTTP/2. Dans le cas contraire, le navigateur communique via HTTP/1.x.

Lorsque vous mettez en œuvre SPDY ou HTTP/2, vous n’avez plus besoin des optimisations de performances HTTP habituelles, telles que la répartition sur plusieurs domaines, le regroupement des ressources et la création de sprites d’images. Ces changements simplifient votre code et vos déploiements, et facilitent leur gestion. Pour en savoir plus sur les changements apportés par HTTP/2, consultez notre livre blanc, « HTTP/2 pour les développeurs d’applications web ».

À titre d’exemple de prise en charge de ces protocoles, NGINX a très tôt pris en charge SPDY, et la plupart des sites qui utilisent aujourd’hui SPDY fonctionnent avec NGINX. NGINX joue également un rôle pionnier dans la prise en charge de HTTP/2, avec la prise en charge de HTTP/2 dans NGINX Open Source et NGINX Plus depuis septembre 2015.

À terme, chez NGINX, nous pensons que la plupart des sites activeront pleinement SSL et passeront à HTTP/2. Cela permettra de renforcer la sécurité et, à mesure que de nouvelles optimisations seront découvertes et mises en œuvre, d’obtenir un code plus simple et plus performant.

Conseil n° 7 – Mettez à jour les versions des logiciels

Un moyen simple d’améliorer les performances d’une application consiste à sélectionner les composants de votre pile logicielle en fonction de leur réputation en matière de stabilité et de performances. En outre, comme les développeurs de composants de haute qualité sont susceptibles d’en améliorer les performances et de corriger les bogues au fil du temps, il est judicieux d’utiliser la dernière version stable des logiciels. Les nouvelles versions bénéficient d’une plus grande attention de la part des développeurs et de la communauté des utilisateurs. Les builds plus récents tirent également parti des nouvelles optimisations des compilateurs, notamment celles adaptées au nouveau matériel.

Les nouvelles versions stables offrent généralement une meilleure compatibilité et de meilleures performances que les anciennes. Il est également plus facile de suivre les optimisations de performances, les corrections de bogues et les alertes de sécurité lorsque vous maintenez vos logiciels à jour.

Conserver des logiciels anciens peut également vous empêcher de profiter de nouvelles fonctionnalités. Par exemple, HTTP/2, décrit ci-dessus, nécessite actuellement OpenSSL 1.0.1. À partir de la mi-2016, HTTP/2 nécessitera OpenSSL 1.0.2, publié en janvier 2015.

Les utilisateurs de NGINX peuvent commencer par passer à la dernière version de NGINX ou de NGINX Plus ; ces solutions intègrent de nouvelles fonctionnalités telles que le partitionnement des sockets et les pools de threads (voir le conseil n° 9), et leurs performances sont constamment optimisées. Examinez ensuite les logiciels situés plus en profondeur dans votre pile et passez à leur version la plus récente chaque fois que possible.

Conseil n° 8 – Optimisez Linux pour de meilleures performances

Linux est aujourd’hui le système d’exploitation sous-jacent de la plupart des serveurs web. En tant que socle de votre infrastructure, il offre donc d’importantes possibilités d’amélioration des performances. Par défaut, de nombreux systèmes Linux sont configurés de manière prudente afin d’utiliser peu de ressources et de répondre aux besoins d’une charge de travail classique sur un ordinateur de bureau. Pour les applications web, il est donc nécessaire d’ajuster au moins certains paramètres afin d’obtenir des performances optimales.

Les optimisations de Linux dépendent du serveur web utilisé. En prenant NGINX comme exemple, voici quelques changements importants que vous pouvez envisager pour accélérer Linux :

• File d’attente des connexions – Si certaines connexions semblent bloquées, envisagez d’augmenter net.core.somaxconn, qui définit le nombre maximal de connexions pouvant être mises en attente avant d’être traitées par NGINX. Des messages d’erreur s’afficheront si la limite de connexions actuelle est trop faible. Vous pouvez augmenter progressivement ce paramètre jusqu’à ce que ces messages disparaissent.
• Descripteurs de fichiers – NGINX utilise jusqu’à deux descripteurs de fichiers par connexion. Si votre système gère un grand nombre de connexions, vous devrez peut-être augmenter sys.fs.file_max, la limite de descripteurs de fichiers à l’échelle du système, ainsi que nofile, la limite de descripteurs de fichiers par utilisateur, afin de prendre en charge la charge accrue.
• Ports éphémères – Lorsqu’il est utilisé comme proxy, NGINX crée des ports temporaires (« éphémères ») pour chaque serveur en amont. Vous pouvez élargir la plage de valeurs des ports, définie par net.ipv4.ip_local_port_range, afin d’augmenter le nombre de ports disponibles. Vous pouvez également réduire le délai avant qu’un port inactif ne soit réutilisé à l’aide du paramètre net.ipv4.tcp_fin_timeout, ce qui permet une rotation plus rapide.

Pour NGINX, consultez le guide d’optimisation des performances de NGINX pour découvrir comment optimiser votre système Linux afin qu’il puisse gérer sans difficulté d’importants volumes de trafic réseau !

Conseil n° 9 – Optimisez les performances de votre serveur web

Quel que soit le serveur web que vous utilisez, vous devez l’optimiser pour améliorer les performances de vos applications web. Les recommandations suivantes s’appliquent de manière générale à tous les serveurs web, mais des paramètres spécifiques sont indiqués pour NGINX. Les principales optimisations sont les suivantes :

• Journalisation des accès – Au lieu d’écrire immédiatement sur le disque une entrée de journal pour chaque requête, vous pouvez mettre les entrées en mémoire tampon et les écrire sur le disque par lots. Pour NGINX, ajoutez le paramètre buffer=size à la directive access_log afin d’écrire les entrées de journal sur le disque lorsque la mémoire tampon est pleine. Si vous ajoutez le paramètre flush=time, le contenu de la mémoire tampon est également écrit sur le disque une fois le délai spécifié écoulé.
• Mise en mémoire tampon – La mise en mémoire tampon conserve une partie d’une réponse en mémoire jusqu’à ce que le tampon soit plein, ce qui peut rendre les communications avec le client plus efficaces. Les réponses qui ne tiennent pas en mémoire sont écrites sur le disque, ce qui peut ralentir les performances. Lorsque la mise en mémoire tampon de NGINX est activée, utilisez les directives proxy_buffer_size et proxy_buffers pour la gérer.
• Connexions persistantes côté client – Les connexions persistantes réduisent la surcharge, en particulier lorsque SSL/TLS est utilisé. Pour NGINX, vous pouvez augmenter le nombre maximal de requêtes keepalive_requests qu’un client peut effectuer sur une connexion donnée par rapport à la valeur par défaut de 100, et augmenter le délai keepalive_timeout afin que la connexion persistante reste ouverte plus longtemps, ce qui accélère les requêtes suivantes.
• Connexions persistantes en amont – Les connexions en amont – connexions aux serveurs d’applications, aux serveurs de bases de données, etc. – bénéficient également des connexions persistantes. Pour les connexions en amont, vous pouvez augmenter keepalive, c’est-à-dire le nombre de connexions persistantes inactives qui restent ouvertes pour chaque processus de travail. Cela permet de réutiliser davantage les connexions et réduit la nécessité d’en ouvrir de nouvelles. Pour plus d’informations, consultez notre article de blog, Connexions HTTP persistantes et performances Web.
• Limites – Limiter les ressources utilisées par les clients peut améliorer les performances et la sécurité. Pour NGINX, les directives limit_conn et limit_conn_zone limitent le nombre de connexions provenant d’une source donnée, tandis que limit_rate limite la bande passante. Ces paramètres peuvent empêcher un utilisateur légitime de monopoliser les ressources et contribuent également à prévenir les attaques. Les directives limit_req et limit_req_zone limitent les requêtes des clients. Pour les connexions aux serveurs en amont, utilisez le paramètre max_conns de la directive server dans un bloc de configuration upstream. Cela limite les connexions à un serveur en amont afin d’éviter toute surcharge. La directive queue associée crée une file d’attente qui conserve un nombre défini de requêtes pendant une durée déterminée une fois la limite max_conns atteinte.
• Processus de travail – Les processus de travail sont chargés de traiter les requêtes. NGINX utilise un modèle événementiel et des mécanismes propres au système d’exploitation pour répartir efficacement les requêtes entre les processus de travail. Il est recommandé de définir la valeur de worker_processes sur un processus par processeur. Le nombre maximal de worker_connections (512 par défaut) peut être augmenté sans risque sur la plupart des systèmes si nécessaire ; faites des essais pour déterminer la valeur la mieux adaptée à votre système.
• Partitionnement des sockets – En règle générale, un seul socket d’écoute distribue les nouvelles connexions à tous les processus de travail. Le partitionnement des sockets crée un socket d’écoute pour chaque processus de travail, le noyau attribuant les connexions aux sockets d’écoute à mesure qu’ils deviennent disponibles. Cela peut réduire la contention des verrous et améliorer les performances sur les systèmes multicœurs. Pour activer le partitionnement des sockets, ajoutez le paramètre reuseport à la directive listen.
• Pools de threads – Tout processus informatique peut être bloqué par une seule opération lente. Dans le cas d’un logiciel de serveur web, l’accès au disque peut bloquer de nombreuses opérations plus rapides, telles que le calcul ou la copie d’informations en mémoire. Lorsqu’un pool de threads est utilisé, l’opération lente est confiée à un ensemble de tâches distinct, tandis que la boucle de traitement principale continue d’exécuter les opérations plus rapides. Une fois l’opération sur le disque terminée, les résultats sont renvoyés dans la boucle de traitement principale. Dans NGINX, deux opérations – l’appel système read() et sendfile() – sont déléguées à des pools de threads.

Conseil : lorsque vous modifiez les paramètres d’un système d’exploitation ou d’un service associé, ne modifiez qu’un seul paramètre à la fois, puis testez les performances. Si la modification entraîne des problèmes ou n’accélère pas votre site, annulez-la.

Pour en savoir plus sur l’optimisation d’un serveur web NGINX, consultez notre article de blog, « Optimiser les performances de NGINX ».

Conseil n° 10 – Surveillez l’activité en temps réel pour résoudre les problèmes et éliminer les goulots d’étranglement

La clé d’une approche hautement performante du développement et de la livraison d’applications consiste à surveiller de près et en temps réel les performances de votre application en conditions réelles. Vous devez être en mesure de suivre l’activité sur des appareils spécifiques et dans l’ensemble de votre infrastructure web.

La surveillance de l’activité du site est essentiellement passive : elle vous indique ce qui se passe, mais c’est à vous de repérer les problèmes et de les résoudre.

La surveillance peut détecter plusieurs types de problèmes, notamment :

• Un serveur est hors service.
• Un serveur fonctionne au ralenti et perd des connexions.
• Un serveur présente une proportion élevée de défauts de cache.
• Un serveur n’envoie pas le contenu approprié.

Un outil global de surveillance des performances applicatives tel que New Relic ou Dynatrace vous aide à surveiller le temps de chargement des pages depuis des sites distants, tandis que NGINX vous permet de superviser la diffusion des applications. Les données sur les performances applicatives vous indiquent quand vos optimisations font réellement la différence pour vos utilisateurs et quand vous devez envisager d’augmenter la capacité de votre infrastructure pour absorber le trafic.

Pour vous aider à identifier et à résoudre rapidement les problèmes, NGINX Plus ajoute des contrôles d’intégrité tenant compte des applications – des transactions synthétiques répétées régulièrement et utilisées pour vous alerter en cas de problème. NGINX Plus propose également le drainage des sessions, qui interrompt les nouvelles connexions tout en laissant les tâches existantes se terminer, ainsi qu’une fonctionnalité de démarrage progressif, qui permet à un serveur rétabli de monter progressivement en charge au sein d’un groupe à charge équilibrée. Lorsqu’ils sont utilisés efficacement, les contrôles d’intégrité permettent d’identifier les problèmes avant qu’ils n’aient un impact significatif sur l’expérience utilisateur, tandis que le drainage des sessions et le démarrage progressif permettent de remplacer des serveurs tout en veillant à ce que le processus n’affecte pas négativement les performances perçues ni la disponibilité. La figure présente le tableau de bord intégré de surveillance de l’activité en temps réel de NGINX Plus pour une infrastructure web comprenant des serveurs, des connexions TCP et une mise en cache.

Conclusion – Des performances multipliées par 10

Les améliorations de performances possibles pour une application web donnée varient considérablement, et les gains réels dépendent de votre budget, du temps que vous pouvez y consacrer et des lacunes de votre implémentation actuelle. Alors, comment pourriez-vous multiplier par 10 les performances de vos propres applications ?

Pour vous aider à évaluer l’impact potentiel de chaque optimisation, voici quelques indications sur les gains que chacune des astuces détaillées ci-dessus pourrait permettre d’obtenir, même si les résultats varieront très certainement selon votre situation :

• Serveur proxy inverse et répartition de charge – L’absence de répartition de charge, ou une mauvaise répartition, peut entraîner des épisodes de très faibles performances. L’ajout d’un serveur proxy inverse, tel que NGINX, peut empêcher les applications web de basculer sans cesse entre la mémoire et le disque. La répartition de charge permet de transférer les traitements des serveurs surchargés vers ceux qui sont disponibles et facilite la mise à l’échelle. Ces changements peuvent améliorer considérablement les performances, avec un gain pouvant facilement atteindre un facteur 10 par rapport aux pires moments de votre implémentation actuelle, ainsi que des gains moindres, mais néanmoins substantiels, sur les performances globales.
• Mise en cache du contenu dynamique et statique – Si votre serveur web est surchargé et fait également office de serveur d’applications, la seule mise en cache du contenu dynamique peut multiplier par 10 les performances aux heures de pointe. La mise en cache des fichiers statiques peut également multiplier les performances par un facteur inférieur à 10.
• Compression des données – L’utilisation de formats de compression de fichiers multimédias tels que JPEG pour les photos, PNG pour les images, MPEG‑4 pour les vidéos et MP3 pour les fichiers audio peut considérablement améliorer les performances. Une fois tous ces formats utilisés, la compression des données textuelles (code et HTML) peut réduire de moitié le temps de chargement initial des pages.
• Optimisation de SSL/TLS – Les négociations sécurisées peuvent avoir un impact considérable sur les performances. Leur optimisation peut donc permettre de doubler la réactivité initiale, en particulier pour les sites comportant beaucoup de texte. L’optimisation de la transmission des fichiers multimédias via SSL/TLS ne devrait apporter que de faibles gains de performances.
• Mise en œuvre de HTTP/2 et de SPDY – Lorsqu’ils sont utilisés avec SSL/TLS, ces protocoles sont susceptibles d’améliorer progressivement les performances globales du site.
• Optimisation de Linux et des logiciels de serveur web (tels que NGINX) – Des ajustements tels que l’optimisation de la mise en mémoire tampon, l’utilisation de connexions persistantes et le transfert des tâches chronophages vers un pool de threads distinct peuvent améliorer considérablement les performances. Par exemple, les pools de threads peuvent accélérer les tâches sollicitant fortement le disque de près d’un ordre de grandeur.

Nous espérons que vous testerez vous-même ces techniques. Nous aimerions savoir quelles améliorations des performances de vos applications vous parviendrez à obtenir. Partagez vos résultats dans les commentaires ci-dessous ou racontez votre expérience sur Twitter avec les hashtags #NGINX et #webperf !

Ressources sur les statistiques d’Internet

Statista.com – Part de l’économie numérique dans le produit intérieur brut des pays du G20 en 2016

Kissmetrics – Comment le temps de chargement affecte vos résultats financiers (infographie)

Econsultancy – Vitesse du site : études de cas, conseils et outils pour améliorer votre taux de conversion

À propos de l’auteur

Floyd SmithDirecteur du marketing de contenu

Autres articles de Floyd Smith