Créer des plans de tests de charge réalistes

En tout premier lieu, il faudra répondre à la question « Quels sont les enjeux ? ».
Car de la réponse dépendra en grande partie la stratégie qu'il faudra adopter.

Par exemple :

• résoudre des problèmes de performance d'une application ;
• dimensionner une infrastructure de production pour un déploiement national ;
• rassurer la DSI sur la montée en charge d'une application ;
• valider les performances/l'endurance/la robustesse d'une application ;
• comparer des solutions ;
• etc.

Il est très important d'identifier les scénarios pertinents et de les pondérer.

Pour définir ces scénarios, on peut :

• récupérer les statistiques de l'utilisation de l'application si elles existent (par exemple le nombre quotidien ou mensuel de transactions « métier », l'analyse des statistiques Web (access_log), etc.) ;
• définir avec les utilisateurs les scénarios majeurs d'utilisation (les fonctions les plus utilisées) de leur application (suites d'écrans et nombre d'utilisateurs).

Ces scénarios devront être :

• réalistes (écrans consultés, champs saisis dans les formulaires, temps entre chaque action…) ;
• importants.

Il y a trois types de scénarios à prendre en compte.

III-B-1. Fréquents▲

III-B-2. Vitaux▲

III-B-3. Risqués▲

Pour le nombre de scénarios, je préconise d'appliquer la loi de Pareto. Par exemple, en ne simulant pas différents navigateurs, différentes vitesses de connexion…

Ma deuxième préconisation est de faire une étude de risque afin de prioriser les tests. Cela permettra de choisir les tests en cas de réduction du planning (application livrée plus tard que prévu, serveur non disponible…).

Une fois les scénarios choisis, il faudra se poser la question du type de test que l'on veut exécuter.

En voici une sélection.

Le type de test choisi définira les paramètres du test (nombre d'utilisateurs simultanés, temps de pause entre chaque action, nombre d'itérations, etc.).
Une liste plus complète est disponible sur Wikipédia

Il est important de choisir des outils que l'on maîtrise.

Les critères de sélection sont :

• support de la technologie utilisée (HTTP, HTTPS…) ;
• type de licence (faire attention au prix qui peut augmenter rapidement si on a besoin de faire beaucoup de tirs (l'application n'est pas stable)…) ;
• simplicité pour la partie scripting et sa modification ;
• les contraintes de sécurité (impossibilité de monitorer certains serveurs…).

Ne pas oublier de faire un POC (Proof Of Concept) pour les valider.

Le test de charge consiste à simuler une utilisation réelle et voir si dans ces conditions l'application (ou le matériel) tient la route.
Pour cela il faut définir un certain nombre d'objectifs chiffrés et réalistes.

On peut classer ces objectifs en trois parties :

• critères utilisateurs :

  • temps d'affichage d'une page maximum acceptable ;
  • temps d'affichage d'une page en mode dégradé acceptable ;

• critères business :

  • nombre d'utilisateurs simultanés ;

• critères systèmes :

  • taux d'occupation CPU maximum ;
  • bande passante maximum ;
  • taux d'occupation mémoire maximum.

Si votre entreprise n'en a pas déjà, définissez-en.

Une fois les SLA définis, il faut regarder quels KPI mesurer.

Par exemple :

• temps de réponse ;
• nombre de requêtes par session ;
• taux CPU ;
• nombre de sessions en mémoire ;
• etc.

Et afin de pouvoir comparer nos résultats, il est utile d'avoir une base line.

Par exemple :

• KPI avec un seul utilisateur ;
• KPI de la version précédente de l'application.

Penchons-nous maintenant sur le côté matériel.

Il est important de tester les performances de l'application sur une configuration la plus proche possible de celle de production, bien qu'en raison du coût d'un tel choix, cela soit souvent compliqué.  Cette configuration devra être équivalente d'un point de vue matériel, logiciel (même version des logiciels), mais aussi d'un point de vue des données.
De plus il faut s'assurer de la disponibilité exclusive de l'environnement afin de garantir la fiabilité des résultats.

Pour les données, il est important d'avoir un jeu de données suffisant et de qualité. Si elles n'existent pas, il faudra les créer (par exemple avec une réplication de la base de données de production ou à l'aide d'un outil de création de jeux de données comme Benerator).
Si elles existent déjà, il faut faire attention à ce qu'elles correspondent bien aux futurs besoins (par exemple si les données pour la V1 existent et que l'on va tester la future version, il faut bien vérifier que cette nouvelle version aura bien le même volume de données).

Si l'application a des problèmes de performances avec seulement un utilisateur ou des problèmes fonctionnels, commencer la campagne de test sera une perte de temps.

Les tests doivent être les plus réalistes possible, mais il est important de ne pas devenir trop perfectionniste et de perdre du temps sur des détails sans importance.

