ACTUALITÉS

Test de montée en charge : optimisez les performances de votre plateforme web

31 juillet 2024

Nos conseils

#iplabel
#test de charge
#test de rupture

Partager

Partager

Partager cette publication sur:

Un besoin ? Contactez-nous

Périodes de soldes, fêtes de fin d’année, lancements d’applications et événements médiatisés. Les plateformes IT sont mises à rude épreuve toute l’année. Leur résistance est cruciale pour la réussite du modèle.

Préventifs, les tests de montée en charge sont incontournables. Ils valident une application ou un système et révèlent leurs limites et goulots d’étranglement. Aussi appelés stress tests, tests de capacité ou de performance, leurs objectifs peuvent varier. Cependant, ils visent tous à corriger les problèmes à chaque phase du projet.

Comprendre les objectifs des tests de charge

Les tests de charge sont souvent considérés comme un moyen de déterminer si une plateforme peut accueillir de nombreux utilisateurs en simultané. En réalité, ce n’est pas le cas. Pour prouver cela, les scénarios utilisés doivent correspondre exactement au comportement des utilisateurs réels. Cependant, cela est impossible à réaliser de manière réaliste. Un test de charge doit mettre en évidence les SPOF (Single Point Of Failure), les faiblesses et les goulots d’étranglement. Il identifie aussi les points de rupture de la plateforme. Ainsi, vous saurez où concentrer vos efforts pour améliorer l’efficacité et la résilience de l’infrastructure ou du code de l’application. Ces tests sont aussi utiles pour mesurer l’évolution des performances de la plateforme après chaque mise à jour. En outre, combinés à un système de métrologie, ils définissent efficacement les seuils d’alertes. Cela permet d’anticiper les dégradations de performances. De plus, ils aident à trouver les indicateurs et seuils à surveiller lors de la mise en place d’infrastructures dynamiques avec des mécanismes comme l’autoscaling.

En résumé, les tests de charge ne se limitent pas à la capacité d’accueil des utilisateurs. Ils sont essentiels pour identifier les points faibles et améliorer la performance globale de la plateforme.

ip label, notre partenaire 

Alter Way s'appuie sur les solutions d'ip label pour accompagner  les entreprises dans la gestion et l'optimisation  la performance de leurs applications critiques : 

• Analyse des besoins et objectifs : comprendre en détail vos besoins et objectifs spécifiques, alignant ainsi les tests avec vos attentes ; 
• Conception de scénarios personnalisés : développer des simulations réalistes pour évaluer la performance dans des conditions variées et difficiles ; 
• Exécution et analyse des performances : mettre en œuvre les scénarios sur mesure et surveiller de près la performance pour identifier les goulots d'étranglement potentiels.
• Rapport détaillé et recommandations : recevoir un rapport détaillé avec des recommandations.

Concevoir des scénarios de test réalistes

Comme mentionné dans l'objectifs, il est presque impossible de créer un scénario parfait. Ce scénario ne peut pas prédire et reproduire le comportement réel de vos clients et/ou utilisateurs. C'est pourquoi nous recommandons de développer plusieurs scénarios. Entre 3 et 5 scénarios sont idéaux, selon la complexité et la profondeur de votre service ou application. Ces scénarios doivent décrire au mieux le comportement supposé des utilisateurs. Ils seront pondérés selon leur probabilité de réalisation.

Chez Alter Way, nous conseillons à nos clients généralement de créer au moins 3 scénarios de base, par exemple :

• Scénario S01_Navigation :
  • Accéder à la page d'accueil
  • Naviguer dans 3-5 catégories de produits aléatoires
  • Effectuer 2-3 recherches de produits
  • Temps de réflexion entre les actions : 5-15 secondes
• Scénario S02_Achat :
  • Accéder à la page d'accueil
  • Rechercher un produit spécifique
  • Ajouter le produit au panier
  • Procéder au paiement (sans finaliser la transaction)
  • Temps de réflexion entre les actions : 10-30 secondes
• Scénario S03_Compte :
  • Accéder à la page de connexion
  • Se connecter avec des identifiants valides
  • Consulter l'historique des commandes
  • Modifier les informations du compte
  • Se déconnecter
  • Temps de réflexion entre les actions : 15-45 secondes

En fonction des secteurs, nous utilisons notre expérience pour définir une liste de pages, fonctions et transactions. Ces éléments consomment beaucoup de ressources (calcul, mémoire, stockage) et sont intégrés dans les scénarios de tests.

Intégrer des données dynamiques et temps de réflexion

