10 conseils pour multiplier par 10 les performances de vos applications

L’amélioration des performances des applications Web est plus cruciale que jamais. La part de l’activité économique en ligne est en augmentation ; plus de 5 % de l’économie du monde développé est désormais sur Internet (voir Ressources pour les statistiques Internet ci-dessous). Et dans notre monde moderne, toujours connecté et en constante évolution, les attentes des utilisateurs sont 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 réalisée par Amazon il y a près de 10 ans a prouvé que, même à cette époque, une diminution de 100 millisecondes du temps de chargement d’une page se traduisait par une augmentation de 1 % de ses revenus. Une autre étude récente a souligné le fait que plus de la moitié des propriétaires de sites interrogés ont déclaré avoir perdu des revenus ou des clients en raison de mauvaises performances des applications.

À quelle vitesse un site Web doit-il être ? Pour chaque seconde nécessaire au chargement d’une page, environ 4 % des utilisateurs l’abandonnent. Les meilleurs sites de commerce électronique offrent un délai de première interaction allant d'une à trois secondes, ce qui offre le taux de conversion le plus élevé. Il est clair que les enjeux en matière de performances des applications Web sont élevés et susceptibles de croître.

Vouloir améliorer les performances est facile, mais voir des résultats concrets est difficile. Pour vous aider dans votre parcours, cet article de blog vous propose dix conseils pour vous aider à augmenter les performances de votre site Web jusqu'à 10 fois. Il s’agit du premier d’une série qui détaille comment vous pouvez augmenter les performances de votre application à l’aide de techniques d’optimisation éprouvées et avec un peu d’aide de NGINX. Cette série décrit également les améliorations potentielles en matière de sécurité que vous pouvez obtenir en cours de route.

Astuce 1 – Accélérez et sécurisez les 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'acquérir une machine plus rapide, avec plus de processeur, plus de RAM, une matrice de disques rapide, etc. La nouvelle machine peut 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 : obtenir deux machines plus rapides et une connexion plus rapide entre elles.)

Le problème est que la vitesse de la machine n’est peut-être pas le problème. Les applications Web s'exécutent souvent lentement car l'ordinateur bascule entre différents types de tâches : interaction avec les utilisateurs sur des milliers de connexions, accès aux fichiers à partir du disque et exécution du code d'application, entre autres. Le serveur d'applications peut être en proie à des problèmes : il manque de mémoire, échange des morceaux de mémoire sur le disque et fait attendre de nombreuses requêtes sur une seule tâche, comme les E/S sur disque.

Au lieu de mettre à niveau votre matériel, vous pouvez adopter une approche entièrement différente : ajouter un serveur proxy inverse pour décharger certaines de ces tâches. Un serveur proxy inverse se trouve devant la machine exécutant l'application et gère le trafic Internet. Seul le serveur proxy inverse est connecté directement à Internet ; la communication avec les serveurs d'applications s'effectue via un réseau interne rapide.

L'utilisation d'un serveur proxy inverse libère le serveur d'applications de l'obligation d'attendre que les utilisateurs interagissent avec l'application Web et lui permet de se concentrer sur la création de pages que le serveur proxy inverse envoie sur Internet. Le serveur d’application, qui n’a plus besoin d’attendre les réponses des clients, peut fonctionner à des vitesses proches de celles atteintes dans les tests de performances optimisés.

L'ajout d'un serveur proxy inverse ajoute également de la flexibilité à la configuration de votre serveur Web. Par exemple, si un serveur d'un type donné est surchargé, un autre serveur du même type peut facilement être ajouté ; si un serveur est en panne, il peut facilement être remplacé.

En raison de la flexibilité qu’il offre, un serveur proxy inverse est également une condition préalable à de nombreuses autres fonctionnalités d’amélioration des performances, telles que :

