
Un test de charge est un test où l’on mesure le comportement d’un système en fonction de la charge d’utilisateurs simultanés. Ce type de test permet de mettre en évidence les points sensibles et critiques de l’architecture technique. Il permet en outre de mesurer le dimensionnement des serveurs, de la bande passante nécessaire sur le réseau, etc.
VOS ATTENTES
- Résoudre des problèmes de performance d’une application
- Rassurer la DSI sur la montée en charge d’une application
- Valider les performances, l’endurance et la robustesse d’une application
- Dimensionner une infrastructure de production pour un déploiement en production et son industrialisation
NOTRE EXPERTISE
- Établissement avec vous d’un ou plusieurs scénarios de navigation pour les utilisateurs finaux
- Mise en place de nos utilitaires de récoltes de données sur l’infrastructure de test
- Lancement de façon graduelle des connexions à partir de cinq points web différents et à partir de cinq fournisseurs d’accès internet
- Création de graphes de consommation des ressources matérielles et logicielles suivant la charge envoyée
- Remise d’un rapport regroupant toutes les informations avec nos analyses et préconisations
- Tests de charge appliqués sur des applications web multi-plateformes, des web services, des bases de données …
Les attentes clients en terme de tests de charge
Les besoins clients auxquels peuvent répondre des tests de charge avancés sont les suivants :
✔️ Résoudre des problèmes de performance d’une application
✔️ Valider les performances, l’endurance et la robustesse d’une application
✔️ Dimensionner une infrastructure de production pour un déploiement en production de son industrialisation
✔️ Rassurer la DSI sur la montée en charge d’une application.
Methodologie
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.
Analyse et livrables
Les livrables comprennent :
- Graphes systèmes du comportement de l’utilisation de la RAM/CPU/Process du serveur ainsi que des applications Apache/PHP/Mysql.
- Graphes d’évolutions du temps d’affichage des pages cibles en fonction du nombre d’utilisateurs simultanées connectés, durant le temps de tests (page d’accueil, et autres à définir ensemble).
- Rapport technique concernant le test de charge et préconisation. Un rapport produit pour le premier tir est mis à jour à chaque tir.
AUTRE CAS CLIENT
EXEMPLE DE TEST DE CHARGE
Un client nous soumet une problématique concernant la future augmentation en nombre d’utilisateurs connectés de son site internet.
Publication récentes

Cas client – Migration d'un système d'information vers le Cloud AWS
Découvrez comment Syloé accompagne son client depuis deux ans et demi sur la migration de son système d’information vers le Cloud AWS.

Tout savoir sur les puits de logs
Découvrez tout ce que vous devez savoir sur les puits de logs, la première étape indispensable de votre stratégie de centralisation des logs.

Sécuriser ses envois de courriers
Face aux cyberattaques, sécuriser ses envois de courriers électoniques est devenu de plus en plus indispensable. Découvrez comment sécuriser vos envois avec 3 méthodes différentes : SPF, DKIM et DMARC.

Nagstamon : Superviser la supervision
Vous cherchez une solution personnalisable qui centralise les alertes remontées par les serveurs de monitoring ? Découvrez Nagstamon et ses nombreux avantages ! En prime on vous explique comment l’installer et le configurer simplement.

Les articles les plus lus en 2019
Retrouvez notre sélection des 10 articles les plus lus sur le blog par nos visiteurs durant l’année 2019. Une occasion de les découvrir ou les redécouvrir !

Cas client : Architecture et infogérance sur le Cloud Azure
Cas client : découvrez comment Syloé a créé et infogéré une infrastructure multiservice sur le Cloud Azure ainsi que les outils utilisés pour y parvenir.

Développement applicatif : optimiser son flux de travail grâce au multi-environnements
Comment optimiser le flux de travail des équipes de développement, tout en réduisant le Time-to-Market ? En intégrant le multi-environnements à son process.

Superviser son cluster Kubernetes avec Prometheus et Grafana
Vous venez d’installer un cluster Kubernetes et vous voulez savoir s’il se porte bien ? Grafana et Prometheus vont vous aider à y voir plus clair.