Les objectifs sont définis de manière commune avec deux approches possibles :

• Tests en rupture (limite haute de tenue de la plate-forme, des temps de réponse acceptables sur une application et sur un ou plusieurs scénarios de navigation.
• Validation de tenue de charge sur un nombre d’utilisateurs simultanés sur un un ou plusieurs scénarios de navigation.

Pour qu’un test de charge soit pertinent, il est nécessaire de simuler au plus près le comportement des utilisateurs dans l’application.

La définition de scénarios de navigation est donc réalisée en accord avec la maîtrise d’ouvrage qui donne des indications sur :

• Les scénarios type à modéliser.
• Les étapes des scénarios à enchaîner, leurs durées et la typologie de donnée à exploiter.
• Le nombre de scénarios simultanés à lancer, les plateaux…

Une fois ces scénarios validés et documentés, ces scénarios sont codés. Nous utilisons l’outil JMETER pour cela. Ces scénarios ont une double utilité :

• être exploités pour les tests de charge ;
• être exploités en continu dans les outils de supervision afin d’identifier les variations de temps de réponse en production (en cas d’incident technique et aussi en cas de mise à jour du code applicatf car une version N+1 d’un code peut avoir un impact fort sur les temps de réponse).

Exemple de scénario :

Plus d’information sur l’outils de test de charge que l’on utilise : https://www.syloe.com/glossaire/jmeter-logiciel-test-de-charge/
JMETER fonctionne en mode client serveur , dans le sens où l’on peut avoir des clients (ou agent ou injecteurs) multiples , qui envoient la charge séparément , et la remontée des métriques est centralisée sur le « serveur » . On passe par des injecteurs en dehors du serveur , si le nombre d’utilisateurs simultanés voulus dépasse les 8000 , ou s’il y a des problématiques de limitations réseaux

Les test de charge ont pour objectif d’identifier les seuils de rupture éventuels, les temps de réponse en fonction des paliers de charge, mais aussi et surtout d’identifier les goulots d’étranglement qui peuvent être très variés en fonction de l’infrastructure et de l’application :

• RAM, CPU, IO disque, réseau…
• Requêtes, cache…

Soit nous instrumentons la supervision à partir d’outils comme Zabbix, ce qui nécessite un accès à la plate-forme, soit nous exploitons les outils en place et dans ce cas, nous devons convenir des métriques qui nous sont nécessaires avec l’exploitant de la plate-forme.

Avant le ou les tirs, les pré-requis doivent être validés :

• Organisation : planification, horaires
• Fonctionnels : scénarios, jeux de données à exploiter et à nettoyer post-tests
• Techniques : ouverture des flux et droits nécessaires

Les tirs sont lancés à partir de nos serveurs distants. Un test de pré-calibration avec un nombre de users limités (#50) est lancé pour valider la chaîne de tests et s’ajuster avec l’exploitant si nécessaire.

Définition conjointe des métriques des tests. Exemple d’un plan de test :

T0 de 0 à 500* utilisateurs simultanées
T+30 min de 500 à 1000*
T+90 min de 1000 à 2000*
T+150 min de 2000 à 2500*

Attention : Il nous est très difficile d’estimer le nombre de tirs nécessaires pour aboutir aux objectifs fixés. Un seul tir est nécessaire si tout se passe bien. Deux tirs à minima sont nécessaires si il y a des points à corriger. Notre offre comprend en général deux tirs ainsi que le test de pré-calibration. Le nombre de tir sera défini lors de la réponse aux marchés subséquents.