• Équilibrage de charge (voir Astuce 2 ) – Un équilibreur de charge s’exécute sur un serveur proxy inverse pour partager le trafic de manière uniforme entre plusieurs serveurs d’applications. Avec un équilibreur de charge en place, vous pouvez ajouter des serveurs d’applications sans modifier du tout votre application.
• Mise en cache des fichiers statiques (voir Astuce 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, ce qui permet de traiter les ressources plus rapidement et de décharger le serveur d'applications, ce qui permet à l'application de s'exécuter plus rapidement.
• Sécurisation de votre site – Le serveur proxy inverse peut être configuré pour une sécurité élevée et surveillé pour une reconnaissance et une réponse rapides aux attaques, gardant ainsi les serveurs d'applications protégés.

Le logiciel NGINX est spécifiquement 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 événements qui est plus efficace que les serveurs traditionnels. NGINX Plus ajoute des fonctionnalités de proxy inverse plus avancées, telles que les contrôles de santé des applications, le routage des requêtes spécialisées, la mise en cache avancée et le support.

Astuce 2 – Ajoutez un équilibreur de charge

L'ajout d'un équilibreur de charge est un changement relativement simple qui peut créer une amélioration spectaculaire des performances et de la sécurité de votre site. Au lieu de rendre un serveur Web principal plus grand et plus puissant, vous utilisez un équilibreur de charge pour répartir le trafic sur plusieurs serveurs. Même si une application est mal écrite ou présente des problèmes de mise à l'échelle, un équilibreur de charge peut améliorer l'expérience utilisateur sans aucune autre modification.

Un équilibreur de charge est avant tout un serveur proxy inverse (voir Astuce 1 ) : il reçoit le trafic Internet et transmet les requêtes à un autre serveur. L’astuce est que l’équilibreur de charge prend en charge deux ou plusieurs serveurs d’applications, en utilisant un choix d’algorithmes pour répartir les requêtes entre les serveurs. L’approche d’équilibrage de charge la plus simple est le round robin, chaque nouvelle requête étant envoyée au serveur suivant de la liste. D’autres méthodes incluent l’envoi de requêtes au serveur avec le moins de connexions actives. NGINX Plus dispose de capacités permettant de poursuivre une session utilisateur donnée sur le même serveur, ce que l'on appelle la persistance de session.

Les équilibreurs de charge peuvent entraîner de fortes améliorations des performances, car ils empêchent un serveur d'être surchargé pendant que d'autres serveurs attendent le trafic. Ils facilitent également l’extension de la capacité de votre serveur Web, car vous pouvez ajouter des serveurs relativement peu coûteux et être sûr qu’ils seront pleinement utilisés.

Les protocoles pouvant être équilibrés en charge incluent HTTP, HTTPS, SPDY, HTTP/2, WebSocket, FastCGI , SCGI, uwsgi, memcached et plusieurs autres types d'applications, notamment les applications basées sur TCP et d'autres protocoles de couche 4. Analysez vos applications Web pour déterminer celles que vous utilisez et où les performances sont inférieures.

Le même serveur ou les mêmes serveurs utilisés pour l'équilibrage de charge peuvent également gérer plusieurs autres tâches, telles que la terminaison SSL, la prise en charge de l'utilisation de HTTP/1. x et HTTP/2 par les clients et la mise en cache des fichiers statiques.

NGINX est souvent utilisé pour l'équilibrage de charge. Pour en savoir plus, téléchargez notre livre électronique, Cinq raisons de choisir un équilibreur de charge logiciel . Vous pouvez obtenir des instructions de configuration de base dans Équilibrage de charge avec NGINX et NGINX Plus, partie 1 , ainsi qu'une documentation complète dans le Guide d'administration NGINX Plus . NGINX Plus est notre produit commercial et prend en charge des fonctionnalités d'équilibrage de charge plus spécialisées telles que le routage de charge basé sur le temps de réponse du serveur et la possibilité d'équilibrer la charge sur le protocole NTLM de Microsoft.

Astuce 3 – Mettez en cache le contenu statique et dynamique

La mise en cache améliore les performances des applications Web en fournissant du contenu aux clients plus rapidement. La mise en cache peut impliquer plusieurs stratégies : prétraiter le contenu pour une livraison rapide en cas de besoin, stocker le contenu sur des appareils plus rapides, stocker le contenu plus près du client, ou une combinaison.

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

• Mise en cache du contenu statique – Les fichiers qui changent rarement, tels que les fichiers image (JPEG, PNG) et les fichiers de code (CSS, JavaScript), peuvent être stockés sur un serveur Edge pour une récupération rapide à partir de la mémoire ou du disque.
• Mise en cache du contenu dynamique – De nombreuses applications Web génèrent du nouveau code HTML pour chaque demande de page. En mettant brièvement en cache une copie du code HTML généré pendant une courte période, 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.

Si une page obtient 10 vues par seconde, par exemple, et que vous la mettez en cache pendant 1 seconde, 90 % des requêtes pour la page proviendront du cache. Si vous mettez en cache séparément le contenu statique, même les versions fraîchement générées de la page peuvent être constituées en grande partie de contenu mis en cache.

Il existe trois techniques principales pour mettre en cache le contenu généré par les applications Web :

• Rapprocher le contenu des utilisateurs – Garder une copie du contenu plus proche de l’utilisateur réduit son temps de transmission.
• Déplacement de contenu vers des machines plus rapides – Le contenu peut être conservé sur une machine plus rapide pour une récupération plus rapide.
• Déplacer le contenu des machines surutilisées – Les machines fonctionnent parfois beaucoup plus lentement que leurs performances de référence sur une tâche particulière parce qu’elles sont occupées par d’autres tâches. La mise en cache sur une autre machine améliore les performances des ressources mises en cache et également des ressources non mises en cache, car la machine hôte est moins surchargée.

La mise en cache des applications Web peut être implémentée de l'intérieur (du serveur d'applications Web) vers l'extérieur. Premièrement, la mise en cache est utilisée pour le contenu dynamique, afin de réduire la charge sur les serveurs d’applications. Ensuite, la mise en cache est utilisée pour le contenu statique (y compris les copies temporaires de ce qui serait autrement du contenu dynamique), déchargeant ainsi davantage les serveurs d’applications. La mise en cache est ensuite déplacée des serveurs d’applications vers des machines plus rapides et/ou plus proches de l’utilisateur, ce qui décharge les serveurs d’applications et réduit les temps de récupération et de transmission.

