Introduction aux tests de performance

Avant d’être déployée en production, votre application web va probablement passer par plusieurs phases de tests. Peu importe le nombre de tests unitaires ou de régressions que vous aurez réalisé, il n’y a qu’un seul moyen de s’assurer que votre application peut encaisser la charge utilisateur à venir.
Le test de performance vous permet de valider la capacité de votre système à rendre le service attendu selon les hypothèses de charge formulées.

Les bases de la performance IT

Avant de plonger dans le monde du test de performance, prenons un peu de recul afin de bien comprendre la valeur ajoutée de cette pratique. A ce titre, j’aimerais vous rappeler les 3 composantes principales de la performance IT :

Les 3 composantes de la performance IT

• Application : C’est-à-dire comment est conçue votre application. L’expérience nous montre que les problèmes de performance viennent d’une architecture inadaptée ou d’un mauvais développement.

A quel besoin votre application est censée répondre ? L’implémentation est-elle adaptée pour répondre à ce besoin ? Les frameworks et design patterns en jeu sont-ils utilisés correctement ? Les composants sont-ils prévus pour monter en charge (scalabilité) ? Avez-vous identifié un Spof ou un goulot d’étranglement dans votre architecture ?

• Resources : On parle ici des infrastructures qui supportent votre application. L’expérience nous montre également que les problèmes de performance viennent d’un environnement mal dimensionné.

Comment assurez-vous la haute disponibilité ? Êtes-vous limité par la capacité réseau ou la virtualisation ? Votre infrastructure est-elle en mesure de supporter une forte charge sur l’ensemble de vos applications en même temps ?

• Load : Autrement dit la charge utilisateur qui sollicite votre application et donc les ressources sous-jacentes.

Avez-vous identifié les cas d’utilisation de votre application et les différents profils utilisateurs ? Quels sont les pics de charge que vous avez rencontrés ? Testez-vous une nouvelle application ou est-elle déjà en production ?

La stratégie du test de performance

L’application est impactée en production par les pics de charge élevés

Sécuriser la performance de votre application dans le temps est un véritable défi car il est difficile de prédire l’évolution de la charge en production. D’ailleurs, il est toujours possible de simuler un contexte dégradant les performances d’une application ou même la rendant indisponible. Vous faites donc face au risque que votre application rencontre une charge anormalement élevée et ne soit pas capable de l’encaisser. Cependant, vous avez la possibilité d’identifier les goulots d’étranglement en amont afin de prévoir un système hautement disponible et résilient.

Si vous envisagez de tester les performances, je vous recommande de considérer les deux phases suivantes :

• Load Testing : Ce test vous permet de valider vos exigences de performance pour une charge définie.
• Stress Testing : Ce test vous permet d’évaluer la capacité de votre système, ou l’un de ses composants, à encaisser la charge. Ce point est essentiel pour identifier les goulots d’étranglement et donc les actions à mettre en place pour dépasser ce palier.

Bien concevoir ses tests de performance

Intégration des tests de performance dans le cycle de développement

On parle souvent de deux approches :

• Shift left : Il s’agit de tester la performance de l’application en continu dès son développement. Cela permet de garantir la performance dès le départ et d’avoir une couverture de test complète. En concevant vos scénarios de test à la fin du processus, il est fort possible que vous en omettiez certains.
• Shift right : Il s’agit d’améliorer vos tests de performance à partir des observations en production. Ces informations sont précieuses pour construire des tests plus réalistes et ainsi tester la stabilité des futures versions en pratique des tests de non-régression. C’est également le moment de vérifier si vos applications et l’infrastructure ont besoin de quelques ajustements.

En intégrant les tests de performance à votre cycle de développement vous assurez une meilleure qualité des livraisons en détectant les problèmes au plus tôt.

Pour accompagner cet effort, je vous recommande de superviser soigneusement votre environnement. Ce point est essentiel afin de bien comprendre le comportement de votre système que ce soit en phase de test ou pendant son utilisation en production. Par ailleurs, cela permet de mesurer l’impact d’une application sur un composant mutualisé afin d’anticiper une éventuelle saturation.

La génération des jeux de données

La donnée est un élément clé durant l’exécution des tests de performance afin de simuler des scénarios utilisateurs réalistes. C’est pourquoi la constitution des jeux de données doit être considérée dès la phase de développement et à affiner dès les premiers retours de la production.

