Animateurs : Arnaud Fontaine et Karim CAdi (Unilog Rhônes-Alpes) (Centre de compétences)
Encore des personnes avec qui nous travaillons !
Enjeux et objectifs :
- évaluation d’une nouvelle technologie ou d’une solution d’architecture,
- sur un projet, analyser les conditions de pic de charge et les contraintes de disponibilité,
- ou encore, évaluer une architecture hétérogène.
L’analyse de la performance au sein du cycle projet :
- en phase de prototypage : sizing a priori
- en phase de développement : profiling pour anticiper les problèmes de performance
- en phase de recette : nouveau tests de charges afin de valider/optimiser le sizing cible.
Aujourd’hui, sur le marché, trois offres sont en concurrence :
- les solutions open source : des outils variés et incomplet, aux coûts d’acquisition très faibles, mais à réserver pour des profils très techniques.
- les offres commerciales : des produits très (trop ?) complets, si coûteux, que bien souvent on se limite à une location le temps des tests, qui nécessite de faire appel à du consulting de haut niveau, en résumé, des solutions qui manquent de souplesse.
- enfin, Microsoft, qui s’est logé comme à son habitude dans une niche, celle des middle actors : prise en main rapide, coûts intermédiaires, pour des fonctionnalités moindres que les offres commerciale,s mais mieux packagées que les solutions open source.
Visual Studio Tema Suite Developper et Tester permet différents types de tests de charges :
- tenue de l’application en charges (analyse du comportement sur plusieurs jours pour vérifier si des dégradations n’apparaissent pas au cours du temps, fuite de mémoire, etc …)
- stress de l’application (sur une charge cible et un peu au-delà)
- test de capacité (clcul du nombre d’utilisateurs en fonction des temps de réponses et des machines)
Dans VSTS Tester, pour mettre en œuvre un test de charge Web :
- création d’un projet de test Web
- enregistrement du scénario de navigation
- problème : les appels asynchrones (Ajax) ne peuvent pas être enregistrés
- pour y remédier, il suffit d’utiliser l’outil Fiddler qui enregistre les appels Javascript
- ensuite, on diversifie les requêtes à partir d’une base de données afin de simuler l’appel du même scénario par des utilisateurs différents qui ne naviguent pas sur les mêmes produits, par exemple.
- le script est modifié afin de mapper le code enregistrer au contenu de la base de données, en précisant un mode aléatoire, pour être encore plus réaliste.
- on spécifie ensuite le pattern du test : nombre d’utilisateurs constants ou augmentation par palier
- enfin, on distribue les navigateurs (ils n’ont pas tous les mêmes temps d’actions), les réseaux (un modem stressera moins l’application qu’un très haut débit), et même le « think time » des utilisateurs, c’est-à-dire le temps qu’il faut à l’internaute pour comprendre ce qu’il doit faire sur la page qu’il a sous les yeux.
L’utilisation de l’outil est très aisée. Mais attention à la méthodologie, en particulier, ne pas modifier tous les paramètres en même temps.
Au départ, bien définir les hypothèses :
- ventilation des scénarios fonctionnels (avec l’aide de la maîtrise d’ouvrage)
- la navigation
- la bande passante (ADSL, LAN, 56K)
Effectuer un test étalon :
- fiabiliser les tests de références (être sûr qu’il fonctionne !)
- vérifier la reproductibilité de la procédure de test (si trop d’écart, il est nécessaire d’affiner, d’allonger la durée de test, d’une manière générale, il ne faut pas compter les 2 à 5 premières minutes du test)
Définir les conditions préparatoires avec soin :
- « think time » ou « think profile »
- % de nouveaux utilisateurs
- simulation du cache du navigateur côté client (avec ou sans cache, des variations de 30% peuvent être constatées)
Plan de test : une stratégie d’exploration :
- ne faire jouer qu’un paramètre libre à chaque fois,
- pas d’analyse en cours de campagne (il faut bien définir le test avant le début de la campagne)
Quelques tips appris sur le tas :
- dans le dimensionnement de la plateforme de test : isoler les agents et le contrôleur, limiter la consommation CPU en dessous de 80% côté agents, au-delà, de gros effets de bord apparaissent
- recours à la virtualisation : cela impose de comprendre la liaison entre le hard et le virtual server, et de penser (et comprendre) l’allocation de ressources (exemple : deux serveurs en cluster)
- isoler la plateforme de test du réseau de l’entreprise !
Etude de cas :
- virtualisation de 6 machines : 1 client (le VSTS Tester), 2 agents, 1 contrôleur (avec SqlServer 2005), 1 puis 2 serveurs cibles.
- objectif : 2000 utilisateurs
- premier test : au-delà de 120 utilisateurs, les requêtes non servies croient de manière exponentielle.
Synthèse :
- pour un architecte, les tests de charge peuvent être monter rapidement, une demi-journée de mise en place peut être suffisante
- penser à la virtualisation des environnements
Pour de la pré-production, l’outil parait encore jeune par rapport à l’offre concurrente :
- pas de simulation depanne
- profil de montée en charge basique
- capacité d’analyse assez faible
- mais l’ouverture du produit permet d’y ajouter de nombreux plug in.
Commentaires