Une mise en cache améliorée peut considérablement accélérer les applications. Pour de nombreuses pages Web, les données statiques, telles que les fichiers image volumineux, représentent plus de la moitié du contenu. La récupération et la transmission de ces données peuvent prendre plusieurs secondes sans mise en cache, mais seulement quelques fractions de seconde si les données sont mises en cache localement.

À titre d’exemple de la manière dont la mise en cache est utilisée dans la pratique, NGINX et NGINX Plus utilisent deux directives pour configurer la mise en cache : proxy_cache_path et proxy_cache . Vous spécifiez l'emplacement et la taille du cache, la durée maximale pendant laquelle les fichiers sont conservés dans le cache et d'autres paramètres. En utilisant une troisième directive (et assez populaire), proxy_cache_use_stale , vous pouvez même diriger le cache pour fournir du contenu obsolète lorsque le serveur qui fournit du contenu nouveau est occupé ou en panne, donnant ainsi au client 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 de mise en cache avancées , notamment la prise en charge de la purge du cache et la visualisation de l'état du cache sur un tableau de bord pour la surveillance des activités en direct.

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

Note : La mise en cache traverse les lignes organisationnelles entre les personnes qui développent des applications, celles qui prennent des décisions d’investissement en capital et celles qui gèrent les réseaux en temps réel. Les stratégies de mise en cache sophistiquées, comme celles évoquées ici, sont un bon exemple de la valeur d'une perspective DevOps , dans laquelle les perspectives du développeur d'applications, de l'architecture et des opérations sont fusionnées pour aider à atteindre les objectifs de fonctionnalité du site, de temps de réponse, de sécurité et de résultats commerciaux, tels que les transactions ou les ventes terminées.

Astuce 4 – Compressez les données

La compression est un énorme accélérateur de performances potentiel. Il existe 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), entre autres. Chacune de ces normes réduit la taille du fichier d’un ordre de grandeur ou plus.

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

C’est parce que les données textuelles sont souvent suffisantes pour qu’un utilisateur puisse interagir avec une page, là où les données multimédias peuvent être plus utiles ou décoratives. La compression de contenu intelligente peut réduire les besoins en bande passante du contenu HTML, Javascript, CSS et autres contenus textuels, généralement de 30 % ou plus, avec une réduction correspondante du temps de chargement.

Si vous utilisez SSL, la compression réduit la quantité de données à encoder via SSL, ce qui compense une partie du temps CPU nécessaire à la compression des données.

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

Astuce 5 – Optimisez SSL/TLS

Le protocole Secure Sockets Layer ( SSL ) et son successeur, le protocole Transport Layer Security (TLS), sont utilisés sur de plus en plus de sites Web. SSL/TLS crypte les données transportées depuis les serveurs d'origine vers les utilisateurs pour aider à améliorer la sécurité du site. Ce qui peut influencer cette tendance est en partie le fait que Google utilise désormais la présence de SSL/TLS comme une influence positive sur le classement des moteurs de recherche.

