Les 10 commandements pour tester efficacement les limites de sa plateforme web
1. Objectifs
Les tests de charge sont souvent considérés comme un moyen de déterminer si une plateforme peut accueillir 500, 1 000 ou 10 000 utilisateurs simultanés. En réalité, ce n’est pas le cas.
Pour prouver ce genre d’affirmation, il faudrait que les scénarios utilisés lors des tests de charge correspondent au comportement exact des utilisateurs réels qui se rendent sur la plateforme et utilisent le service, ce qui est impossible à réaliser de manière réaliste.
Un test de charge devrait plutôt être considéré comme un outil mettant en évidence les SPOF (Single Point Of Failure), les faiblesses, les goulots d’étranglement et les points de rupture de la plateforme afin de savoir où nous devons concentrer nos efforts pour améliorer l’efficacité et la résilience de l’infrastructure ou du code de l’application.
Ces tests sont également utiles afin de mesurer l’évolution des performances de la plateforme au fur et à mesure des mises à jour de l’infrastructure ou de l’application.
Enfin, combiné à un système de métrologie, ces tests permettent de définir efficacement les seuils d’alertes à mettre en place pour anticiper les dégradations de performances, ou de trouver les indicateurs et seuils à surveiller lors de la mise en place d’infrastructures dynamiques disposant de mécanismes tels que la mise à l’échelle automatique (autoscaling).
2. Outils
Il existe un grand nombre d’outils disponibles pour effectuer des tests de performance, stress, fiabilité et des tests de charge.
Chez Iguane Solutions, nous avons une grande expérience dans l’utilisation d’outils opensource : Gatling, Octoperf (JMeter). Aucun outil n’est meilleur que l’autre et ils ont tous leurs avantages et leurs inconvénients.
Nous privilégions des outils disposant de fonctions adaptées à nos besoins (facilité de création de scénarios via l’utilisation de proxy, création de rapports standardisés et facilement interprétables, personnalisation et configuration avancée, intégration aisée dans l’application), et qui nous permettent d’implémenter un plan de tests défini préalablement.
Une méthodologie rigoureuse nous permet également de pouvoir ré-utiliser l’ensemble pour lire, comparer et comprendre les résultats et en faire des synthèses compréhensibles par tous.
3. Scénario (Privilégier le pragmatisme à la perfection)
Comme mentionné dans la section des objectifs, il est presque impossible de développer le scénario parfait qui va 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 selon la complexité et la profondeur de votre service ou application) qui décrivent au mieux le comportement supposé des utilisateurs et qui seront tirés avec des poids relatifs à leur probabilité de réalisation.
Chez Iguane Solutions, nous travaillons avec de nombreux e-commerçants. Nous leur conseillons généralement de créer au moins 3 scénarios de base :
- Le premier simulant un utilisateur non authentifié naviguant sur le site web, afin de pouvoir tester les différentes couches de cache ;
- Un autre scénario où l’utilisateur se connecte, parcourt les articles, ajoute quelques produits à son panier et finalise sa commande ;
- Et enfin un scénario où l’utilisateur crée simplement un compte.
Pour tous les autres secteurs et de manière générale, nous utilisons notre expérience afin de définir avec nos clients une liste de pages, fonctions et transactions qui consomment beaucoup de ressources au sein de la plateforme (calcul, mémoire, stockage) afin de les intégrer dans les scénarios de tests.
4. Utiliser des données dynamiques (Temps de réflexion et données)
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 offrent cette fonctionnalité par défaut, mais tout l’enjeu est de trouver une valeur réaliste pour le temps de réflexion en fonction de votre audience spécifique. Pour cela vous pouvez utiliser des outils d’analyse web tels que Google Analytics, Fathom Analytics, Matomo … afin de vérifier combien de temps vos utilisateurs réels restent sur une page de votre site avant d’agir avec.
Enfin, il peut être utile d’introduire dans vos tests des données dynamiques (envoi de formulaire, de fichier, d’ensemble de données) pour anticiper ces comportements sollicitant souvent beaucoup de ressources sur la plateforme.
5. Réutilisabilité (Testez fréquemment, CI/CD)
L’un des principaux objectifs des tests de charge est de savoir si une modification de votre code ou de votre infrastructure entraîne une perte de performance. C’est pourquoi il est essentiel d’inclure les tests de charge dans votre processus de développement agile.
Vous pouvez, par exemple, après chaque déploiement votre environnement de pré-production, déclencher un test de charge et comparer le résultat avec le déploiement précédent, afin d’émettre une alerte si les performances ont été impactées à la baisse. L’ensemble de ce processus peut être réalisé de manière automatisé en l’intégrant dans votre chaîne d’intégration et de déploiement continue. (CI/CD).
Il est essentiel de tester sa plateforme aussi souvent que possible; et c’est également la raison pour laquelle nous vous recommandons de commencer à développer vos scénarios tôt dans le cycle de vie de votre application.
6. La métrologie
La métrologie est essentielle lorsqu’il s’agit d’analyser les résultats de vos tests. Elle vous permet de déterminer rapidement où se trouvent les goulots d’étranglement de votre plateforme en vous donnant des mesures détaillées sur chaque service et partie de votre infrastructure.
Chez Iguane Solutions, lorsque nous effectuons des tests de charge, nous nous assurons de mesurer les métriques matérielles telles que l’utilisation du CPU, de la RAM, du disque et du réseau de chaque composant de l’infrastructure.
Mais aussi de nombreuses métriques middleware pour des services tels que Nginx, Apache, Varnish, HAproxy, Redis, MySQL…
En plus de ces mesures, nous recommandons fortement d’utiliser des outils de RUM (Real User Monitoring) et de profilage applicatifs tels que NewRelic, AppDynamics, Data Dog…
Le but, évidemment, est d’avoir une image complète de ce qui se passe au niveau de l’infrastructure (hardware), des middlewares et du logiciel, pour déterminer où il serait judicieux de concentrer les efforts afin d’être en mesure de faire évoluer votre plateforme plus efficacement.
Des outils tels que Newrelic sont très efficaces pour déterminer où l’application passe le plus clair de son temps. D’après notre expérience, l’examen du temps passé pendant les requêtes de base de données est toujours un bon début pour enquêter et améliorer les performances.
7. Pré-production/Production
Chez Iguane Solutions, nous recommandons et mettons toujours en place des infrastructures similaires pour les environnements de production et de pré-production, généralement avec des capacités de calcul plus petites et une redondance quelque peu réduite pour le second environnement.
L’objectif principal est de garantir que l’application se comporte de la même manière en phase de test qu’en production, en utilisant les mêmes mécanismes de répartition de charge, de mise en cache, etc.
Cependant, même si nous recommandons fortement de tester chaque déploiement sur l’environnement de pré-production, nous vous conseillons également de programmer au moins un test de charge hebdomadaire sur votre plateforme de production, peut-être la nuit ou pendant une période d’activité creuse.
8. Tests de rupture et tests de montée en charge
Il nous semble important de mentionner qu’il existe en réalité 2 types de tests que vous pouvez effectuer : les tests de rupture et les tests de montée en charge.
Les deux ont des objectifs différents et des conséquences différentes :
- Test de rupture :
Le but d’un test de rupture est généralement de pousser la plateforme à ses limites absolues, afin de détecter des points de rupture clairs. Comme le but d’un test de rupture est de submerger complètement la plateforme, nous ne recommandons pas de les effectuer dans un environnement de production. Si vous souhaitez avoir une idée claire des limites de votre environnement de production, nous vous conseillons de faire évoluer temporairement votre environnement de pré-production pour qu’il corresponde à vos capacités de production.
- Tests de charge
Les tests de charge sont généralement moins durs pour la plateforme. L’objectif est d’injecter un nombre raisonnable de scénarios afin d’observer comment la plateforme et l’application réagissent pour s’assurer que la dernière modification du code ou de l’infrastructure n’a pas eu d’impact négatif sur les performances ou l’évolutivité.
9. Sortir des sentiers battus
Il est généralement recommandé d’effectuer les tests de charge ou de stress à partir d’une infrastructure extérieure. Par exemple, chez Iguane Solutions, 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.
10. Aller plus loin
Grâce aux tests de montée en charge, nous avons pu identifier les SPOF (Single Point Of Failure), les faiblesses, les goulots d’étranglement et les points de rupture de la plateforme. Mais lorsque vous commencez le processus d’amélioration continue de votre plateforme, il est également important de penser à la partie performance web du côté front-end.
En effet, les moteurs de recherche comme google, yahoo et bing favorisent naturellement les sites web qui respectent et contiennent certaines caractéristiques et méthodes de performance. C’est ce que nous appelons le SEO (Search Engine Optimization) et il existe des méthodes rapides pour améliorer ces performances, par exemple en optimisant la taille de vos statiques, en compressant vos pages en utilisant Gzip ou Brotli lorsque cela est possible, en utilisant HTTP2, ou en exécutant les scripts Javascript non essentiels à la fin du chargement de la page.
Nous avons à notre disposition plusieurs outils qui nous permettent d’analyser, de surveiller et de prendre des mesures en conséquence. Nous en utilisons chez Iguane Solutions certains comme GTmetrix ou Webpage test.
Ces outils nous permettent d’avoir une évaluation complète de la webperf de notre page web et nous donnent des indications sur les points à améliorer tels que le taux de rétention du cache, la taille des images ou encore l’ordre d’exécution de certains scripts JS.
Vous souhaitez en savoir plus ?