Tests de charge vs tests de résistance
Tests de charge et de stress comparés
Un test de charge, par définition, mesure les performances d’un système sous une charge prévue.
En revanche, un test de résistance surcharge un système pour trouver le point de rupture.
Examen des différences :
Charge vs stress testing
Un test de charge est un test planifié pour effectuer un nombre spécifié de demandes à un système afin de tester la fonctionnalité du système sous des niveaux spécifiques de demandes simultanées. Un test de charge permet de s’assurer qu’un système Web peut gérer un volume de trafic attendu, et est donc parfois appelé test de volume. L’objectif d’un test de charge est de prouver qu’un système peut gérer le volume attendu avec une dégradation minimale à acceptable des performances. Le seuil de dégradation acceptable des performances doit être défini par les testeurs comme une valeur jugée acceptable pour l’utilisateur final afin que les utilisateurs ne rebondissent pas du site.
Un test de résistance est un test conçu pour augmenter le nombre de requêtes simultanées sur un système au-delà d’un point où les performances sont dégradées, même au point de défaillance complète. Lorsqu’un test de charge (ou test d’API) atteindra un pic dans le nombre d’utilisateurs simultanés, un test de contrainte de base continuera d’augmenter la charge sur le système jusqu’à ce que les ressources soient surchargées. Cela pousse le système à un état de défaillance potentielle pour voir comment le système le gère et si le système peut effectuer une récupération gracieuse.
Dans ces définitions d’un test de charge et d’un test de résistance, nous constatons qu’elles ne sont certainement pas complètement indépendantes les unes des autres. Souvent, lorsque vous exécutant les limites supérieures d’un test de charge, vous pouvez effectivement finir par exécuter un test de résistance où vous poussez le système au-delà des limites des ressources disponibles. À ce stade, vous pouvez commencer à voir des défaillances dans un test de charge identiques aux défaillances généralement observées lors de l’exécution d’un test de résistance.
Une différence entre un test de charge et un test de résistance est que vous pouvez injecter des pauses dans un test de charge pour simuler le trafic utilisateur réel. Avec un test de résistance, vous pouvez exécuter autant d’utilisateurs simultanés aussi vite que possible pour générer un trafic excessif pour un test de résistance.
Les objectifs d’un test de charge sont très différents des objectifs d’un test de résistance. Un test de charge est effectué pour s’assurer qu’un site Web, une application Web ou une API est capable de gérer un nombre spécifique d’utilisateurs à la fois. Les tests de charge sont souvent utilisés dans le processus de planification de la capacité, pour s’assurer qu’un système peut gérer la croissance à des niveaux spécifiés de trafic simultané.
Un test de résistance est utilisé pour pousser spécifiquement un système au-delà de sa capacité prévue pour identifier les composants qui commencent à ralentir, identifier les goulots d’étranglement dans le système et mettre en lumière les goulots d’étranglement potentiels ou les points de défaillance.
Les tests de charge sont généralement effectués sous la forme d’une série d’étapes où le système de test lance une quantité d’utilisateurs simultanés qui sont connus pour être pris en charge par l’infrastructure. Cela établit un ensemble de données de référence à référencer au fur et à mesure que le nombre d’utilisateurs simultanés augmente tout au long du test. Le test de performances peut aider à déterminer plusieurs lignes de base différentes, telles que la vitesse de connexion moyenne, la latence moyenne et le temps moyen de téléchargement d’un fichier de taille fixe, etc.
Une fois que les valeurs de performance de base sont connues, le nombre d’utilisateurs est porté à un nombre qui peut être réaliste s’attendre à visiter le site au cours d’une période d’échantillon. Le test s’exécutera souvent à ce nombre statique d’utilisateurs pendant plusieurs minutes pour vérifier la stabilité du site Web une fois que le système se sera stabilisé au nouveau niveau de charge.
Il est important de noter que les termes test de référence et test de référence sont souvent utilisés de manière interchangeable, mais il existe des différences entre ces deux termes. Des tests de base sont effectués pour s’assurer que les performances d’un site ou d’une application ne diminuent pas avec le temps. Par exemple, lors d’un test de référence, les mesures de performance sont enregistrées afin que, lorsque cette application ou ce site est mis à jour à l’avenir, les ingénieurs puissent tester et comparer les nouvelles mesures de performance avec les mesures précédentes. Ces tests de base incluraient également toute nouvelle modification de code, de logiciel, de matériel et de réseau. L’objectif est de fournir une application ou un site cohérent, ce qui garantit une expérience positive pour les utilisateurs.
Les tests de référence consistent à comparer les performances des applications à des normes et exigences spécifiques prédéfinies de l’industrie ou de l’organisation. Comme les tests de base, les tests de référence comprennent la mesure et l’enregistrement des performances du matériel, des logiciels et des conditions réseau. Les tests de référence aident à mesurer la qualité du service pour les propres exigences d’une organisation ou par rapport à d’autres organisations. Ces métriques aident à créer des SLA (Contrats de Niveau de Service) pour les organisations et à fournir un niveau de service garanti aux utilisateurs ou aux clients. En savoir plus sur les tests de référence et de référence.
Une différence entre l’établissement d’une mesure de performance de base lors d’un test de charge et d’un test de contrainte est que la différence entre la performance de base et la performance de pointe vous aidera à déterminer si vous avez les systèmes appropriés en place pour gérer la charge de pointe, tandis que lors d’un test de contrainte, vous êtes plus préoccupé par le point auquel le système devient stressé, ou même cesse de fonctionner correctement.
Tests de charge ou de stress pour identifier les goulots d’étranglement des applications Web
Les applications Web s’exécutent généralement dans un navigateur et lorsqu’elles sont programmées correctement, en raison de leur nature asynchrone, peuvent traiter plusieurs centaines ou milliers d’utilisateurs simultanés. Si vous générez la charge prévue dans la capacité de votre système, les temps de réponse de l’application doivent rester dans les lignes directrices générées. Si vous poussez le système au-delà de ces limites, vous passez dans le domaine des tests de résistance, ce qui entraîne délibérément une pression sur le système pour identifier les composants qui échouent (cela est souvent effectué avec des outils open source comme JMeter). Par conséquent, tout test effectué dans le but d’identifier les goulots d’étranglement est généralement considéré comme un test de résistance (ce qui est différent des tests d’API et de la surveillance des API).
Tests de charge pour établir des accords de niveau de service (AL)
Les tests de charge sont les mieux exécutés dans un environnement de production pour comprendre les temps de réponse moyens sous la charge d’utilisateur prévue. Ces temps de réponse moyens deviennent la base de référence pour les ASS acceptables. De là, c’est à vous de déterminer les seuils supplémentaires qui sont considérés comme inacceptables en vertu de vos SSR en termes de performances attendues pour vos clients.
Test de charge pour la planification de la capacité
Générer une charge accrue sur une application Web peut aider à prédire les performances de l’application pour une charge utilisateur plus lourde à l’avenir. Si l’application répond dans les paramètres de votre SLA, un tel test sera considéré comme un composant réussi dans la planification de la capacité. Si les mesures de performance enregistrées pendant le test sont en dehors des paramètres souhaitables, un test de charge peut devenir un test de résistance lorsque vous poussez le système au-delà de sa capacité disponible.
Infrastructure d’application Web stress testing
L’identification du moment où chaque composant de votre infrastructure échouera est un élément essentiel de la maintenance d’une application Web évolutive. Des tests de contrainte efficaces vous permettent d’isoler chaque composant à l’aide d’une série de tests différents pour déterminer le point de défaillance de ce composant. Ces tests peuvent inclure :
- Isoler tout le trafic vers une région géographique spécifique.
- Limiter artificiellement l’espace disque disponible.
- Envoi répété d’une demande GET particulièrement importante.
- Limiter le nombre maximum de connexions de données.
- Téléchargement d’un fichier d’image grand.
- Envoi répété d’un POST intense qui écrit fortement à une base de données.
Chaque test est conçu pour mettre l’accent sur une composante particulière de l’infrastructure afin d’identifier les points de défaillance, le taux de défaillance et les limites supérieures de la capacité du système. Les tests de résistance peuvent aider à identifier les goulots d’étranglement pendant les brèves charges intenses provenant de choses telles que le marketing viral, la reconnaissance internationale des nouvelles, et les journées d’achats en ligne lourds tels que le Black Friday.
Un test de résistance max out généralement une partie du système ou une autre qui provoque éventuellement des ralentissements, puis des accidents ou des insensibles. Il est important de déterminer quels composants du système seront les premiers à rencontrer des problèmes pendant le test. Pour cette raison, il existe plusieurs composants que nous vous recommandons de surveiller lors de l’exécution d’un test de résistance. Il est à noter que selon l’application, le logiciel ou même la technologie utilisée dans votre environnement/système, les mesures que vous mesurez lors d’un test de résistance peuvent varier.
- Temps de réponse. Il faut du temps pour recevoir une réponse après l’envoi d’une demande. Ceci est particulièrement important pour mesurer les temps de réponse tels que perçus par les utilisateurs
- Contraintes matérielles. Cela inclut la surveillance de l’utilisation du Processeur, ram, disque I/O. Si les temps de réponse sont retardés ou lents, ces composants matériels pourraient être des coupables potentiels.
- Débit. La quantité de données envoyées/reçues pendant la durée du test en fonction de vos niveaux de bande passante.
- Base de données lit et écrit. Si votre application utilise plusieurs systèmes, les tests de résistance peuvent indiquer quel système, ou unité, est le goulot d’étranglement.
- Ouvrez les connexions de base dedonnées . Les grandes bases de données peuvent avoir un impact sévère sur les performances, ralentissant les temps de réponse.
- Contenu tiers. Les pages Web et les applications s’appuient sur de nombreux composants tiers. Les tests de résistance vous montreront ceux qui peuvent avoir un impact sur les performances de votre page ou de votre application.
Si vous n’avez pas de systèmes de surveillance adéquats du côté serveur, la plate-forme Dotcom-Monitor fournit une solution de surveillance des compteurs de performances pour une surveillance complète des performances du serveur de bout en bout. Ces compteurs de performance sont installés directement sur vos serveurs pour surveiller les compteurs de performance Windows, Linux ou SNMP (Simple Network Management Protocol). En outre, il existe également une solution pour surveiller tous les compteurs de performances personnalisés à partir de vos appareils et serveurs. Pour plus d’informations sur la surveillance des compteurs de performances, visitez notre page Solutions de surveillance des compteurs de performances.
Les problèmes liés à l’un ou l’autre de ces éléments pourraient se manifester par :
- Lente réponse du premier paquet.
- Délais importants entre les demandes et les réponses GET/POST.
- Temps de chargement de page plus longs que la normale.
- Calendrier de chargement de la page Web.
- Codes d’erreur serveur retournés.
Bien que ces mêmes problèmes puissent être initialement détectés lors d’un test de charge, l’idée derrière un test de charge est de simuler les charges attendues que le système devrait être en mesure de gérer régulièrement. Parfois, il peut être le cas où le système connaît brièvement des ralentissements tandis que les ressources sont allouées à la charge accrue, mais dans la plupart des cas, le système devrait être en mesure de récupérer de l’allocation initiale et de reprendre les performances normales dans le cadre d’un test de charge.
Si le test de charge continue de détecter les problèmes, vous devez examiner de plus près les compteurs de performances du système pour déterminer la cause profonde du ralentissement ou de la défaillance. C’est à ce moment qu’un test de charge devient un test de contrainte car la charge provoque des problèmes de performances de manière inattendue. Vous voulez en savoir plus? Contactez notre équipe pour une démonstration de la plateforme LoadView. Un ingénieur de performance vous aidera à traverser tout le processus de charge et de stress. Qu’il s’agisse de montrer comment créer des scripts pour des scénarios de page Web ou d’application Web, de configurer et de lancer le test, ils vous guideront tout au long du processus et répondront à toutes les questions que vous pourriez avoir en cours de route.
Notre équipe chez LoadView est disponible pour vous aider, vous et votre équipe de développement, à tirer le meilleur parti de votre processus de test de charge et de stress et de votre budget. En comprenant quand exécuter des tests de charge et de stress respectivement, soutenus par notre plate-forme facile à utiliser et des experts utiles, vous serez en mesure d’intégrer un processus de test intelligent dans votre stratégie DevOps et de fournir rapidement des résultats aux utilisateurs de vos sites Web et applications Web.
Comme pour la plupart des choses dans le paysage numérique en évolution rapide, il est important de tirer parti de l’aide d’experts. Chez LoadView, nous nous concentrons entièrement sur le développement de notre plate-forme leader de l’industrie pour les tests de charge et de résistance. Nous aidons nos clients à se concentrer sur ce qui compte lors des tests de charge : des résultats précis et exploitables qui peuvent être transformés en informations qui entraînent des changements significatifs dans le développement de sites Web et d’applications et l’infrastructure de soutien.
Sans tests de charge et de stress réguliers, vos sites Web et applications risquent de subir une dégradation des performances ou de graves temps d’arrêt. Même si vous êtes à côté de certains que vos sites Web sont à l’épreuve des pannes, des tests appropriés vous aideront, vous et votre équipe de développement, à apporter des améliorations qui peuvent donner encore plus de tranquillité d’esprit et une meilleure expérience à vos utilisateurs du monde entier. Dans le monde en ligne, la vitesse compte. Lorsque vous utilisez LoadView comme plate-forme de test de charge et de stress, vous serez en mesure d’offrir la meilleure expérience possible à vos utilisateurs et d’assurer la disponibilité. Inscrivez-vous pour un essai gratuit de LoadView dès aujourd’hui.
Pas de carte de crédit. Pas d’engagement. Payez au fur et à mesure.