Malgré une popularité croissante, les pertes de performances liées à SSL/TLS constituent un problème pour de nombreux sites. SSL/TLS ralentit les performances du site Web pour deux raisons :

1. La poignée de main initiale requise pour établir les clés de chiffrement chaque fois qu'une nouvelle connexion est ouverte. La façon dont les navigateurs utilisant HTTP/1. x établissent plusieurs connexions par serveur multiplie ce succès.
2. Frais généraux continus liés au cryptage des données sur le serveur et à leur décryptage sur le client.

Pour encourager l’utilisation de SSL/TLS, les auteurs de HTTP/2 et SPDY (décrits dans l’ astuce suivante ) ont conçu ces protocoles de manière à ce que les navigateurs n’aient besoin que d’une seule connexion par session de navigation. Cela réduit considérablement l’une des deux principales sources de surcharge SSL. Toutefois, il est encore possible de faire davantage aujourd’hui pour améliorer les performances des applications diffusées via SSL/TLS.

Le mécanisme d’optimisation SSL/TLS varie selon le serveur Web. À titre d’exemple, NGINX utilise OpenSSL , exécuté sur du matériel standard, pour fournir des performances similaires aux solutions matérielles dédiées. Les performances SSL de NGINX sont bien documentées et minimisent la pénalité de temps et de CPU liée à l’exécution du chiffrement et du déchiffrement SSL/TLS.

En outre, consultez cet article de blog pour plus de détails sur les moyens d’augmenter les performances SSL/TLS. Pour résumer brièvement, les techniques sont :

• Mise en cache de session – Utilise la directive ssl_session_cache pour mettre en cache les paramètres utilisé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 en douceur, 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 – gérant le cryptage et le décryptage du trafic client, tout en communiquant avec d'autres serveurs en texte clair. 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 .

Astuce 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 poignée de main. Pour les sites qui n’utilisent pas encore SSL/TLS, HTTP/2 et SPDY rendent le passage à SSL/TLS (qui ralentit normalement les performances) un échec du point de vue de la réactivité.

Google a introduit SPDY en 2012 comme moyen d'obtenir des performances plus rapides sur HTTP/1. x . HTTP/2 est la norme IETF récemment approuvée basée sur SPDY. SPDY est largement pris en charge, mais sera bientôt obsolète et remplacé par HTTP/2.

La caractéristique clé de SPDY et HTTP/2 est l’utilisation d’une seule connexion plutôt que de plusieurs connexions. La connexion unique est multiplexée, elle peut donc transporter des morceaux de plusieurs requêtes et réponses en même temps.

En tirant le meilleur parti d'une connexion, ces protocoles évitent les frais généraux liés à la configuration et à la gestion de plusieurs connexions, comme l'exige la manière dont les navigateurs implémentent HTTP/1. x . L’utilisation d’une connexion unique est particulièrement utile avec SSL, car elle minimise le temps nécessaire à la négociation SSL/TLS pour établir une connexion sécurisée.

Le protocole SPDY nécessite l'utilisation de SSL/TLS ; HTTP/2 ne l'exige pas officiellement, mais tous les navigateurs qui prennent en charge HTTP/2 ne l'utilisent jusqu'à présent que si SSL/TLS est activé. Autrement dit, un navigateur qui prend en charge HTTP/2 l’utilise uniquement si le site Web utilise SSL et que son serveur accepte le trafic HTTP/2. Sinon, le navigateur communique via HTTP/1. x .

Lorsque vous implémentez SPDY ou HTTP/2, vous n'avez plus besoin des optimisations de performances HTTP classiques telles que le partitionnement de domaine, la fusion de ressources et le spriting d'image. Ces modifications rendent votre code et vos déploiements plus simples et plus faciles à gérer. Pour en savoir plus sur les changements apportés par HTTP/2, lisez notre livre blanc, HTTP/2 pour les développeurs d'applications Web .

À titre d'exemple de prise en charge de ces protocoles, NGINX a pris en charge SPDY dès le début, et la plupart des sites qui utilisent SPDY aujourd'hui fonctionnent sur NGINX. NGINX est également un pionnier de 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.

Au fil du temps, chez NGINX, nous prévoyons que la plupart des sites activeront entièrement SSL et passeront à HTTP/2. Cela conduira à une sécurité accrue et, à mesure que de nouvelles optimisations seront trouvées et mises en œuvre, à un code plus simple et plus performant.