Le temps de réflexion est le temps moyen pendant lequel un utilisateur navigue sur une page web et réfléchit avant d’effectuer l’action suivante. Du côté de la plateforme, il se matérialise par une pause d’une durée variable entre les différentes requêtes qui arrivent. Il est essentiel d’implémenter ce paramètre dans vos tests afin de rendre votre scénario réaliste et pas trop agressif envers votre plateforme. Bien sûr, nous recommandons de rendre ce temps de réflexion aléatoire en utilisant une fourchette de temps raisonnable.

La plupart des outils de test offrent la fonctionnalité de temps de réflexion par défaut. Cependant, le défi réside dans la détermination d'une valeur réaliste pour votre audience spécifique. Pour ce faire, vous pouvez utiliser des outils d'analyse web comme Google Analytics, Fathom Analytics, Matomo . Ces outils vous aideront à mesurer le temps passé par vos utilisateurs réels sur une page avant d'agir. De plus, il est recommandé d'intégrer des données dynamiques dans vos tests. Par exemple, vous pouvez simuler l'envoi de formulaires, de fichiers ou d'ensembles de données. Cette approche permet d'anticiper les comportements qui sollicitent souvent beaucoup de ressources sur la plateforme. L'utilisation de temps de réflexion réalistes et de données dynamiques rendra vos tests plus précis et pertinents.

Automatiser et intégrer les tests dans votre processus de développement

Les tests de charge visent principalement à détecter les pertes de performance suite aux modifications de code ou d'infrastructure. Par conséquent, il est crucial d'intégrer ces tests dans votre processus de développement agile. Après chaque déploiement en pré-production, lancez un test de charge. Ensuite, comparez les résultats avec le déploiement précédent. Ainsi, vous pourrez émettre une alerte en cas de baisse des performances. De plus, ce processus peut être automatisé en l'intégrant dans votre chaîne d'intégration et de déploiement continu (CI/CD).

Exemple : Pipeline CI/CD pour une application web

• Développeur pousse le code sur la branche de développement
• Gitlab déclenche automatiquement le build et les tests unitaires
• Si les tests unitaires passent, déploiement sur l'environnement de pré-production
• Exécution automatique des tests de charge avec Gatling :
  • 1000 utilisateurs virtuels sur 5 minutes
  • Comparaison des résultats avec le benchmark précédent
