Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Types de test de charge
Les types de test suivants sont basés sur les questions fondamentales répertoriées plus haut dans le guide.
Quelle charge mon application peut-elle supporter ?
Lorsque vous configurez un test pour déterminer la charge que votre application peut supporter, déterminez d'abord si vous souhaitez mesurer le nombre de demandes par seconde (req/s), le temps de réponse (secondes) ou le nombre d'utilisateurs simultanés. Dans les deux cas, définissez la partie de l'application qui est testée.
-
La navigation sur le site est une charge qui est atteinte en visitant un certain nombre de pages ou de points de terminaison, ou en demandant des données à un seul point de terminaison en utilisant des paramètres différents pour chaque demande. Vous pouvez souvent y parvenir en utilisant les outils de base indiqués dans la section Outils à utiliser. Le cache étant souvent un composant essentiel d'une application, décidez si vous souhaitez inclure une couche de mise en cache dans le test.
-
Les tests de flux de travail transactionnels, tels qu'un contrôle où les demandes dépendent les unes des autres et transfèrent des données entre les demandes, requièrent des outils plus complexes. De plus, comme la mesure des demandes a une pertinence limitée dans le contexte d'une transaction en plusieurs étapes, il est plus précis de compter l'ensemble de la transaction, qui doit être émise sous forme de point de données distinct par l'outil. Les outils Apache JMeter et k6 peuvent être configurés pour fournir ces points de données.
Définissez le seuil acceptable pour les performances et le taux d'erreur de votre système cible. Pour certains systèmes, les temps de réponse peuvent ne pas vous intéresser tant que l'événement est correctement traité. Pour de nombreuses applications, telles que celles impliquant une interaction avec l'utilisateur, définissez des limites de ce qui est acceptable pour l'utilisateur final.
Il est souvent utile d'effectuer les tests par étapes. La charge augmente à chaque étape jusqu'à ce que vous atteigniez le seuil défini. Pour les tests répétés, vous pouvez tirer des leçons des tests précédents et améliorer votre définition d'étapes pour effectuer moins d'étapes lors d'un test tout en obtenant toujours des résultats valides.
Mon application peut-elle supporter une charge X ?
Comme pour le test précédent, la charge de ce test peut être définie en tant qu'utilisateurs simultanés req/s ou en tant qu'utilisateurs simultanés, en fonction de la nature de l'application que vous testez. Ce test est une version simplifiée du précédent. Ici, une charge de travail spécifique doit être soumise et le système doit être en mesure de la gérer. Il est important de choisir un outil de test qui prend en charge la spécification du volume de charge dont vous avez besoin.
L'heure d'exécution du test peut également être pertinente. Certains effets ne peuvent être observés que lorsqu'un test est effectué sur une plus longue période. Par exemple, la pression de retour peut entraîner une surcharge des files d'attente. Si vous souhaitez reproduire un système de production et tirer des conclusions convenables, le temps nécessaire pour exécuter le test peut affecter le dimensionnement du système de test.
Mon application est-elle automatiquement augmentée ou réduite ?
L'élasticité est l'un des principaux arguments de vente du cloud et constitue une source essentielle de réduction des coûts. Dans le cadre de votre transition vers le cloud, vous devez vérifier si votre application se met correctement à l'échelle, afin que vous puissiez bénéficier de son élasticité en toute confiance.
Les métriques clés utilisées pour augmenter ou réduire doivent être identifiées. Il s'agit généralement de la charge du processeur des systèmes cibles. Un point de terminaison qui crée une charge de processeur peut être utilisé comme cible.
Comme ce test ne nécessite pas de représentabilité, vous pouvez tirer parti du ciblage d'un point de terminaison exempt d'effets secondaires. Vous ne souhaitez pas non plus lancer un flux qui conserve les données susceptibles de s'accumuler, ou qui initie des processus ultérieurs et entraîne des coûts inutiles ou bloque la charge.
Effectuez le test par étapes, en augmentant progressivement la charge. Les intervalles doivent être suffisamment longs pour que les métriques puissent initier la mise à l'échelle à chaque étape. Par exemple, si vous avez pour règle selon laquelle la charge du processeur doit être supérieure à 70 % sur une période de 5 minutes, vos étapes doivent durer plus de 5 minutes afin de laisser le temps à l'événement de mise à l'échelle d'être initié et exécuté. Vous souhaitez également constater que la mise à l'échelle fonctionnait et qu'elle a corrigé la situation de charge que vous avez créée.
Envisagez de commencer votre test de mise à l'échelle avec plusieurs serveurs. Dans un environnement restreint, la mise à l'échelle peut être lente et nécessiter plusieurs cycles pour faire face à la charge. En outre, la taille d'un cluster EC2 Auto Scaling ne peut que doubler. Cela signifie que si vous commencez par un serveur et que vous lancez le test de charge, le premier événement de mise à l'échelle maximal ne peut être que de deux serveurs. Si la charge générée nécessitait trois serveurs, vous auriez besoin de deux événements de mise à l'échelle, ce qui peut prendre 20 minutes ou plus.
Surveillez le déclencheur souhaité pour l'événement d'augmentation et vérifiez si la mise à l'échelle était adaptée à la charge réelle.
Si vous avez implémenté un événement de réduction, vous pouvez également le tester par étapes. Vérifiez si la réduction est applicable et adaptée à la charge existante, et vérifiez qu'elle ne déclenche pas une nouvelle augmentation immédiate.
Le comportement de mon application se dégrade-t-il au fil du temps avec une charge constamment élevée ?
Certains effets ne peuvent être observés que lorsque la charge est générée sur une période prolongée. L'un des effets les plus importants est la pression de retour. Cela signifie que lorsqu'un système est trop lent pour traiter le nombre de demandes à la vitesse à laquelle elles arrivent, les performances de ses systèmes clients se dégradent.
Cela est plus facile à observer si le système lent est la cible de charge. Dans une configuration plus complexe, vous ne pouvez observer l'effet que lorsque l'impact du test de charge se propage. Une solution de suivi capable de visualiser les temps de réponse entre chacun des services d'un système distribué affiche non seulement les résultats plus rapidement, mais peut également contribuer à identifier le système qui agit comme un goulot d'étranglement. Vous pouvez identifier le système de goulot d'étranglement en obtenant l'ID de corrélation des messages dans les fichiers journaux. Chaque demande conserve le même ID sur tous les systèmes soumis au test de charge.
L'utilisation d'un identifiant de corrélation vous permet de suivre l'intégralité du parcours d'un message unique à travers les différents composants de votre plateforme. Grâce à ces informations, vous pouvez calculer le temps de traitement pour chaque composant traversé par votre message (processing_time = departure_time - arrival_time) et identifier le plus lent. Zipkin
Pour obtenir les résultats les plus fiables, choisissez un outil qui permet de définir un taux de demandes constant. Cela signifie que si le système cible ralentit, la simultanéité de l'outil de test doit augmenter ou rester req/s constante. Lorsque le système commence à répondre plus lentement, il accapare davantage de threads et réduit le taux de demandes de votre outil de génération de charge. Un outil dont le taux de demandes est constant doit augmenter la simultanéité lorsque cela se produit, et vous constaterez une défaillance plus rapidement. Au lieu de mesurer la dégradation en fonction du taux de req/s obtenu, vous mesurerez en fonction de la latence et même des demandes ayant échoué.
Mon application fonctionne-t-elle ?
En général, vous ne créez pas une charge élevée, mais plutôt un nombre raisonnable de demandes qui vérifient les fonctionnalités. Vous pouvez également le faire périodiquement par rapport à la production, lorsque les clients ne consultent pas les flux testés, afin de disposer d'un niveau de surveillance supplémentaire.
En guise de raccourci, les scénarios déjà créés pour les tests de charge peuvent être réutilisés en production en configurant une charge plus faible.