Astuce 7 – Mettre à jour les versions des logiciels

Un moyen simple d’améliorer les performances des applications consiste à sélectionner les composants de votre pile logicielle en fonction de leur réputation de stabilité et de performances. De plus, étant donné que les développeurs de composants de haute qualité sont susceptibles de rechercher des améliorations de performances et de corriger les bogues au fil du temps, il est avantageux d’utiliser la dernière version stable du logiciel. Les nouvelles versions reçoivent davantage d’attention de la part des développeurs et de la communauté des utilisateurs. Les versions plus récentes bénéficient également de nouvelles optimisations du compilateur, notamment le réglage pour le nouveau matériel.

Les nouvelles versions stables sont généralement plus compatibles et plus performantes que les anciennes versions. Il est également plus facile de se tenir au courant des optimisations de réglage, des corrections de bogues et des alertes de sécurité lorsque vous restez au courant des mises à jour logicielles.

Rester avec des logiciels plus 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 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 NGINX Plus ; ils incluent de nouvelles fonctionnalités telles que le sharding de socket et les pools de threads (voir Astuce 9 ), et les deux sont constamment optimisés pour les performances. Ensuite, examinez les logiciels plus en profondeur dans votre pile et passez à la version la plus récente chaque fois que vous le pouvez.

Astuce n°8 – Régler Linux pour les performances

Linux est le système d’exploitation sous-jacent à la plupart des implémentations de serveurs Web actuelles et, en tant que base de votre infrastructure, Linux représente une opportunité significative d’améliorer les performances. Par défaut, de nombreux systèmes Linux sont réglés de manière conservatrice pour utiliser peu de ressources et pour correspondre à une charge de travail de bureau typique. Cela signifie que les cas d’utilisation d’applications Web nécessitent au moins un certain degré de réglage pour des performances maximales.

Les optimisations Linux sont spécifiques au serveur Web. En prenant NGINX comme exemple, voici quelques points saillants des changements que vous pouvez envisager pour accélérer Linux :

• File d'attente du backlog – Si vous avez des connexions qui semblent se bloquer, envisagez d'augmenter net.core.somaxconn , le nombre maximal de connexions qui peuvent être mises en file d'attente en attendant l'attention de NGINX. Vous verrez des messages d'erreur si la limite de connexion existante est trop faible, et vous pouvez augmenter progressivement ce paramètre jusqu'à ce que les messages d'erreur cessent.
• Descripteurs de fichiers – NGINX utilise jusqu’à deux descripteurs de fichiers pour chaque connexion. Si votre système gère un grand nombre de connexions, vous devrez peut-être augmenter sys.fs.file_max , la limite à l'échelle du système pour les descripteurs de fichiers, et nofile , la limite du descripteur de fichiers utilisateur, pour 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 augmenter la plage de valeurs de port, définie par net.ipv4.ip_local_port_range , pour augmenter le nombre de ports disponibles. Vous pouvez également réduire le délai d'expiration avant qu'un port inactif ne soit réutilisé avec le paramètre net.ipv4.tcp_fin_timeout , permettant un renouvellement plus rapide.

Pour NGINX, consultez le guide de réglage des performances NGINX pour savoir comment optimiser votre système Linux afin qu'il puisse gérer de gros volumes de trafic réseau sans transpirer !

Astuce n° 9 – Réglez votre serveur Web pour optimiser ses performances

Quel que soit le serveur Web que vous utilisez, vous devez le régler pour les performances des applications Web. Les recommandations suivantes s'appliquent généralement à tout serveur Web, mais des paramètres spécifiques sont fournis pour NGINX. Les principales optimisations incluent :