• Si les tests de charge passent (temps de réponse < 2s, taux d'erreur < 1%), déploiement en production
• Si échec, notification à l'équipe de développement avec rapport détaillé

Il est essentiel de tester votre plateforme fréquemment. C'est pourquoi nous recommandons de développer vos scénarios de test dès le début du cycle de vie de votre application.

Mettre en place une métrologie complète

La métrologie est cruciale pour analyser les résultats des tests de charge. Elle permet d'identifier rapidement les goulots d'étranglement de votre plateforme. Chez Alter Way, nous mesurons les métriques matérielles de chaque composant de l'infrastructure. Cela inclut l'utilisation du CPU, de la RAM, du disque et du réseau. De plus, nous surveillons de nombreuses métriques middleware pour des services comme Nginx, Apache et MySQL. Ces données offrent une vue détaillée des performances.En outre, nous recommandons fortement l'utilisation d'outils de RUM (Real User Monitoring). Des solutions comme NewRelic, AppDynamics ou Data Dog sont particulièrement efficaces. L'objectif est d'obtenir une image complète de l'infrastructure, des middlewares et du logiciel. Ainsi, vous pouvez cibler vos efforts d'optimisation de manière plus efficace.

Enfin, des outils comme NewRelic aident à identifier où l'application passe le plus de temps. Notre expérience montre que l'analyse des requêtes de base de données est souvent un bon point de départ pour améliorer les performances.

Tester en pré-production et en production

Chez Alter Way, nous privilégions des infrastructures similaires pour la production et la pré-production. Cependant, l'environnement de pré-production a généralement des capacités de calcul réduites et une redondance moindre. L'objectif principal est d'assurer un comportement identique de l'application dans les deux environnements. Pour ce faire, nous utilisons les mêmes mécanismes de répartition de charge et de mise en cache. Nous recommandons fortement de tester chaque déploiement en pré-production. Néanmoins, il est également crucial de programmer des tests de charge hebdomadaires en production. Ces tests peuvent être effectués la nuit ou pendant les périodes d'activité creuse. En suivant ces recommandations, vous optimisez la performance et la fiabilité de votre plateforme. De plus, vous anticipez les problèmes potentiels avant qu'ils n'affectent vos utilisateurs réels.

Distinguer tests de rupture et tests de charge

Il nous semble important de mentionner qu’il existe 2 types de tests dont les objectifs et des conséquences sont différents : 

• Tests de rupture visent à pousser la plateforme à ses limites absolues. Leur objectif principal est de détecter des points de rupture clairs. Cependant, ces tests peuvent être très exigeants pour la plateforme. Par conséquent, nous déconseillons de les effectuer dans un environnement de production. Pour évaluer les limites de votre environnement de production, une alternative existe. Nous recommandons d'adapter temporairement votre environnement de pré-production. Ainsi, il correspondra aux capacités de votre production réelle.
• Tests de charge sont généralement moins intensifs pour la plateforme. Leur but est d'injecter un nombre raisonnable de scénarios. Cela permet d'observer les réactions de la plateforme et de l'application.Ces tests sont particulièrement utiles après des modifications. Ils aident à vérifier que les changements de code ou d'infrastructure n'ont pas d'impact négatif. De plus, ils permettent d'évaluer les performances et l'évolutivité de la plateforme.

Exemple : Application de streaming vidéo

Test de charge :

• Simuler 10 000 utilisateurs visionnant des vidéos simultanément
• Durée : 1 heure
• Objectif : Vérifier que le temps de chargement des vidéos reste < 3 secondes
• Métrique surveillée : Utilisation CPU des serveurs < 80%

Test de rupture :

• Commencer avec 10 000 utilisateurs, augmenter de 1000 toutes les 5 minutes
• Continuer jusqu'à ce que le système montre des signes de défaillance
• Objectif : Identifier le nombre maximum d'utilisateurs supportés
• Point de rupture observé : 35 000 utilisateurs (CPU à 100%, temps de chargement > 10s)

Effectuer des tests depuis l'extérieur

Il est généralement recommandé d’effectuer les tests de charge ou de stress à partir d’une infrastructure extérieure. Par exemple, chez Alter Way, nous lançons toujours nos tests à partir d’un environnement isolé AWS ou GCP, quel que soit l’endroit où est hébergée la plateforme que nous voulons tester.

Cela garantit que vous testez la capacité de votre stack entière (y compris votre capacité à gérer le trafic entrant provenant d’un autre réseau) au lieu de travailler depuis votre réseau local.

Exemple : Application SaaS B2B

Configuration :

• Application hébergée sur AWS en région eu-west-1 (Irlande)
• Tests lancés depuis des instances EC2 dans 3 régions différentes :
  1. us-east-1 (Virginie du Nord)
  2. ap-southeast-1 (Singapour)
  3. eu-central-1 (Francfort)

Scénario de test :

• Chaque région simule 1000 utilisateurs se connectant et utilisant l'application
• Durée : 30 minutes
• Métriques observées :
  • Temps de réponse moyen par région
  • Taux d'erreur par région
  • Latence réseau

Résultats :

• Temps de réponse moyen :
  • us-east-1 : 800ms
  • ap-southeast-1 : 1200ms
  • eu-central-1 : 300ms
• Identification d'un problème de performance pour les utilisateurs en Asie-Pacifique

Action corrective :

• Déploiement d'un CDN (Amazon CloudFront) pour améliorer les performances globales

Défis et pièges courants des tests de montée en charge

Scénarios de test irréalistes

• Défi : Créer des scénarios qui ne reflètent pas le comportement réel des utilisateurs.
• Solution :
  • Analyser les logs de production pour comprendre les modèles d'utilisation réels ;
  • Collaborer avec les équipes métier pour identifier les parcours utilisateurs typiques ;
  • Utiliser des outils d'analyse web pour obtenir des données sur le comportement des utilisateurs.

Négliger l'environnement de test

• Défi : Utiliser un environnement de test qui ne reflète pas fidèlement la production.
• Solution :
  • Créer un environnement de pré-production aussi proche que possible de la production ;
  • Utiliser des données de test représentatives (en volume et en nature) ;
  • Simuler les intégrations tierces et les services externes.

Ignorer les effets de cache

• Défi : Les tests répétitifs peuvent donner des résultats faussement positifs en raison du caching.
• Solution :
  • Vider les caches avant chaque série de tests ;
  • Varier les données de test pour éviter les effets de cache ;
  • Inclure des scénarios qui testent spécifiquement les performances du système sans cache.

Sous-estimer l'impact du réseau

• Défi : Ne pas prendre en compte la latence réseau et les conditions variables du réseau.
• Solution :
  • Effectuer des tests depuis différentes localisations géographiques ;
  • Simuler différentes conditions réseau (bande passante limitée, latence élevée) ;
  • Utiliser des outils comme Network Link Conditioner ou WANem pour simuler des conditions réseau réalistes.

Négliger la surveillance des ressources système

• Défi : Se concentrer uniquement sur les métriques de l'application, en ignorant les ressources système.
• Solution :
  • Mettre en place une surveillance complète (CPU, mémoire, disque, réseau) pendant les tests ;
  • Utiliser des outils comme Prometheus, Grafana, ou les services de monitoring cloud natifs ;
  • Corréler les métriques système avec les performances de l'application.

Mal interpréter les résultats

• Défi : Tirer des conclusions hâtives ou incorrectes des résultats des tests.
• Solution :
  • Établir des benchmarks clairs et des KPIs avant de commencer les tests ;
  • Analyser les tendances sur plusieurs exécutions de test plutôt que de se fier à un seul résultat ;
  • Former l'équipe à l'interprétation correcte des résultats de test de charge.

Négliger les tests de longue durée

• Défi : Se concentrer uniquement sur les pics de charge à court terme, en ignorant les problèmes qui peuvent survenir sur de longues périodes.
• Solution :
  • Inclure des tests de charge soutenus sur plusieurs heures ou jours ;
  • Surveiller les fuites de mémoire, la fragmentation de la base de données et autres problèmes qui se manifestent avec le temps.

Ignorer le nettoyage post-test

• Défi : Laisser des données de test ou des configurations modifiées après les tests, ce qui peut affecter les futurs tests ou même la production.

• Solution :
  • Mettre en place des procédures de nettoyage automatisées après chaque série de tests ;
  • Utiliser des conteneurs ou des environnements éphémères pour les tests quand c'est possible ;
• Vérifier systématiquement l'état du système après les tests.

Ne pas impliquer toutes les parties prenantes

• Défi : Réaliser des tests de charge sans impliquer toutes les équipes concernées (développement, ops, réseau, base de données, etc.).
• Solution :
  • Organiser des réunions de planification incluant toutes les parties prenantes ;
  • Partager les résultats des tests avec toutes les équipes concernées ;
  • Encourager une approche collaborative pour résoudre les problèmes identifiés.

Négliger la sécurité pendant les tests

• Défi : Ignorer les implications de sécurité des tests de charge, potentiellement en exposant des vulnérabilités.
• Solution :
  • Impliquer l'équipe de sécurité dans la planification des tests ;
  • S'assurer que les données de test sont anonymisées et sécurisées ;
  • Vérifier que les tests de charge n'interfèrent pas avec les mécanismes de sécurité existants.

Obtenir un retour sur investissement sur vos tests

• Réduction des pannes :
  • Diminution des temps d'arrêt coûteux ;
  • Économie potentielle : 10 000€ - 100 000€ par heure de panne évitée.
• Amélioration de l'expérience utilisateur :
  • Augmentation de la satisfaction et de la rétention des clients ;
  • Impact : Augmentation potentielle de 5-10% du chiffre d'affaires.
• Optimisation des ressources :
  • Dimensionnement correct de l'infrastructure, évitant le sur-provisionnement ;
  • Économie : 10-30% sur les coûts d'infrastructure.
• Détection précoce des problèmes :
  • Réduction des coûts de correction en production ;
  • Économie : 3-10 fois le coût de correction en phase de développement.
• Confiance accrue dans les déploiements :
  • Réduction du stress de l'équipe et amélioration de la productivité ;
  • Impact : Amélioration de 10-20% de la vélocité de développement.
• Conformité et réputation :
  • Respect des SLAs et maintien de la réputation de l'entreprise ;
  • Valeur : Difficile à quantifier, mais cruciale pour la croissance à long terme.

Alter Way analyse en profondeur les résultats des tests de charge. Cette analyse permet d'identifier les anomalies de la plateforme ou de l'application. Ensuite, notre équipe élabore un plan de remédiation détaillé. Ce plan vise à corriger les éventuels défauts d'architecture identifiés. De plus, nous proposons des solutions concrètes pour optimiser les performances. Ces recommandations sont basées sur notre expertise en hébergement cloud. Enfin, Alter Way vous accompagne dans la mise en œuvre des améliorations. Ainsi, nous assurons une optimisation continue de votre infrastructure.

Notre approche complète garantit une plateforme robuste et performante, prête à relever les défis de charge. Souhaitez-vous en savoir plus et tester votre plateforme avant votre prochain événement en ligne ? Contactez-nous pour discuter de votre projet.