Lors de la conception de vos scénarios de test, identifiez le type d’activité que vous souhaitez simuler. Cela se déroule généralement en deux temps :

• L’initialisation : Il s’agit de la première utilisation de l’application, c’est-à-dire que la base de données n’est pas chargée et que beaucoup de créations seront effectuées.
• La campagne : L’application est prête à être testée de manière réaliste, c’est-à-dire que la base de données sera chargée (impact sur les performances) et que l’utilisation sera plus variée avec des consultations et des modifications en plus des créations.

Avant de générer vos jeux de données et de créer les dumps de base de données correspondants, assurez-vous que vos profils utilisateurs soient réalistes. Voici quelques conseils à garder en tête :

• Vérifier que les règles pour la génération sont correctes et exhaustives. Cela permet de tester l’application sans oublier les particularités fonctionnelles d’un scénario et qui peuvent impacter les performances de l’application.
• Varier les profils pour correspondre à la réalité. Les utilisateurs peuvent avoir un impact fort sur la base de données car ils sont rattachés à beaucoup de données. L’impact sur le cache est également différent s’il s’agit d’un nouvel utilisateur ou s’il revient sur votre site. En ce qui concerne les fichiers, variez leur nombre et leur taille afin d’en mesurer les impacts.
• Maitriser les contextes d’exécution pour rester consistant. C’est une bonne chose de mettre à jour ses jeux de données au fur et à mesure que l’application évolue, mais il est important d’utiliser le même contexte de test afin de mesurer l’impact en performance d’une modification.

Dans le cas où votre application est déjà en production, vous pouvez générer un dump de base de données à partir de la base de production. Cependant, assurez-vous d’être conforme RGPD en procédant à une anonymisation des données sensibles.

Pour cela, identifiez puis substituez ces données par des données de test. Si cette action a vocation à être récurrente, il est essentiel de l’automatiser par soucis d’efficacité. Cette méthodologie est la meilleure pour réaliser des tests vérifiant votre contexte de production.

La performance dans une démarche DevOps

Chez Leanovia nous constatons, pour la plupart de nos clients, que la performance IT n’était pas une priorité mais l’est devenu dès qu’un problème a fortement impacté leur métier. Heureusement, il existe des actions simples pour sécuriser l’avenir et mettre en place une stratégie de gouvernance de la performance dans une démarche DevOps.

Le coût de résolution des anomalies est moindre si elles sont détectées tôt

Si le sujet vous intéresse, voici quelques axes que je vous recommande :

Tests de performance

Trouver l’outil d’injection de charge répondant à votre besoin. Vous pouvez privilégier la simple performance de l’outil à générer plus de charge ou des fonctionnalités pour gagner du temps comme la corrélation des paramètres de framework.

Supervision et observabilité

Trouver l’outil de supervision adapté à votre contexte. Ce volet est indispensable pour analyser les résultats de vos tests de performance et les comparer aux observations de la production.

Performance en continu

Garantir la performance dès le début du projet. Une fois le processus maitrisé il est intéressant de capitaliser en automatisant les tests de performance. Bien entendu, tout n’est pas automatique dans la mise à jour des scripts, des jeux de données ou de la supervision.

Déploiement

Automatiser le déploiement de l’application pour une meilleure maitrise de l’environnement. L’expérience nous montre qu’une infrastructure permettant de restaurer facilement l’environnement de test est plus efficace et moins sujet aux erreurs humaines.

Un point intéressant si vous le pouvez est de conteneuriser vos injecteurs de charge afin de créer des instances à la demande sans se préoccuper des installations parfois laborieuses.

Jeux de données

Capitaliser sur les jeux de données de vos tests de charge pour vos tests de non-régression. N’hésitez pas à automatiser la génération des données en utilisant un outil approprié ou en développant des scripts pérennes si la structure de vos jeux de données est plus complexe.

En résumé, nous avons passé en revue les concepts de la performance IT ainsi que quelques clés pour correctement tester la charge de votre application. Comme vous le voyez, l’ingénierie des performances ne se limite pas à l’exécution des tests et requiert des expertises variées.

Si vous souhaitez que j’approfondisse un sujet, n’hésitez pas à me le faire savoir !