• Journalisation des accès – Au lieu d’écrire immédiatement une entrée de journal pour chaque demande sur le disque, vous pouvez mettre en mémoire tampon les entrées et les écrire sur le disque en tant que groupe. Pour NGINX, ajoutez le paramètre buffer= size à la directive access_log pour é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 du tampon sera également écrit sur le disque après la durée spécifiée.
• Mise en mémoire tampon – La mise en mémoire tampon conserve une partie d’une réponse en mémoire jusqu’à ce que la mémoire tampon soit remplie, ce qui peut rendre les communications avec le client plus efficaces. Les réponses qui ne rentrent pas dans la mémoire sont écrites sur le disque, ce qui peut ralentir les performances. Lorsque la mise en mémoire tampon NGINX est activée , vous utilisez les directives proxy_buffer_size et proxy_buffers pour la gérer.
• Keepalives client – Les connexions Keepalives réduisent les frais généraux, en particulier lorsque SSL/TLS est utilisé. Pour NGINX, vous pouvez augmenter le nombre maximal de keepalive_requests qu'un client peut effectuer sur une connexion donnée à partir de la valeur par défaut de 100, et vous pouvez augmenter le keepalive_timeout pour permettre à la connexion keepalive de rester ouverte plus longtemps, ce qui entraîne des demandes ultérieures plus rapides.
• Keepalives en amont – Les connexions en amont (connexions aux serveurs d’applications, aux serveurs de base de données, etc.) bénéficient également des connexions keepalive. Pour les connexions en amont, vous pouvez augmenter keepalive , le nombre de connexions keepalive inactives qui restent ouvertes pour chaque processus de travail. Cela permet une réutilisation accrue des connexions, réduisant ainsi le besoin d'ouvrir de nouvelles connexions. Pour plus d'informations, consultez notre article de blog, Connexions HTTP Keepalive 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 à partir 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 » des ressources et également aider à 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 serveur dans un bloc de configuration en amont . Cela limite les connexions à un serveur en amont, évitant ainsi toute surcharge. La directive de file d'attente associée crée une file d'attente qui contient un nombre spécifié de requêtes pendant une durée spécifiée une fois que la limite max_conns est atteinte.
• Processus de travail – Les processus de travail sont responsables du traitement des demandes. NGINX utilise un modèle basé sur les événements et des mécanismes dépendants du système d’exploitation pour répartir efficacement les demandes entre les processus de travail. La recommandation est de définir la valeur de worker_processes sur un par CPU. Le nombre maximal de connexions worker_connections (512 par défaut) peut être augmenté en toute sécurité sur la plupart des systèmes si nécessaire ; expérimentez pour trouver la valeur qui convient le mieux à votre système.
• Socket sharding – En général, un seul écouteur de socket distribue les nouvelles connexions à tous les processus de travail. Le partitionnement de socket crée un écouteur de socket pour chaque processus de travail, le noyau attribuant des connexions aux écouteurs de socket dès qu'ils deviennent disponibles. Cela peut réduire les conflits de verrouillage et améliorer les performances sur les systèmes multicœurs. Pour activer le partitionnement de socket , incluez le paramètre reuseport dans la directive listen .
• Pools de threads – Tout processus informatique peut être retardé par une seule opération lente. Pour les logiciels de serveur Web, l'accès au disque peut retarder 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 affectée à un ensemble distinct de tâches, tandis que la boucle de traitement principale continue d'exécuter des opérations plus rapides. Une fois l’opération sur le disque terminée, les résultats reviennent dans la boucle de traitement principale. Dans NGINX, deux opérations – l’appel système read() et sendfile() – sont déchargées vers des pools de threads .

Conseil . Lorsque vous modifiez les paramètres d’un système d’exploitation ou d’un service de support, modifiez un seul paramètre à la fois, puis testez les performances. Si le changement entraîne des problèmes ou s'il n'accélère pas le fonctionnement de votre site, rétablissez-le.

Pour en savoir plus sur le réglage d'un serveur Web NGINX, consultez notre article de blog, Réglage de NGINX pour les performances .

Astuce n° 10 – Surveillez l’activité en direct pour résoudre les problèmes et les goulots d’étranglement

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

La surveillance de l’activité du site est principalement passive : elle vous indique ce qui se passe et vous laisse le soin de repérer les problèmes et de les résoudre.

La surveillance peut détecter plusieurs types de problèmes différents. Ils comprennent :

• Un serveur est en panne.
• Un serveur est en panne et perd les connexions.
• Un serveur souffre d'une forte proportion d'échecs de cache.
• Un serveur n'envoie pas le contenu correct.

Un outil de surveillance des performances des applications globales comme New Relic ou Dynatrace vous aide à surveiller le temps de chargement des pages à partir d'emplacements distants, tandis que NGINX vous aide à surveiller le côté distribution des applications. Les données de performances des applications vous indiquent quand vos optimisations font une réelle différence pour vos utilisateurs et quand vous devez envisager d'ajouter de la capacité à votre infrastructure pour soutenir le trafic.

