Test de charge vs tests de résistance
Avant d’expliquer comment déterminer le point de rupture de l’application dans la plate-forme LoadView, nous devons d’abord décrire les différences entre un test de charge et un test de contrainte. Bien que les termes soient souvent utilisés de façon interchangeable, ces tests cherchent à trouver des résultats différents.
Un test de charge est un type de test non fonctionnel utilisé pour valider la santé d’un système alors qu’il est soumis à un niveau spécifique de demandes simultanées, également connu sous le nom de charge. L’objectif d’un test de charge est de prouver qu’un système peut gérer un niveau de volume attendu ou acceptable avec un minimum de perturbation ou de dégradation. Les facteurs qui sont utilisés pour créer cette ligne de base de performance sont la vitesse de connexion, la latence et les temps de téléchargement, entre autres. En règle générale, les tests de charge sont effectués pour aider à prédire les performances de l’application dans des limites réalistes, ce qui aide à comprendre comment les performances sont affectées pendant les pics de charge. Si vous poussez le système au-delà de ces seuils, votre test de charge peut devenir par inadvertance un test de résistance.
D’autre part, un test de résistance est conçu pour pousser un système au-delà du point de dégradation, parfois au point d’une défaillance complète. Pousser un système au-delà du point de dégradation ou de défaillance permet aux ingénieurs de voir comment le système gère la récupération de cette défaillance et si oui ou non des changements dans la capacité matérielle sont nécessaires. Certains des facteurs qui sont généralement surveillés lors d’un test de contrainte sont les E/S disque, la bande passante, l’utilisation du processeur, la mémoire et diverses mesures de performances de la base de données.
Calcul de la charge initiale
Déterminer le point de rupture d’une application n’est généralement pas simple comme il semble. Évidemment, si le serveur se bloque, vous avez certainement trouvé ce point, mais il ya d’autres facteurs à considérer, tels que les temps de réponse. De nos jours, si une page Web ou une application ne répond pas en quelques secondes, les utilisateurs vont rebondir. De longs délais de réponse peuvent indiquer que votre demande est en panne. Une autre indication que quelque chose est cassé, c’est que vous commencez à recevoir des commentaires des utilisateurs sur les problèmes de page Web ou votre soutien ou votre équipe de l’IT est notifié par des billets de problèmes.
Tout d’abord, considérez le nombre de vos serveurs Web en cours d’utilisation et le nombre de cœurs CPU disponibles. Pour cet exemple, nous supposerons que nous travaillons avec un serveur Web quad-core et que nous utiliserons un point de départ de 25 utilisateurs simultanés par cœur de processeur, donc 100 utilisateurs simultanés . Cependant, il est recommandé de commencer avec le nombre 50 pour cent inférieur à un point de départ calculé, de sorte que fonctionne à 50 utilisateurs simultanés. À partir de ce point de départ, et en fonction des exigences de performances de l’application, vous pouvez augmenter la charge à 5x ou 10x de plus.
Choisir une courbe de charge : la plate-forme LoadView
La plate-forme LoadView offre aux utilisateurs la possibilité de choisir parmi trois options de courbe de charge différentes.
- Courbe d’étape de charge. Le type d’essai permet de comparer les temps de réponse sous la charge opérationnelle et sous la charge de trafic prévue.
- Courbe basée sur les objectifs. Ce test est utile lorsque vous avez déjà un débit prédéterminé (objectif de transaction), ou le nombre de visiteurs que vous attendez sur votre site web pendant un intervalle de temps fixe et que vous voulez vous assurer que le site répond aux exigences.
- Courbe réglable dynamique. Vous pouvez utiliser ce type pour connaître les limites de performances du site ou pour planifier la capacité de son serveur en modifiant manuellement le trafic utilisateur pendant le test.
Pour les besoins de cet exemple, nous recherchons à déterminer le point de rupture d’une application, et nous ne travaillons pas avec un objectif de débit ou de transaction prédéterminé, de sorte que nous n’envisagerons pas l’option de courbe basée sur les objectifs. Avec le test de courbe réglable dynamique, vous pouvez augmenter le trafic jusqu’à ce que vous trouviez le point de rupture, ou avec la courbe de pas de charge, vous pouvez définir les taux de montée en puissance jusqu’à ce que vous trouviez ce point de rupture.
Un autre facteur à prendre en considération est le temps d’exécuter la transaction. Une fois que votre dispositif de test de résistance a été créé, cette valeur peut être trouvée dans le rapport performance suivant le processus de validation. Par exemple, si le temps d’exécution de la transaction est d’environ 30 secondes, vous voudrez maintenir la charge pendant le double de ce temps, en vous assurant que la transaction se termine, même si le temps de réponse augmente.
Trouver le point de rupture de la demande
Vous trouverez ci-dessous les résultats d’un test de contrainte HTTP de base, utilisant une courbe de pas de charge, avec une charge initiale de 12 utilisateurs par minute.
Comme vous pouvez le voir dans les zones mises en surbrillance en jaune, il ya une augmentation des temps de réponse et le nombre d’erreurs que le nombre d’utilisateurs est augmenté au fil du temps. Selon les exigences de l’application, à tout moment où des erreurs se produisent, cela pourrait être considéré comme le point de rupture. Ou dans les cas où le temps de réponse est de la plus haute importance, le point de rupture de l’application peut être lorsque le temps de réponse dépasse le seuil prédéfin défini.
Pour plus d’informations sur l’exécution des tests de résistance au sein de la plate-forme LoadView, veuillez visiter notre base de connaissances.