Comment préparer un test de charge

Lorsque l’on veut réaliser un test de charge la première étape est de définir une date (logique, vous me direz…). L’idéal, c’est de préparer correctement cette journée de façon à ce que tout se déroule pour le mieux et qu’il n’y ai pas de mauvaises surprises. Voici, d’après mon expérience, une liste des petits détails à valider et à prendre en compte avant le jour J. Je n’ai pas la prétention de dire qu’elle est exhaustive, mais elle peut vous donner un point de départ pour vos tests.

1.     Définir les objectifs que l’on veut atteindre

Réaliser un test de charge sur une application distribuée ne doit pas être fait à l’aveuglette. Il est préférable d’avoir un objectif que l’on souhaite atteindre et qui va orienter le test, le type de charge, et les indicateurs que l’on doit suivre.

Personnellement, j’identifie 4 objectifs parmi ceux qu’on  retrouve généralement :

-          Déterminer les capacités de l’application

Ce type de test a pour but de déterminer la charge que peut supporter l’application dans son état actuel. Il permet notamment :

o   D’établir un ensemble de mesures de référence pour les futurs tests

o   D’identifier de potentiels problèmes et pistes d’amélioration

 

-          Déterminer l’origine d’un problème identifié en production

Très souvent, un test de charge est exécuté pour identifier l’origine d’un problème de performance identifié en production. On va alors mettre en évidence les composants de l’application qui sont à l’origine de ces problèmes de performance.

-          Valider une intervention en termes d’amélioration des performances

Lorsque l’on à mis en évidence un problème de charge, s’ensuit une tentative de correction éliminant ce problème. Avant de valider cette modification et potentiellement de la déployer, on va effectuer un test de charge qui assurera que la correction est efficace. En général, on utilise le même test que celui ayant révélé le problème.

-          Dimensionner une architecture matérielle par rapport à un objectif de charge

Même si le plus souvent un problème de performance peut être résolu de manière applicative, on arrive toujours à un moment ou les performances dépendent des capacités matérielles de la machine hébergeant l’application. Réaliser un test de charge sur plusieurs architectures matérielles différentes permet de déterminer laquelle sera la plus adaptées pour la production, suivant l’objectif de charge à atteindre.

On peut bien entendu avoir plusieurs objectifs, l’idéal étant de ne pas en avoir trop lors de chaque test. Cette liste n’est pas exhaustive, on pourra retrouver d’autres variantes, celles-ci dépendant de l’application que l’on mesure. Vous pouvez imaginer vos propres objectifs, mais gardez-les à l’esprit et tenez vous-y au cours du test.

2.     L’application doit être testable

Loin d’être un détail, la testabilité de l’application est un des pré-requis les plus importants ! Très souvent ignoré, il est pourtant vital pour la bonne marche de votre journée de tests.

Comment déterminer si l’application est testable, me direz vous ? C’est une simple question de logique. Si l’application ne répond pas dans des temps acceptables lorsqu’un seul utilisateur la consomme, comment pourrait-elle supporter une charge importante ? Si certaines pages d’un site web échouent une fois sur deux dans tous les cas, à quel point les indicateurs relevés seront-ils pertinent ? Si le processeur du serveur de base de données est consommé à 100% avec 2 utilisateurs, est-il vraiment nécessaire de faire un test de charge ?

Bref, je pourrais citer un nombre impressionnant de cas pour lesquels il est logique qu’un test de charge est inutile. L’idée est simplement de faire preuve de bon sens et d’attendre une certaine maturité du développement avant de pouvoir tester les performances d’une application.

Par contre, je préconise toujours de tester la charge le plus tôt possible lors du processus de développement. Même si l’intégralité de l’application n’est pas testable, on peut toujours se concentrer sur les composants qui le sont.

3.     L’environnement à tester

Réaliser des tests de charge, ça implique d’avoir du matériel disponible pour réaliser ces tests, et uniquement pour cela. Il faut à tout prix éviter d’exécuter des tests sur une machine utilisée en parallèle par d’autres applications. C’est logique, mais pas toujours évident pour tout le monde. Dans le pire des cas, on peut utiliser une telle machine, mais s’assurer qu’aucune autre application ne viendra polluer les résultats.

Pour avoir des résultats utilisables et pertinents, il faut que les mesures soient faites sur un environnement identique à celui qui accueil(lera) l’application en production. Sinon, on peut par exemple ne pas atteindre les objectifs en termes de charge sur une machine ayant 1 processeur alors que tout se passerait bien sur une machine possédant 4 processeurs en production.

Attention par contre : n’effectuez jamais de test de charge en production ! Encore une fois, c’est tellement logique que j’ai du mal à comprendre qu’on puisse même se poser la question… Le seul cas ou c’est envisageable, c’est lorsque l’application n’est pas encore en production et que les futures machines sont disponible et pas encore utilisées. Mais c’est le seul cas !

Côte logiciel, l’application à mesurer doit être déployée et prête avant le jour J. Si besoin, la base de données doit être remplie, et le tout configuré pour les tests. La seule chose dont on doit se préoccuper le jour des tests, c’est des tests en eux même.

Très souvent lors d’une journée de tests, on a besoin d’en exécuter plusieurs dans les mêmes conditions logicielles (même configuration, mêmes données d’origine). Hors, suivant les scénarios exécutés, la base de données peut être modifiée. L’idéal est de pouvoir très facilement et surtout très rapidement remettre en place l’environnement tel qu’il était à l’origine. Cette problématique arrive très fréquemment au niveau des données dans la base. Vous pouvez pour cela utiliser un mécanisme de backup/restore, ou même de snapshots disponibles avec SQL Server qui permettent de revenir rapidement à un état de la base de données.

4.     L’environnement de test

Tout comme l’environnement à tester, l’environnement de test doit être prêt à l’avance. Suivant le type et la quantité de charge que l’on veut simuler, il faut déterminer le nombre d’agents à utiliser et donc de machines à configurer. Une machine standard peut, avec un agent Visual Studio Team Test, simuler environ 700 utilisateurs. Bien entendu, ce chiffre dépend de la complexité des tests que vous réalisez et souvent, on préfère parler en termes de requêtes par secondes que de nombre d’utilisateurs.

Un test de charge sans indicateurs à analyser, c’est comme une journée sans café : ça ne sert à rien. Très souvent, on ne pense pas aux indicateurs à suivre avant d’exécuter le test. Hors c’est vital pour que l’analyse soit de qualité. Il faut bien les choisir en fonction de ce qu’on veut mesurer. Dans Visual Studio, il s’agit des compteurs de performance Windows des machines que l’on test. Il faut s’assurer à l’avance qu’on peut les récupérer à partir des machines de l’environnement de test.

Il peut également être intéressant d’exécuter une première fois le test de charge avant le jour J avec une charge faible (constante à 1 utilisateur), pour s’assurer que tout se passera bien lors des tests.

 

En conclusion, le plus important est de prendre le temps de préparer cette journée à l’avance et de bien réfléchir à tous les aspects avant de se lancer dans l’aventure J Créez vous une check-list pour ne rien oublier et travailler sereinement.

.Dispose() ;

Publié mercredi 17 septembre 2008 09:00 par Etienne Margraff
Classé sous ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01