Test de charge informatique VS Stress test

Vous avez peut-être entendu parler du succès qu’a rencontré la réédition du jogging Decathlon de 1985 ? Un tel succès que le site internet de Decathlon est « tombé » car il n’a pas pu absorber le pic de trafic. Cela aurait pu être évité ! Vous êtes développeur, ingénieur QA ou Chef de Projet, vous savez que vous devez effectuer différents tests de performance pour vous assurer que chaque modification de code ou de fonctionnalité ajoutée ne génère pas de régressions. C’est une chose, mais il convient également de s’assurer de la compatibilité de l’infrastructure avec l’usage prévu, et pour cela il faut mettre en place une campagne de stress test ou de test de charge informatique. Souvent confondues, ces deux notions sont pourtant différentes et répondent à des besoins spécifiques.

Stress test.

Il importe de bien distinguer test de charge informatique et stress test. Quand on parle de stress test, cela consiste à aller stresser l’infrastructure et plus particulièrement le temps de réaction de la partie matérielle (% d’utilisation de la mémoire vive, volume de données sur la bande passante…). Techniquement on bombarde le serveur en simulant des connexions simultanées reproduisant des requêtes HTTP. L’objectif intuitif de cette méthode est de vérifier la performance d’une application face à l’affluence d’utilisateurs.

On pense en effet souvent utiliser le stress test pour connaître la réaction d’un site web ou d’un applicatif face à une « connexion simultanée d’utilisateurs ». Mais attention, on ne reproduit pas un grand nombre d’utilisateurs et leur comportement : on va solliciter l’infrastructure en la stressant de requêtes http. On obtiendra des métriques très utiles sur l’utilisation de la bande passante, le % de mémoire vive des frontaux sollicités, … mais en aucun cas sur la qualité du ressenti de l’internaute derrière l’écran.

Admettons que l’ouverture de la page d’accueil de votre site nécessite 30 requêtes HTTP, pour reproduire 100 utilisateurs on va simplement générer 3000 requêtes simultanément et analyser les réponses du serveur. Cela s’apparente au procédé utilisé par les attaques par déni de service : DdoS (Distributed Denial of Service attack).

Pour mettre en place une campagne de stress test, il faut implémenter une ou plusieurs machines qui vont séquencer et reproduire toutes les requêtes. Il faut avoir accès à l’espace d’hébergement ou alors permettre d’y accéder depuis l’extérieur de l’infrastructure en contournant les firewalls et systèmes de sécurités mis en place. Inutile de vous parler des risques de sécurité que cela pose.

• Intérêts et avantages : cela va permettre d’observer comment l’infrastructure réagit à une sollicitation importante de la bande passante.
• Inconvénients : nous ne sommes pas face à des connexions mais à des simulations. Les mesures sont limitées et vous n’aurez donc qu’une notion du comportement de l’infrastructure et sans aucun point de vue du côté utilisateur. Pour les mettre en place il vous faudra également un outil pour reproduire les requêtes HTTP de type Apach Jmeter et un développeur pour le configurer.

Pour résumer : idéal pour savoir si un site (l’infrastructure) peut absorber la connexion simultanée de, par exemple,  250 utilisateurs. Réponse : oui ou non.

Test de charge informatique.

Le test de charge informatique est une autre technique de production pour tester les limites d’une application en matière de charge. Lors d’une campagne de montée en charge, on va reproduire à l’identique les actions d’un utilisateur afin d’identifier les points de friction et d’agir pour trouver des solutions. La seule différence c’est qu’il n’y a personne derrière la souris pour effectuer telles ou telles actions :

1. Ouverture du navigateur
2. Saisie de L’URL
3. Recherche d’un produit
4. Affichage de la fiche produit
5. …

Derrière ces actions, le test de charge informatique va pouvoir mesurer la réaction du serveur et donc de l’infrastructure comme pour un stress test mais également le comportement des JS, des services tiers … . Le rôle du navigateur étant FONDAMENTAL dans l’affichage front end de votre site, s’en affranchir relève presque du non-sens.

Le navigateur réagissant différemment en fonction du contexte réseau et des temps de réponse serveur face à la montée en charge, les requêtes HTTP émises par le navigateur peuvent être très différentes en fonction de la charge injectée sur les serveurs.

• Intérêt et avantages : le test de charge informatique va permettre d’observer au réel les conditions d’utilisation de votre site internet ou le processus d’achat de votre plateforme e-commerce, ce sans aucune immixtion sur votre infrastructure (sonde, agent, ..) ou site web (tag, javascript,..)
• Inconvénients : impossible à mettre en œuvre de manière autonome car serait énormément couteux. Imaginez devoir louer 500 machines pour réaliser une campagne et activer simultanément les scénarios variabilisés (ex : au moins les credentials) nécessaires. Il est impératif de se tourner vers un partenaire qui proposerait ce type de solution, technologiquement très complexe à mettre en œuvre.

Pour conclure.

Afin de vous aider à y voir encore plus clair au sujet du test de charge informatique, nous avons déjà illustré ces différences dans un article il y a quelques mois de ça, à propos du Black Friday.

Pour résumer : sans navigateur et avec un injecteur traditionnel (ex: jmeter), les résultats peuvent être erronés et décorrélés du comportement réel. Il faut également garder à l’esprit que les injecteurs traditionnels ne gèrent pas nativement les fonctions intrinsèques du navigateur : pas de session, pas de rendu d’éléments, pas d’exécution Javascript réelle, aucune mesure dans le navigateur, pas de déclenchement des services tiers. C’est donc votre besoin qui vous orientera vers l’une ou l’autre des solutions, stress test ou test de charge informatique.