Tests de performances avec OpenSTA (1)

De nombreuses années d'expériences m'ont amené au constat suivant: une forte proportion des applications réceptionnées en production rencontre des problèmes de performance dans les premiers mois qui suivent leur déploiement. Les coûts induits annuellement se chiffrent en centaines de jours-homme.  Les tests constituent une approche pragmatique permettant, pour une application, en plate-forme:

• De Certifier sa disponibilité;
• De Valider sa fiabilité ;
• D’Etablir de façon aussi réaliste que possible,  ses performances;
• De Dimensionner l’Infrastructure requise pour sa mise en production.

Rappelons à cet effet que :

-L’audit transactionnel vise  à auditer les applications au niveau des transactions (Analyse du flux transactionnel, bande passante), à mesurer les performances applicatives sur le réseau.
-Les tests de  montée en charge, visent à reproduire une activité de production, à mesurer les temps de réponse du  côté utilisateur, à  mesurer l’utilisation des ressources systèmes des serveurs.

Les tests de montées en charge obéissent à une démarche qui peut être schématisée par la figure ci-dessous. Dans le cadre de cette démarche, l’Outil OpenSTA, qui ne s’applique qu’aux applications utilisant le protocole http, couvre les phases  3 (Elaboration des scripts de montée en charge)  et 4 (Exécution de la
 montée en charge).

 Examinons comment installer et mettre en œuvre l’outil OpenSTA, dans le contexte d’un  processus de test de montée en charge.

Les tests de charge permettent classiquement : 

•  La mesure des temps de réponse Utilisateurs ;
•  La mesure de la consommation des ressources systèmes (réseau et serveurs) ; 
•  Le calibrage du Système de façon optimale ; 
•  L’optimisation des applications.

Une  plate-forme de test va comporter : 

• Un poste utilisé comme conducteur, pour le pilotage des tests en temps réel et le recueil des mesures, et aussi comme genérateur de script (ScriptModeler) ;
• Un ou plusieurs postes utilisés comme injecteur (simulation des utilisateurs) .

Le poste utilisé comme conducteur héberge un repository comportant les scripts, la logique d’enchaînement des scripts, le recueil des mesures. La logique d’enchaînement des scripts, associé à un nombre d’utilisateurs, et à leur comportement  constitue un test. Dans OpenSTA, le conducteur est appelé TestCommander. Il est recommandé, pour des tests impliquant de nombreux utilisateurs, d’utiliser un repository unique, centralisé sur le conducteur (RepositoryHost). Ceci permet d’effectuer des test distribués (injection du scénario à partir de plusieurs postes).

Le conducteur capture un scénario et génère le script correspondant. Ce script, flux http,  peut être rejoué (injecté) par un poste injecteur.

 L’installation est à effectuer à partir des "sources" windows 32 bit, se présentant sous la forme d’un exécutable msi :

Installation

Double-cliquez sur le fichier d’installation .msi. Vous devez obtenir une image-écran du type :

Actionnez Next.

Le processus d’installation se déroule sans intervention particulière jusqu’à l’affichage de la fenêtre de fin d’installation.

Actionnez le bouton  Close  .

Redémarrez l’ordinateur.

OpenSTA doit être accessible à partir du menu Démarrer de Windows :

Anatomie de l’installation

OpenSTA a installé une arborescence comprenant  les sous-répertoires  suivants:

Répertoire	Contenu
BaseUI	Interfaces utilisateur : Script  Modeler, OpenSTAT Commander, etc
Common	Modules commun OpenSTA
Engines	Moniteurs/injecteurs  de test
Plugins	Modules utilises pour la présentation des résultants de tests
Repository	Référentiel des scripts, des tests et des résultants de tests
Server	Serveur CORBA mis en oeuvre par les différents modules

Configuration de base

Dans un environnement où plusieurs machines vont être utilisées pour produire de l a charge, openSTA devra être installé sur chacune des machines. Celles-ci doivent pouvoir communiquer. Le répertoire Repository de la machine principale sera utilisé comme référentiel central. La machine principale est celle à partir laquelle les tests seront lancés sur les autres machines

A partir du menu Démarrer,  sélectionnez l’option  OpenSTA Name Server. Une icône OPenSTA NameServer doit apparaître dans la barre des tâche de Windows :

Cliquez avec le bouton droit sur l’icône OpenSTA Nama Server de façon à faire apparaître le menu contextuel

Sélectionnez l’option configure :

Dans le champ Repository Host, entrez le nom de la machine  sur laquelle s’effectueront les tests : il s’agit de la machine courante.

Le champ Repository path  est lui, configuré sur OpenSTA Commander, à partir du menu Tools, option Repository path. Le Repository est toujours un répertoire sur  la machine courante. Pour des environnements destinés à supporter des tests importants, je recommande de placer ce répertoire à l’extérieur de l’arborescence d’installation d’OpenSTA

