Les 10 commandements pour tester efficacement les limites de votre plateforme web
1. Buts
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, les scénarios utilisés pendant les tests de charge devraient correspondre au comportement exact des utilisateurs réels qui entrent sur la plateforme et utilisent le service, ce qui est impossible à réaliser.
Le test de charge doit plutôt être considéré comme un outil qui met en évidence les SPOF (Single Point Of Failure), les faiblesses, les goulets 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 pour mesurer l'évolution des performances de la plateforme au fur et à mesure des mises à jour de l'infrastructure ou de l'application.
Enfin, associés à un système de métrologie, ces tests permettent de définir efficacement les seuils d'alerte à mettre en place pour anticiper les dégradations de performance, ou de trouver les indicateurs et les seuils à surveiller lors de la mise en place d'infrastructures dynamiques avec des mécanismes tels que l'autoscaling.
2. Les outils
Il existe un grand nombre d'outils permettant d'effectuer des tests de stress et des tests de charge.
Chez Iguane Solutions, nous avons une solide expérience de l'utilisation de Gatling et d'Octoperf(JMeter). Aucun outil n'est meilleur que l'autre et ils ont tous leurs avantages et leurs inconvénients.
Nous privilégions les outils dont les fonctionnalités sont adaptées à nos besoins(création aisée de scénarios via l'utilisation de proxies, création de rapports standardisés et facilement interprétables, personnalisation et configuration avancées, intégration aisée dans l'application) et qui nous permettent de mettre en œuvre un plan de test défini à l'avance.
Une méthodologie rigoureuse permet également de pouvoir réutiliser l'ensemble pour lire, comparer et comprendre les résultats et rendre les synthèses compréhensibles par tous.
3. Scénario (préférer le pragmatisme à la perfection)
Comme indiqué dans la section sur les 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 le mieux possible le comportement supposé des utilisateurs. Ces scénarios peuvent ensuite être testés plus ou moins fortement en fonction de leur probabilité.
Chez Iguane Solutions, nous travaillons avec de nombreux commerçants en ligne. Nous leur conseillons généralement de créer au moins 3 scénarios de base :
- La première simule un utilisateur non authentifié naviguant sur le site web, afin de tester les différentes couches de cache ;
- Autre scénario : l'utilisateur se connecte, parcourt les articles, ajoute quelques produits à son panier et finalise sa commande ;
- Enfin, un scénario dans lequel un utilisateur crée simplement un compte.
Pour toutes les autres industries ou cas d'utilisation, et de manière générale, nous utilisons notre expérience pour définir avec nos clients une liste de pages, de fonctions et de transactions qui consomment beaucoup de ressources de la plateforme (calcul, mémoire, stockage) afin de les intégrer dans les scénarios.
4. Utiliser des données dynamiques (penser au temps et aux 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 de 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 vis-à-vis de votre plateforme. Bien entendu, nous vous conseillons de randomiser le temps de réflexion en utilisant une fourchette de temps raisonnable.
La plupart des outils offrent cette fonction par défaut, mais le défi consiste à trouver une valeur réaliste pour le temps de réflexion en fonction de votre public spécifique. Pour ce faire, vous pouvez vous appuyer sur vos outils d'analyse web habituels tels que Google Analytics, Fathom Analytics, Matomo... pour vérifier combien de temps vos utilisateurs réels restent sur une page de votre site avant d'agir.
Enfin, il peut être utile d'introduire dans vos tests des données dynamiques (envoi d'un formulaire, d'un fichier, d'un ensemble de données) pour anticiper ces comportements qui occupent souvent beaucoup de ressources sur la plateforme.
5. Réutilisation (tests fréquents, 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 poussée sur l'environnement de mise à disposition, déclencher un test de charge et comparer le résultat avec la poussée précédente afin de déclencher une alerte si les performances ne sont pas aussi bonnes qu'avant. Toute cette chaîne d'événements peut être entièrement automatisée dans votre pipeline CI/CD.
Il est essentiel de tester souvent et c'est pourquoi nous vous recommandons de commencer à développer vos scénarios dès le début du cycle de vie de votre application.
6. 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 goulets d'étranglement de votre plateforme en vous donnant des mesures détaillées sur chaque service et chaque partie de votre infrastructure.
Chez Iguane Solutions, lorsque nous effectuons des tests de charge, nous veillons à mesurer les paramètres matériels tels 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 d'applications tels que NewRelic, AppDynamics, Data Dog...
L'objectif est évidemment d'avoir une vue d'ensemble de ce qui se passe au niveau du matériel, de l'intergiciel et du logiciel afin de comprendre où vous devez concentrer vos efforts pour pouvoir 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é lors des requêtes de base de données est toujours un bon point de départ pour l'investigation et l'amélioration des performances.
7. Mise en scène/Production
Chez Iguane Solutions, nous recommandons et mettons toujours en place des infrastructures similaires pour la production et le stockage, généralement avec des capacités de calcul plus petites et une redondance quelque peu réduite pour ce dernier environnement.
L'objectif principal est de garantir que l'application se comporte de la même manière en phase d'essai qu'en phase de production, en utilisant les mêmes mécanismes d'équilibrage de la charge, de mise en cache, etc.
Cependant, même si nous recommandons fortement de tester chaque déploiement sur l'environnement de préparation, nous 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é calme.
8. Test de stress et test de charge
Nous pensons qu'il est utile de préciser qu'il existe en fait deux types de tests que vous pouvez effectuer : Les tests de stress et les tests de charge.
Les deux ont des objectifs et des conséquences différents :
- Test de stress
L'objectif d'un test de résistance est généralement d'amener la plateforme à ses limites absolues, afin de détecter des points d'arrêt clairs. Comme l'objectif d'un test de stress est de submerger complètement la plateforme, nous ne recommandons pas de l'effectuer dans un environnement de production. Si vous souhaitez avoir une idée précise des limites de votre environnement de production, nous vous conseillons d'adapter temporairement votre environnement de démonstration à votre capacité de production.
- Test de charge
Les tests de charge sont généralement moins difficiles 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 et de s'assurer que le dernier changement de code ou d'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 externe. 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ù la plateforme que nous voulons tester est hébergée.
Cela vous permet de tester la capacité de l'ensemble de votre site stack (y compris votre capacité à gérer le trafic entrant en provenance d'un autre réseau) au lieu de travailler à partir de votre réseau local.
10. Aller plus loin
Grâce aux tests de charge, nous avons vu comment nous pouvions identifier les SPOF (Single Point Of Failure), les faiblesses, les goulets d'étranglement et les points de rupture d'une plateforme. Mais lorsque vous entamez le processus d'amélioration continue de votre plateforme, il est également important de penser à la performance web du côté frontal.
En effet, les moteurs de recherche tels que 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 SEO (Search Engine Optimization) et certains des gains rapides sont d'optimiser la taille de vos statiques, de compresser en utilisant Gzip ou brotli lorsque c'est possible, d'utiliser HTTP2, d'exécuter le Javascript non important à la fin de la page de chargement, d'utiliser les derniers codes SSL, etc.
Nous disposons de plusieurs outils qui nous permettent d'analyser, de surveiller et de prendre des mesures en conséquence. Par exemple, nousous utilisons chez Iguane Solutions 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 l'ordre dans lequel nous devons charger certains scripts JS.
Contactez Iguane Solutions pour en savoir plus et nous faire part de vos besoins !
