Qu’est-ce que le load testing ?

Dans le domaine de l’ingénierie logicielle, le load testing (ou test de charge en français) est un processus dans lequel les performances d’une application sont testées face à différents scénarios de montée en charge. En d’autres termes, il s’agit de modéliser l’accès à une application par un grand nombre d’utilisateurs de manière concurrentielle et sur une période de temps donnée.

L’objectif principal de ce type de test est de mesurer la qualité de service d’une application face à une forte affluence et d’en déterminer les indices de performances en termes de fiabilité, stabilité, temps de réponse et scalabilité.

Différents types de test

Il existe en effet plusieurs types de test de charge, chacun fournissant des informations différentes sur l’état d’une application, au regard des performances. Il est ainsi primordial de déterminer ses besoins par rapport à son marché et aux attentes de ses clients.

• Load testing : ce test de charge permet simplement l’évaluation des performances du système sous une charge dite classique. On l’utilise généralement dans le but de mesurer l’évolution des performances entre chaque nouveau déploiement par exemple.

• Stress testing : le but de ce test est d’identifier les limites du système et comment celui-ci se comporte sous des conditions « extrêmes » d’utilisation, généralement en augmentant graduellement la charge au cours du test. Cela permet de déterminer comment l’expérience utilisateur va en être affectée (retour en erreur, temps de réponse aberrant, crash du système, …), quelle ressource sera le point de rupture mais surtout si le système sera capable de revenir dans un état stable sans intervention externe le cas échéant.

• Spike testing : il s’agit d’une variation du stress test présenté précédemment. En revanche, au lieu d’augmenter la charge de manière continue, on applique une charge extrême sur une très courte période de temps. Cela permet de déterminer comment le système va se comporter face à une surcharge soudaine du trafic et s’il sera capable de se rétablir une fois la charge revenue dans un état « normal ».

• Soak testing : le problème avec les tests précédents dits « standards » est leur durée d’exécution. Lancés sur une période de temps limité, il peut être difficile de couvrir tous les usages et toutes les situations que peut rencontrer une application réelle, disponible le plus souvent 24h sur 24 et 7 jours sur 7. Pour ces raisons, ce genre de test est souvent exécuté sur des périodes allant de quelques heures à plusieurs jours dans certains cas. Le but du soak testing est donc de mettre en lumière d’éventuelles dégradations de performances qui n’apparaitraient que sur de longues périodes d’activité. On pourrait citer :
  • Dégradation des ressources systèmes : fuite mémoire, espace disque disponible, utilisation CPU
  • Processus périodiques pouvant altérer les performances momentanément
  • Services externes à l’arrêt une fois une limite de requêtes atteinte
  • …

Dans quels cas mettre en place ce type de tests ?

Au déploiement d’une nouvelle application, suite à l’ajout d’un nouveau service, après une migration logicielle ou en amont d’une période de forte affluence attendue, les raisons peuvent être nombreuses. Dans tous les cas, il est nécessaire de savoir si les performances d’une application vont en être affectées, et le cas échéant dans quelle mesure afin d’éviter d’éventuels goulots d’étranglement.

Azure load testing

Azure Load Testing est un service managé d’Azure permettant de créer des tests de charge à grande échelle. Celui-ci permet de simuler le trafic d’une application afin d’extraire différents indicateurs de performance et l’état de santé global d’une application.

Comme on peut l’attendre d’un service natif Azure, la mise en place de ce type de test peut se faire très facilement directement depuis le portail Azure.

Du fait de son intégration avec les différentes composantes applicatives et ressources Azure, les résultats sont traités par Azure Monitor et les métriques affichées dans un tableau de bord.

L’ensemble de ce processus peut être automatisé et industrialisé grâce à son intégration dans les pipelines de CI/CD (Azure Pipelines ou Github Actions) et ce à différents stades significatifs du cycle de vie de développement.

Azure Load Testing permet en outre de configurer des règles d’échec et/ou de réussite et ainsi de prévenir de potentielles régressions de performances. Parmi ces règles, on peut par exemple définir :

• Un taux limite d’échec des appels à certains points de terminaison
• Un temps de réponse moyen maximal
• …

Créer et configurer un test de charge

Dans la suite de cet article, nous allons présenter les différentes étapes pour créer et configurer un test de charge sur un projet initié pour l’occasion et analyser les résultats obtenus.

Présentation du projet

Contexte fonctionnel

Back office d’une compagnie d’assurance destiné au suivi des dossiers clients, accessible par l’ensemble des conseillers et managers du groupe.

Contexte technique

Ressources créées dans Azure :

• Un service plan dans lequel une Web app a été déployée : API Web ASP.NET Core 6
• Une base Azure Cosmos DB

Contexte du test de charge

Nous allons mettre en place un test de charge de type Stress Testing.

Notre intention ici est de déterminer si le système est capable de maintenir un niveau de performance optimal en simulant un nombre d’appels croissant avant d’atteindre un palier. Cela permet de modéliser une journée type d’utilisation du système avec une demande croissante avant de maintenir une charge stable.

Création du test de charge

Il existe deux manières de créer un test de charge depuis le service Azure.

A – Test rapide :

La création d’un test de charge peut se faire très rapidement depuis le portail. Le service Azure simplifie le processus et permet de déployer ses tests en quelques clics seulement.

Sur la page d’accueil de notre ressource, onglet « Vue d’ensemble », il nous faut sélectionner « Test rapide ».

