introduction
À mesure que les sites Web et les applications Web deviennent de plus en plus riches et complexes, les performances deviennent une préoccupation majeure pour les développeurs et les utilisateurs. Avec studies, qui montre que des sites plus rapides entraînent plus d’utilisateurs engagés, plus de ventes et un trafic accru, il est important de faire attention à la rapidité avec laquelle vous pouvez livrer votre site à vos utilisateurs et le rendre restitué. leur navigateur.
Le terme général pour ce domaine de connaissances est «optimisation des performances Web» et, au cours des dernières années, de nombreuses meilleures pratiques, techniques et technologies ont été développées pour améliorer l’expérience Web. Bon nombre de ces techniques sont axées sur la réduction de la taille de téléchargement des pages Web, l’optimisation de JavaScript et la limitation du nombre de requêtes HTTP individuelles nécessaires à une page.
Dans cet article, nous allons parler de l’autre côté des performances Web: à quelle vitesse votre serveur peut-il répondre aux demandes de vos utilisateurs? Nous allons passer en revue le paysage général des tests de charge, passer en revue un plan pour trouver le taux de réponse pratique maximum de votre serveur et discuter de certains logiciels de test de charge open source.
Glossaire
Avant de commencer, clarifions certains termes et concepts pertinents:
-
* La latence * est une mesure de la * rapidité * d’un serveur à répondre aux demandes du client. Généralement mesurée en millisecondes (ms), la latence est souvent appelée * temps de réponse *. Les chiffres plus bas indiquent des réponses plus rapides. La latence est mesurée côté client, à partir du moment où la demande est envoyée jusqu’à la réception de la réponse. Les frais généraux du réseau sont inclus dans ce numéro.
-
* Le débit * est * le nombre de requêtes * que le serveur peut traiter pendant un intervalle de temps spécifique, généralement indiqué comme * requêtes par seconde *.
-
Les * centiles * permettent de regrouper les résultats en fonction de leur pourcentage dans l’ensemble de l’échantillon. Si votre temps de réponse au 50e centile est de 100 ms, cela signifie que 50% des demandes ont été renvoyées en 100 ms ou moins. Le graphique ci-dessous montre pourquoi il est utile de regarder vos mesures en centiles: + image: https: //assets.digitalocean.com/articles/load-testing/p99.png [Un exemple de graphique de latence en fonction de temps, montrant un pic important dans le 99e centile] + Le graphique ci-dessus montre la latence d’un serveur Web sur une période donnée. Même si le temps de réponse moyen (moyen) est relativement cohérent, la pointe du 99e centile est en forte hausse. Cela signifie que 1% des demandes de nos utilisateurs ont été pires que cette mesure du 99e centile, alors que la moyenne est restée relativement stable. C’est pourquoi il est utile d’examiner les centiles pour avoir une idée plus précise de ce que vivent réellement vos utilisateurs.
Notions de base sur les tests de charge
Le test de charge consiste à envoyer un trafic HTTP simulé à un serveur afin de mesurer les performances et de répondre à certaines questions importantes, telles que:
-
Le serveur dispose-t-il de suffisamment de ressources (processeur, mémoire, etc.) pour gérer la charge prévue?
-
Le serveur répond-il assez rapidement pour offrir une bonne expérience utilisateur?
-
Notre application fonctionne-t-elle efficacement?
-
Avons-nous besoin de faire évoluer notre matériel de serveur ou de passer à plusieurs serveurs?
-
Y a-t-il des pages ou des appels d’API qui nécessitent des ressources importantes?
Le test de charge est effectué en exécutant un logiciel de test de charge sur un ordinateur (ou un cluster de machines) afin de générer un grand nombre de demandes adressées à un serveur Web sur un deuxième ordinateur (ou une autre infrastructure de service Web plus complexe). Il existe de nombreux outils de ce type, et nous examinerons ultérieurement un logiciel spécifique. Pour l’instant, nous discuterons des tests de charge en termes pertinents, quel que soit le logiciel choisi.
Le logiciel de test de charge utilise couramment le * nombre maximal de demandes par seconde * qu’un serveur peut gérer. Ceci est fait en envoyant autant de requêtes que possible à un serveur et en voyant combien de requêtes peuvent être renvoyées avec succès.
C’est utile dans un premier temps pour comprendre la capacité maximale de votre serveur, mais cela ne nous donne pas beaucoup d’informations sur la latence et les performances quotidiennes que vos utilisateurs vont expérimenter. Un serveur très chargé peut être capable de renvoyer mille réponses par seconde, mais si chaque réponse prend dix secondes, vos utilisateurs seront probablement mécontents.
Le graphique ci-dessous illustre la relation entre le débit (réponses par seconde) et la latence:
image: https: //assets.digitalocean.com/articles/load-testing/latency2.png [Un exemple de graphique de la latence en fonction de demandes, montrant une corrélation positive entre les deux]
Ce n’est qu’un exemple, et chaque configuration aura un profil de réponse unique, mais la tendance générale est qu’une charge plus élevée (plus de demandes par seconde) entraîne une latence plus élevée. Pour avoir une idée plus concrète de la latence de notre serveur à une charge donnée, nous devons effectuer plusieurs tests à différentes vitesses. Tous les logiciels de test de charge ne sont pas capables de cela, mais nous verrons plus tard + wrk2 +, un outil de test de charge en ligne de commande capable d’exécuter cette fonction.
Maintenant que nous avons une compréhension générale des tests de charge, discutons d’un plan spécifique pour explorer les performances de notre serveur.
Un plan de test de charge
Vous pouvez suivre quelques étapes générales pour avoir une idée de la performance et de la performance de votre serveur et de votre application Web. Premièrement, nous allons nous assurer de surveiller les bonnes ressources système pendant le test de charge. Ensuite, nous découvrirons le nombre maximum absolu de requêtes par seconde dont notre serveur est capable. Enfin, nous trouverons le débit maximal auquel la latence de notre serveur entraînerait des performances inacceptables pour nos utilisateurs.
Étape 1 - Surveillance des ressources
Notre logiciel de test de charge nous fournira des informations sur les demandes et la latence, mais il est utile de surveiller d’autres métriques système pour voir si le serveur devient soumis à des contraintes de ressources lorsqu’il traite de gros volumes de trafic.
Nous nous intéressons principalement à la charge du processeur et à la mémoire disponible: les surveiller alors que vous êtes sous une charge importante vous aidera à prendre des décisions plus éclairées sur la manière de redimensionner l’infrastructure et de concentrer les efforts lors du développement de votre application.
Si vous avez déjà configuré un système de surveillance (tel que Prometheus ou Graphite and CollectD) vous êtes tous ensemble. Sinon, connectez-vous à votre serveur Web via SSH et utilisez les outils de ligne de commande suivants pour effectuer un contrôle en temps réel.
Pour vérifier la mémoire disponible, vous pouvez utiliser la commande + free +. Combinez-le avec + watch + pour mettre à jour périodiquement (toutes les deux secondes par défaut) la sortie:
watch free -hL’indicateur + -h + indique à + free + de générer les nombres dans un format lisible par l’homme au lieu d’octets:
Output total used free shared buffers cached
Mem: 489M 261M 228M 352K 7.5M 213M
-/+ buffers/cache: 39M
Swap: 0B 0B 0BLe nombre en surbrillance dans la sortie ci-dessus représente la mémoire disponible après soustraction de la mémoire tampon et de l’utilisation du cache. Les versions les plus récentes de + free + ont modifié la sortie:
Output total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M
Swap: 0B 0B 0BLa nouvelle colonne + available + est calculée légèrement différemment, mais représente généralement la même mesure: mémoire actuellement disponible pour les applications.
Pour contrôler l’utilisation du processeur à partir de la ligne de commande, mpstat est un bon utilitaire offrant une vue de mise à jour de la quantité de ressources de processeur inutilisées. mpstat n’est pas installé par défaut sur Ubuntu. Vous pouvez l’installer avec la commande suivante:
sudo apt-get install sysstatLorsque vous lancez + mpstat +, vous devez lui indiquer le nombre de secondes que vous souhaitez entre les mises à jour:
mpstat 2Cela produira une ligne d’en-tête, puis une ligne de statistiques toutes les deux secondes:
OutputLinux 4.4.0-66-generic (example-server) 08/21/2017 _x86_64_ (4 CPU)
08:06:26 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00+% inactif + nous indique le pourcentage de ressources CPU non utilisées. La raison pour laquelle nous examinons combien est * inactif * au lieu de * utilisé * est parce que l’utilisation du processeur est souvent divisée en différentes catégories telles que * utilisateur * processeur et * système * processeur. Au lieu de les additionner à la volée, nous examinons le côté inactif de l’équation.
Maintenant que nous pouvons observer les ressources de notre serveur, effectuons un test de charge initial pour trouver le taux de réponse maximal de notre serveur.
Étape 2 - Trouver le taux de réponse maximal
Comme mentionné précédemment, la plupart des logiciels de test de charge sont particulièrement bien adaptés pour rechercher le taux de réponse maximal de votre serveur Web. Souvent, les seules options que vous devez définir sont la devise souhaitée et la durée du test.
La simultanéité est une mesure du nombre de connexions parallèles établies sur le serveur. 100 est un choix par défaut sûr, mais vous pouvez faire un choix plus éclairé en vérifiant les paramètres + MaxClients +, + MaxThreads + de votre serveur Web, ou des paramètres similaires, pour déterminer le nombre de connexions simultanées qu’il peut gérer.
En plus de définir ces options, vous devrez choisir une URL à utiliser pour le test. Si votre logiciel ne peut gérer qu’une seule URL à la fois, il est intéressant de faire plusieurs tests avec quelques URL différentes, car les exigences de traitement peuvent varier considérablement entre, par exemple, votre page d’accueil et une page de produit nécessitant le chargement de plusieurs requêtes de base de données. .
Certains logiciels de test de charge vous permettent également de spécifier plusieurs URL à tester simultanément. C’est un bon moyen de simuler avec plus de précision le trafic dans le monde réel. Si vous disposez de données d’utilisation du site (provenant de logiciels d’analyse ou de journaux de serveur), vous pouvez faire correspondre les URL de test aux valeurs observées.
Une fois que vous avez sélectionné l’URL ou les URL à tester, exécutez le test de charge. Assurez-vous que votre logiciel envoie les demandes le plus rapidement possible. Si vous utilisez un logiciel nécessitant que vous choisissiez le taux de requête, choisissez une valeur presque certaine d’être trop grande. Si votre logiciel a un délai configurable entre les demandes, réduisez-le à zéro.
Vous devriez voir vos ressources de processeur et de mémoire consommées. Votre processeur inactif peut atteindre 0% et votre client de test de charge peut recevoir des erreurs de connexion car votre serveur a du mal à suivre toutes les demandes. C’est normal, car nous poussons le serveur à ses limites.
Lorsque tout est terminé, votre logiciel génère des statistiques, notamment * demandes par seconde *. Notez également le * temps de réponse *: il sera probablement très faible, car le serveur aurait dû être extrêmement étendu. De ce fait, le nombre de requêtes par seconde n’est pas un bon indicateur du débit maximal réel de votre serveur, mais c’est un bon point de départ pour une exploration plus approfondie.
Ensuite, nous allons rappeler la charge et tester à nouveau pour obtenir plus d’informations sur le fonctionnement de notre serveur quand il n’est pas poussé à fond.
Étape 3 - Trouvez le débit maximal pratique
Pour cette étape, nous devons utiliser un logiciel de test de charge capable de réduire légèrement la charge afin de tester les performances de notre serveur à différents niveaux de débit. Certains logiciels le font en vous permettant de spécifier un délai entre chaque demande, mais il est difficile de cibler un débit précis.
Heureusement, + wrk2 + vous permet de spécifier une cible exacte par seconde. Pour ce faire, il lance d’abord quelques requêtes d’étalonnage afin d’obtenir son timing juste.
Prenez votre taux de demande maximum de l’étape précédente et coupez-le en deux. Exécutez un autre test à ce nouveau taux et notez le temps de réponse. Est-il toujours dans la fourchette acceptable?
Si tel est le cas, ramenez le taux au maximum et testez-le jusqu’à ce que votre latence atteigne la valeur maximale que vous avez déterminée d’être acceptable. Il s’agit du taux de réponse maximal actuel que votre serveur peut gérer avant que vos utilisateurs ne subissent une dégradation des performances.
Nous examinerons ensuite certains packages logiciels open-source disponibles pour nous aider à mettre en œuvre notre plan de test de charge.
Logiciel de test de charge
Il existe de nombreux packages logiciels open source disponibles pour les tests de charge. En outre, de nombreux services commerciaux exécuteront une infrastructure de test de charge et créeront automatiquement des graphiques et des rapports à partir des données de test. Ces services pourraient constituer un bon choix pour les entreprises qui doivent générer une charge de travail importante pour tester une infrastructure à grande échelle, car la plupart d’entre elles exécutent des grappes de machines afin de générer beaucoup plus de demandes qu’un serveur unique.
Cela dit, certains outils open source sont également capables de fonctionner en mode cluster. Parcourons quelques-uns des outils open source les plus populaires et résumons leurs fonctionnalités:
ab
ab (également connu sous le nom d’ApacheBench) est un outil de ligne de commande simple à un seul thread permettant de comparer un serveur HTTP. Bien qu’il ait été initialement distribué avec le serveur HTTP Apache, vous pouvez utiliser ab pour tester n’importe quel serveur HTTP ou HTTPS.
Comme il n’existe qu’un seul thread, l’ab ne peut pas tirer parti de plusieurs processeurs pour envoyer un grand volume de demandes. Cela peut être limitant si vous essayez de charger complètement un serveur Web puissant.
Une invocation de base de la commande + ab + ressemble à ceci:
ab -n 1000 -c 100Vous spécifiez le nombre de demandes (+ -n +) et la concurrence (+ + c +) », puis vous lui donnez une seule URL à extraire. Le résultat - extrait ci-dessous - contient le nombre de requêtes par seconde, le temps de requête et une liste de différents centiles de temps de réponse:
Output. . .
Time per request: 1.361 [ms] (mean, across all concurrent requests)
Transfer rate: 60645.11 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)JMeter
JMeter est un test de charge et une application de test fonctionnel fonctionnels et riches en fonctionnalités d’Apache Software Foundation. Les tests fonctionnels signifient que JMeter peut également tester pour vous assurer que votre site Web ou votre application produit le bon résultat.
JMeter a une interface graphique Java pour configurer Test Plans:
image: https: //assets.digitalocean.com/articles/load-testing/jmeter.png [L’interface par défaut de JMeter]
Les plans de test peuvent être enregistrés à l’aide du proxy Web d’enregistrement du trafic de JMeter et d’un navigateur classique. Cela vous permet de tester avec un trafic qui simule de plus près une utilisation réelle.
JMeter peut générer des informations sur les centiles dans les rapports HTML et autres formats.
Siege
Siege est un autre outil de test de charge en ligne de commande, similaire à ab mais avec quelques fonctionnalités différentes. Siege est multithread, ce qui permet un débit relativement élevé. Il vous permet également de fournir une liste de plusieurs URL à tester en charge. Une invocation de base suit:
siege -c 100 -t 30sCela appelle 100 demandes simultanées (+ -c 100 +) et un test de trente secondes (+ -t 30s +). Siege génère le temps de réponse moyen et le taux de requête:
Output. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .Siege ne fournit aucune ventilation en centiles pour ses statistiques de latence.
Locust
Locust est un outil de test de charge basé sur Python avec une interface utilisateur Web en temps réel permettant de surveiller les résultats:
image: https: //assets.digitalocean.com/articles/load-testing/locust.png [La page des résultats du test acridien]
Vous écrivez des scénarios de test Locust dans le code Python, ce qui permet une configuration puissante, pratique pour ceux qui sont déjà familiarisés avec le langage.
Locust peut également être exécuté en mode distribué, où vous pouvez exécuter un cluster de serveurs Locust et leur demander de produire leur charge de manière coordonnée. Cela facilite les tests de charge de la puissante infrastructure de service Web.
Locust peut fournir des statistiques détaillées et des informations sur les pourcentages dans des fichiers CSV téléchargeables.
wrk2
wrk2 est un outil de test de charge de ligne de commande multi-thread capable de produire une charge à un taux de requêtes spécifié. Il peut fournir des statistiques détaillées sur la latence et est scriptable avec le langage de programmation Lua.
wrk2 est appelé avec la commande + wrk + (c’est un fork de l’original '+ wrk + `):
wrk -t4 -c100 -d30s -R100 --latencyLes options ci-dessus spécifient quatre threads (+ -t4 +, vous devez utiliser le nombre de cœurs de processeur sur votre ordinateur), 100 requêtes simultanées (+ -c100 +), une période de test de trente secondes (+ -d30s +), et un taux de demande de 100 demandes par seconde (+ -R100 +). Enfin, nous demandons une sortie de latence détaillée avec + - latency +:
Output. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000% 5.79ms
75.000% 7.58ms
90.000% 10.19ms
99.000% 29.30ms
99.900% 30.69ms
99.990% 31.36ms
99.999% 31.36ms
100.000% 31.36ms
. . .La sortie ci-dessus est un extrait - des centiles de latence plus détaillés sont également imprimés.
Conclusion
Dans cet article, nous avons passé en revue une terminologie de test de charge et des concepts de base, présenté un plan visant à déterminer le nombre maximal de demandes pratiques par seconde, observé les ressources système observées afin de guider les décisions futures concernant le matériel et les efforts de développement, et examiné certaines des sources ouvertes disponibles. logiciel de test de charge.
Après avoir mesuré les performances de votre infrastructure, vous souhaiterez peut-être utiliser ces informations pour améliorer les temps de réponse et réduire la charge du serveur. Vous souhaiterez peut-être mettre à l’échelle votre matériel de serveur Web ou utiliser plusieurs serveurs et un équilibreur de charge. Vous pouvez essayer d’affiner la configuration de votre serveur Web pour optimiser le nombre de connexions qu’il autorise ou le nombre de processus de travail ou de threads qu’il utilise. Vous pouvez également envisager de mettre en mémoire cache les données fréquemment consultées afin de réduire la charge de la base de données et le temps d’interrogation.
Vous trouverez les rubriques ci-dessus et plus encore à l’adresse notre collection de tutoriels marqués * Optimisation du serveur *].