Nous contacter au +33 1 84 20 44 13

Tests de montée en charge 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 traffic. 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 des stress test ou des tests de montée en charge. Souvent confondus, ces deux notions sont pourtant différentes et répondent à des besoins spécifiques.

1 – 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.

On pense 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 les utilisateurs mais 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 des 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.

2 – Tests de montée en charge

Lors d’une campagne de montée en charge on va reproduire à l’identique les actions d’un utilisateur. 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

Derrière ces actions, nous allons 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, 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 : cela va permettre d’observer au réel les conditions d’utilisation de votre site internet 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

Pour vous aider à y voir encore plus clair nous avons déjà illustré ces différences dans un article il y a quelques mois de ça : 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.

Les dernières actualités

ESSAYER GRATUITEMENT
2019-02-21T18:46:44+02:00