Sur la page suivante, le service nous propose de renseigner plusieurs paramètres qui serviront à exécuter notre test.

• Test URL : le point de terminaison de l’API que l’on souhaite tester

• Number of virtual users : il s’agit du nombre fictif d’utilisateurs que l’on souhaite faire requêter notre URL (100 utilisateurs virtuels dans notre cas de test)

• Test duration : la période durant laquelle le test va s’exécuter (30 minutes ici)

• Ramp up time : le temps que l’on alloue au système pour atteindre le nombre d’utilisateurs virtuels renseignés plus haut (dans cet exemple, le système va graduellement ajouter des utilisateurs virtuels pour atteindre le nombre défini – 100 –  et ce en 15 minutes avant d’atteindre un palier pendant les 15 dernières minutes d’exécution du test)

B – Création d’un test à partir d’un script JMeter

Sur la page principale de la ressource, sélectionner le bouton « Créer » associé au test à partir d’un script JMeter, comme indiqué sur l’image ci-dessous.

La configuration du test s’effectue ensuite sur plusieurs étapes.

Basics : Informations générales du test (libellé et description)

Test plan : Sélection du script JMeter

À cette étape nous pouvons charger le script contenant la configuration de notre test. Nous avons gardé les mêmes paramètres que ceux renseignés dans le cas du test rapide.

Load : Configuration du nombre d’instances de moteur de test

Il s’agit du nombre d’instances responsabilisées pour l’exécution du test, de manière parallèle. Dans le cas de notre Test Plan, augmenter le nombre d’instances à 4 (par exemple) reviendrait à exécuter un total de 400 threads : 4 instances * 100 threads (utilisateurs virtuels). Pour notre test nous allons rester sur une seule instance d’exécution.

Test criteria : Définition des critères de validation/échec du test de charge

Cette étape permet de définir des critères d’acceptation afin de déterminer si le test est en échec ou non. Plusieurs critères peuvent ainsi être appliqués sur chaque métrique disponible.

Monitoring : Sélection des ressources à surveiller

Azure Load Testing nous permet de sélectionner les ressources que l’on souhaite superviser lors de l’exécution de notre test. Ici, nous avons choisi d’inclure notre Service Plan et l’App Service ainsi que la base Azure Cosmos DB.

Validation

Une fois que la configuration est terminée, nous pouvons créer notre test de charge. Azure va initialiser les ressources nécessaires et exécuter notre test.

Un Dashboard s’affiche alors à l’écran avec l’ensemble des métriques associées au test en temps réel.

Résultat

Quelles sont les informations mises à disposition et que peut-on en conclure sur les performances globales de notre application à la suite de ce test ?

Le résumé qui nous est présenté en fin de test semble nous indiquer que celui-ci s’est terminé sans erreur (notre critère d’échec n’ayant pas été atteint).

Deux types de métriques nous sont ensuite présentées :

• Métriques côté client : correspond aux informations générales associés au test de charge, à savoir le nombre d’utilisateurs virtuels, les temps de réponses ainsi que le nombre de requêtes par secondes.

On retrouve bien la montée en charge graduelle attendue que nous avions configurée, caractéristique des Stress test.

• Métriques côté serveur : celles-ci font références aux services qui vont être directement consommés par le test de charge. Dans notre exemple, on aura la consommation CPU/mémoire du service plan, le nombre de requêtes à l’API, le nombre de requêtes en erreur (et le type d’erreur associé), la consommation en RU (Request Unit) de la base Azure Cosmos DB, etc…

Que nous indiquent ces données ?

Sur toute la durée du test, à savoir 30 minutes, 174 000 requêtes ont été faites à notre API. Le temps de réponse est resté stable sur toute cette période.

En revanche, le premier point que l’on peut remonter est la consommation CPU. Avec une moyenne à 88% d’utilisation sur cette période, il peut être pertinent de revoir ou à minima de s’interroger sur les choix d’architecture qui ont été faits : sur une période de plus forte activité, le système sera-t-il capable de faire face ?

Ensuite, on s’aperçoit que dans le cas de notre test et pour un nombre déterminé d’utilisateurs, on atteint un taux de consommation en unités de requête de presque 60%. Là encore, il est nécessaire d’estimer avec précaution comment est utilisée l’application par les utilisateurs et la charge associée, afin d’éviter de potentiels goulots d’étranglement.

Utilisation du service

Comme pour tout service Azure, Azure Load Testing a un coût. Et celui-ci peut vite devenir non négligeable en fonction des paramètres d’exécution saisis.

Imaginons que ce process ait été intégré dans nos pipelines de CI/CD et que les tests soient exécutés à chaque nouveau déploiement en environnement de recette programmé 1 fois par jour. Dans notre exemple précédent, pour un test de 30 minutes avec 100 utilisateurs virtuels exécuté 20 fois par mois, le coût associé sera de 158,35€/mois (10,38€ par ressource – fixe – et 147,97€ pour l’ensemble des instances). Il est donc important de bien dimensionner ses tests en fonction de ses besoins et des coûts.

Bilan

Concevoir et déployer des applications sûres et robustes est capital.

Le load testing fait partie des outils permettant de s’en assurer et ce de manière pro-active.

Dans cet article nous avons pu démontrer l’importance de son rôle dans la caractérisation des performances d’un système soumis à des conditions réelles de montée en charge, dans quelle mesure il est capable d’identifier les limites du système et ainsi d’agir en conséquence.