Pour aider à identifier et à résoudre rapidement les problèmes, NGINX Plus ajoute des contrôles de santé prenant en compte les applications : des transactions synthétiques qui sont répétées régulièrement et utilisées pour vous alerter des problèmes. NGINX Plus dispose également d' une fonction de drainage de session , qui arrête les nouvelles connexions pendant que les tâches existantes se terminent, et d'une fonction de démarrage lent, permettant à un serveur récupéré de reprendre sa vitesse de croisière au sein d'un groupe à charge équilibrée. Lorsqu'ils sont utilisés efficacement, les contrôles de santé vous permettent d'identifier les problèmes avant qu'ils n'aient un impact significatif sur l'expérience utilisateur, tandis que l'épuisement des sessions et le démarrage lent vous permettent de remplacer les serveurs et de garantir que le processus n'affecte pas négativement les performances ou la disponibilité perçues. L’illustration montre le tableau de bord de surveillance d’activité en direct intégré NGINX Plus pour une infrastructure Web avec serveurs, connexions TCP et mise en cache.

Conclusion – Une amélioration des performances multipliée par 10

Les améliorations de performances disponibles pour une application Web varient énormément, et les gains réels dépendent de votre budget, du temps que vous pouvez investir et des lacunes de votre implémentation existante. Alors, comment pourriez-vous obtenir une amélioration des performances de 10 fois pour vos propres applications ?

Pour vous aider à comprendre l'impact potentiel de chaque optimisation, voici quelques indications sur l'amélioration qui peut être possible avec chaque conseil détaillé ci-dessus, même si votre kilométrage variera presque certainement :

• Serveur proxy inverse et équilibrage de charge – L’absence d’équilibrage de charge, ou un équilibrage de charge médiocre, peut entraîner des épisodes de très mauvaises performances. L'ajout d'un serveur proxy inverse, tel que NGINX, peut empêcher les applications Web de se balancer entre la mémoire et le disque. L'équilibrage de charge peut déplacer le traitement des serveurs surchargés vers ceux disponibles et faciliter la mise à l'échelle. Ces changements peuvent entraîner une amélioration spectaculaire des performances, avec une amélioration de 10 fois facilement obtenue par rapport aux pires moments de votre implémentation actuelle, et des réalisations moindres mais substantielles disponibles pour les performances globales.
• Mise en cache du contenu dynamique et statique – Si vous disposez d'un serveur Web surchargé qui fait également office de serveur d'applications, vous pouvez obtenir des performances 10 fois supérieures aux heures de pointe en mettant en cache uniquement le contenu dynamique. La mise en cache des fichiers statiques peut également améliorer les performances de plusieurs dizaines de milliers de fois.
• Compression des données – L’utilisation de la compression de fichiers multimédias tels que JPEG pour les photos, PNG pour les graphiques, MPEG-4 pour les films et MP3 pour les fichiers musicaux peut considérablement améliorer les performances. Une fois que tous ces éléments sont utilisés, la compression des données texte (code et HTML) peut améliorer les temps de chargement initiaux des pages d'un facteur deux.
• Optimisation SSL/TLS – Les poignées de main sécurisées peuvent avoir un impact important sur les performances. Leur optimisation peut donc conduire à une amélioration de la réactivité initiale pouvant aller jusqu'à deux fois plus, en particulier pour les sites contenant beaucoup de texte. L’optimisation de la transmission de fichiers multimédias sous SSL/TLS n’apportera probablement que de légères améliorations des performances.
• Implémentation de HTTP/2 et SPDY – Lorsqu’ils sont utilisés avec SSL/TLS, ces protocoles sont susceptibles d’entraîner des améliorations progressives des performances globales du site.
• Optimisation des logiciels Linux et des serveurs Web (tels que NGINX) – Des correctifs tels que l’optimisation de la mise en mémoire tampon, l’utilisation de connexions keepalive et le déchargement des tâches chronophages vers un pool de threads distinct peuvent considérablement améliorer les performances ; les pools de threads, par exemple, peuvent accélérer les tâches gourmandes en disque de près d’un ordre de grandeur .

Nous espérons que vous essayerez ces techniques par vous-même. Nous souhaitons connaître le type d’améliorations des performances des applications que vous êtes en mesure d’obtenir. Partagez vos résultats dans les commentaires ci-dessous ou tweetez votre histoire avec les hashtags #NGINX et #webperf !

Ressources pour les statistiques sur Internet

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

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

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