Le Repository défini est affiché dans le panneau  gauche :

Configuration d'un script

Lancez OpenSTA Commander à partir du menu Démarrer.

La configuration d’un script s’effectue en créant le script à partir du dossier Scripts et en double cliquant sur le script concerné, de façon à faire apparaître la fenêtre  de gestion de scripts : Script Modeler.

Gateway

Dans cette option, vous allez configurer le module de capture.

A partir du menu  Options/Gateway, sélectionnez l’option « console » pour visualiser les actions exécutées par OpenSTA. 

Selectionnez « Local », et cochez les cases « Automatic cookie generation » et « Page Timers »

Vérifiez que la machine sur laquelle s’exécute OpenSTA Commander ne comporte pas d’application utilisant  les ports 3000 et 81 (Apache par exemple). Pour vérification, ouvrez une fenêtre de commandes DOS et entrez la commande suivante :

Netstat –an

Vous devez obtenir un affichage du type de celui-ci :

Si l’un de ces ports est déjà utilisé (colonne « Adresse locale), vous devrez modifier  les paramètres Administration Port et/ou  Port du panneau Capture.

  

                                                                                                                                   

Le navigateur

A partir du menu  Options/Browser, sélectionnez le navigateur mis en œuvre sur le poste de capture.

  

Paramétrage du navigateur

Si vous travaillez dans un environnement  impliquant un proxy (Intranet d'Entreprise par exemple) , vous devrez, si votre profil le permet, ajuster la configuration de votre navigateur (Firefox, IE, etc...) , autrement, vous obtiendrez le message suivant lors de la demande de capture :

Lancez internet Explorer (ou tout autre navigateur), puis, dans le menu  « Outils », choisissez « Options Internet ».

Dans l’onglet connexion, actionnez le bouton « Paramètres réseau ».

Vous devez obtenir une fenêtre du genre :

Copiez l’adresse du script de configuration automatique et sauvez-la  de façon à pouvoir la restaurer après les captures de scénario de test.

Décochez la case intitulée « Utiliser un script de configuration automatique ».

Validez l’ensemble, puis fermez le navigateur.

Construction d'un test

Rappel du positionnement de OpenSTA

Dans le processus des tests, OpenSTA se positionne :

- Dans la capture des scénarii et l’élaboration des scripts ;

- Dans l’exécution des scripts.

Capture des scénarii et génération des  scripts

 La création des scripts s’effectue à partir du plan de travail d’OpenSTA Commander. Actionnez le bouton droit de la souris sur  Scripts et spécifiez un nom qui sera celui du script généré par la procédure de capture.

En cliquant sur le bouton droit de la souris, on peut aussi renommer, supprimer ou décrire un script.

Double-cliquez sur le nouveau script pour obtenir  la fenêtre du Script Modeler. Les principaux boutons de cette image-écran sont les suivants :

 Capture du scénario

 Re-jeu du scénario

  Arrêt de la capture

Pause de la capture

Actionnez le bouton rouge (« Record »). 

Vous  devez  obtenir un affichage  console du genre :

Puis la fenêtre  à partir de laquelle vous pouvez saisir votre URL d’un scénario de test.

Sur l’espace de travail OpenSta ScriptModeler, vous devez obtenir un écran du type de celui-ci.

Celui-ci comporte un volet présentant le texte du script généré (volet gauche).

Actionnez le boutonpour arrêter la capture.

Sauvegardez le script à partir du menu File/Save As.
Pour rejouer le script à titre d’essai, actionnez le bouton

Important : Un script rejoué à un instant donné doit correspondre à la version du logiciel applicatif qui a donné lieu à sa génération. Entre deux versions, l’applicatif peut, dans une transaction, envoyer des paramètres de signification différente. Exemple,  un numéro de session suivi d’un user Id et d’un mot de passe dans une transaction ;  Un numéro de session suivi d’une option de menu et d’un index d’une liste de choix dans une autre transaction. Si dans une version ultérieure l’application envoie deux index de listes de choix, le fonctionnement du script ne sera pas satisfaisant.

 La suite...

En examinant un script généré, on constate que celui-ci fait intervenir, dans les requêtes GET/POST, des constantes (identification de session par exemple), et des variables contenant des constantes (UserID, password, …) .

Rejouer le script tel quel ne serait pas réaliste : Si l’on voudrait simuler 5 utilisateurs, le script doit pouvoir envoyer 5 login différents au serveur ; d’autres valeurs envoyées au serveur doivent varier en fonction des utilisateurs, par exemple.

La « variabilisation » intervient à ce stade pour rendre le script dynamique. C'est l'objet de l'article consacré à la "variabilisation".