De la notion de corrélation dans les scripts




Lorsque l’on construit un script de simulation de charge, on peut avoir l’impression que le travail de corrélation des requêtes  est une tâche bien ardue. Et pourtant il existe de nombreux moyens pour nous simplifier la vie.

Pour illustrer ce propos, je vais m’inspirer d’un article (en Anglais) de Leonid Pekel, un expert Loadrunner de chez HPE, qui traite des différentes manières d’effectuer les corrélations avec l’outil Loadrunner.

Mais avant tout, quelques fondamentaux …

 

Pourquoi la corrélation ?

Après avoir capturé un script Web HTTP avec Loadrunner (ou un autre outil de charge), les entêtes et le corps des requêtes HTTP contiennent des valeurs qui sont enregistrées « en dures ». Or bien souvent – pour ne pas dire tout le temps – quand on rejoue ces trame de requêtes HTTP, elles tombent en erreur. Cela s’explique par le fait que chaque requête contient des informations dépendantes de contextes technique et fonctionnel uniques. En d’autres terme, certaines données transmises dans les requêtes sont périmées dès leur premier jeu (l’enregistrement).

C’est pourquoi, il faut rendre dynamique certaines données transmises au serveur dans les entêtes et les corps. Et pour déterminer quelles données rendre dynamique et quelles valeurs mettre à la place, on va passer par différents traitements et outils d’identification, d’extraction et de remplacement dynamique, on va effectuer une corrélation.

 

Les méthodes de corrélation

Sous Loadrunner, il existe tout un panel d’outils et de traitements pour gérer les corrélations. Certains sont dit « automatiques » tandis que d’autres nécessitent des actions utilisateur.

 

Corrélation automatique

Loadrunner est capable de détecter par lui-même les éléments de requêtes à rendre dynamique, et de mettre en place ces variables. On peut considérer trois types de corrélation automatique : Correlation rules, Record based et Replay based.

Correlation rules permet d’appliquer des corrélations à partir de modèles connus de structure d’échange de requêtes. Un certain nombre de règles sont déjà préenregistrées dans l’outil (GWT, PeopleSoft, Siebel, …). Mais il est aussi possible de créer ses propres règles.

La corrélation Record based intervient après l’enregistrement d’un script. Elle propose un choix de corrélations automatiques sur des champs identifiés en fonction de ce qui est communément transformé en variable et en fonction de l’utilisation des valeurs entre les différents échanges enregistrés.

Enfin, la corrélation Replay based peut être utilisée suite à l’enregistrement et le rejeu du script. L’outil va comparer l’échange de requêtes avant la détection d’un échec. Dans ce cas, il proposera des corrélations potentielles sur cet échange. Le processus sera à répéter jusqu’à disparition totale des KO.

 

Corrélation manuelle

Bien sûr, Loadrunner permet d’effectuer manuellement les corrélations qui seraient passées entre les mailles du filet des corrélations automatiques ou, pourquoi pas, des corrélations manuelle pour les « puristes » qui souhaiteraient tout faire par eux même :) Sous Loadrunner, on peut identifier trois approches de la corrélation manuelle : La corrélation par sélection, La corrélation à partir de Snapshoots et Le double enregistrement.

La corrélation par sélection est tout simplement l’intervention qui permet d’appliquer, directement dans le code, la corrélation de la valeur sélectionnée à partir du menu d’option (clic droit sur la valeur sélectionnée). Son application sera comparable à l’application d’un Record based.

La corrélation à partir de Snapshoots est opérée à partir de la log de la réponse serveur à partir du menu d’option (clic droit sur la valeur sélectionnée). Il sera alors possible de l’appliquée automatiquement aux autres occurrences dans le script.

Le double enregistrement est la comparaison de deux enregistrements du même processus métier (deux scripts) pour identifier les valeurs qui changent et qui sont donc à corréler.

 

Les fonctions de récupération des valeurs dynamiques

Toujours sous Loadrunner, pour récupérer les valeurs dynamiques dans les réponses serveurs, il existes différentes fonctions à placer avant l’appel de la réponse serveur ciblée et à choisir en considération de la méthode d’extraction identifiée. Celles-ci sont automatiquement positionnées lorsqu’on passe par des corrélations automatiques ou par le menu d’option.

web_reg_save_param_ex va permettre d’enregistrer une ou plusieurs valeur(s) dynamique(s) en fonction de bornes.

web_reg_save_param_regexp va permettre d’enregistrer une ou plusieurs valeur(s) dynamique(s) en fonction d’une expression régulière.

web_reg_save_param_xpath va permettre d’enregistrer une ou plusieurs valeur(s) dynamique(s) d’une réponse XML en utilisant une expression XPath.

web_reg_save_param_json va permettre d’enregistrer une ou plusieurs valeur(s) dynamique(s) d’une réponse en format JSON.

Pour les versions de Loadrunner antérieurs à la 10, les fonctions peuvent être différentes (web_reg_save_param, …).

 

Pour aller plus loin…

Je vous encourage à lire la documentation Vugen et ce lien qui a inspiré cet article.






A propos de l'auteur :

Expert dans le domaine de la performance, je porte un intérêt particulier à toutes les problématiques autour de la méthodologie, de l'organisation et de la métrologie des qualifications techniques.

1 commentaire pour cet article


N’hésitez pas à poster vos commentaires et questions 😉



Veuillez respecter ces quelques règles avant la publication de votre commentaire :

- Aucun message à caractère raciste, xénophobe, pornographique, diffamatoire ou homophobe,
- Evitez le langage SMS et les majuscules utilisées de façon abusive,
- Pas de warez, pas de P2P, pas de lien de téléchargement illégal.
- Enregistrez-vous pour commenter sans avoir besoin de remplir les champs.

Cet espace est aussi le vôtre, respectez-le !