Pour ne pas faire des tests inutiles ou mal interpréter les résultats des tests, il faut connaitre les limites hardware et software de la cible testée.
Par exemple si l'application ne supporte pas plus de dix utilisateurs en même temps (à cause de la licence, de limite fonctionnelle…), il est important de le savoir.
De même s'il y a des normes de sécurité (firewall…) qui empêchent certaines actions (installation de certains outils…).

En plus des limites de la cible testée, il faut faire attention à la partie hardware des injecteurs pour les mêmes raisons.

Et donc il faudra :

• monitorer les injecteurs ;
• utiliser toutes les machines disponibles.

Afin de contrôler les paramètres qui changent entre chaque test, il est important d'avoir une application stable techniquement et qu'elle soit figée (le code ne change plus). Sans cela il faut prévoir beaucoup plus de temps ou pire des interprétations des résultats faussées. 

Dans certains cas, il peut être nécessaire de faire appel à des spécialistes (administrateur base de données, administrateur système/réseau, développeur…).
Par exemple s'il y a de gros problèmes niveau base de données, réunir le développeur du module posant problème et du dba fera gagner énormément de temps.
Donc il faut prévoir ces spécialistes dans le planning et dans le budget.

Afin d'éviter de ne tester que les performances du ou des caches, il faut varier les entrées utilisateurs (valeurs dans les formulaires, identifiant/mot de passe…). Cela permet aussi d'avoir une couverture de test plus large, car il se peut que certaines requêtes (SQL…) dépendent des données en entrée.
Attention à ne pas trop diversifier les valeurs des entrées utilisateurs afin de se retrouver avec un cache inutile. Car il ne faut pas oublier que la gestion d'un cache a un coût et donc les résultats seraient faussés.

Par rapport au conseil précédent, dans certains cas il peut être utile d'utiliser régulièrement la ou les mêmes valeurs afin de tester les contentions possibles.

Pour chaque scénario, il faut identifier le type d'utilisateurs et leur ratio.
Par exemple pour un site d'achat il y a les visiteurs qui n'achèteront rien et les acheteurs. De même, il peut être utile de différencier les nouveaux utilisateurs et les autres, car cela a un impact sur le cache du serveur et du navigateur Web.

Le temps de réflexion (ou think time) est le temps entre deux actions de l'utilisateur.
Il faut trouver le juste milieu pour sa durée afin de refléter la réalité. Une durée différente et bornée pour chaque temps de réflexion est une bonne solution.
Attention à ce qu'il ne soit pas trop court, car les résultats du test seraient mauvais et on se retrouverait à essayer de résoudre un problème qui n'existe pas.

Attention au cas où l'application fait appel à un service extérieur (serveur de cartographie, serveur de validation du numéro de carte bleue…).

Et cela pour plusieurs raisons :

• se faire bannir par le service, car il se croit attaqué ;
• avoir des faux positifs ;
• etc.

Le « Ramp up » est la durée de la période de montée en charge des utilisateurs.

Il faut la choisir assez longue pour que le serveur ne s'effondre pas sous la charge. Car durant cette période des traitements lourds seront réalisés (augmentation de la taille des pools, compilation JIT par la JVM…) sur une période courte alors que dans la réalité, le serveur aura surement plus de temps pour traiter ce surplus de travaille.

Afin de laisser le temps aux caches de s'initialiser et de détecter plus facilement les fuites de mémoire/thread/connexions, il peut être judicieux dans certains tests d'avoir une durée de tests assez longue (temps variables en fonction de l'architecture).

Il est important de prendre en compte le nombre d'erreurs renvoyées par l'application afin d'éviter les faux positifs et de valider ou pas le test.
Par exemple pour le temps de réponse d'une page Web.

Si on ne tient pas compte des erreurs on se retrouve avec une moyenne de 8,33 ms alors qu'en réalité, si les erreurs correspondent à un « time out » et/ou à une impossibilité de l'application de répondre pour cause de surcharge, le temps de réponse est mauvais. Et donc on passera à côté d'un problème.

Dans certains cas il peut être utile de faire les tests avec différents navigateurs Web. En particulier lorsque le rendu de la page dépend du navigateur utilisé.
Par exemple, la vitesse d'exécution des scripts JavaScript dépend énormément du navigateur et de sa version. 

Toutefois une bonne gestion du cache peut diminuer le risque de ce problème et donc je pense qu'il est plus judicieux de traiter ce problème avec un outil du type PageSpeed, ou YSlow afin d'optimiser la gestion du cache et de réduire la différence entre les navigateurs.

Si une majorité des utilisateurs a un type de connexion (par exemple en 3G sur un téléphone), il peut être judicieux de tester l'application avec cette limite. Dans les autres cas, faire la même chose qu'au conseil précédent.