JMeter : attention à suivre ou non les redirections HTTP (code 302)

Un petit billet pour vous montrer un effet de bord de l’élément Serveur Proxy HTTP de JMeter.

Tout d’abord, voici un arbre JMeter qui va nous permettre de faire l’enregistrement d’une session de navigation.

J’ai choisi comme application modèle, l’un des exemples livrés avec Tomcat 6 : l’exemple de ressources protégées par un identifiant et mot de passe.

Donc si vous prenez un Tomcat 6 avec ses applications d’exemples, vous le démarrez et vous entrez cette adresse : http://localhost:8080/examples/jsp/security/protected, vous aurez cette page :

Le login et le mot de passe à saisir se trouvent dans le fichier conf/tomcat-users.xml de votre Tomcat. Donc on saisit les accréditations, pour arriver sur cette page :

Elle nous dit simplement que nous sommes bien connecté et identifié.

Maintenant, si on (re)fait cette session de navigation correspondant à ce scénario fonctionnel en utilisant l’élément Serveur Proxy HTTP, on va obtenir cet arbre dans le contrôleur Enregistreur :

Donc, on a trois requêtes (bien que l’on ait appelé un scénario de deux écrans : « formulaire de connexion », « page d’accueil connectée »).

Quand on regarde dans l’élément Arbre de résultats qui est situé en fils du Serveur Proxy HTTP, on trouve la raison des trois requêtes :

La deuxième requête est une redirection HTTP (code 302).

Ce qui se passe donc, c’est qu’une fois authentifié par le système, ce dernier envoi une instruction de redirection au navigateur (ici JMeter) pour lui faire afficher la page d’accueil.

Ok, maintenant voyons ce qui se passe si on reprend notre scénario JMeter et on l’exécute avec un groupe d’unités configuré à 1 utilisateur qui exécute une seule itération.

Dans l’arbre de résultats (celui rattaché au groupe d’unités du test), on voit les trois requêtes, et pour la deuxième requête, on trouve qu’elle correspond à deux requêtes, la première ([…]/protected/j_security_check) qui a retournée un code 302 (redirection) vers la page d’accueil connectée ([…]/protected/).

La troisième requête est la même URL que la requête de redirection provenant de la requête numéro 2. Ce qui signifie que le test automatisé de JMeter, dans ce cas, appelle deux fois la même URL au lieu d’une fois.

C’est un problème, car le nombre de requêtes attendu n’est pas le bon, de plus, dans un récepteur comme la Rapport consolidé, on trouvera que le temps de réponse de la requête numéro 2 est égale à 1/ l’exécution de la servlet j_security_check + 2/ l’appel à la page d’accueil connectée.

Comment résoudre ce petit soucis ? Deux moyens :

Le premier consiste, tout simplement à demander à JMeter de ne pas suivre les redirections (ne pas traiter les codes 302), pour cela, dans l’échantillon correspondant à la requête 2, il suffit de décocher la case « Suivre les redirections »

Ensuite à l’exécution du test, on a bien 3 requêtes (sans aucune ‘double-requête’). La requête numéro 2 donne bien une redirection, mais elle n’est pas suivie par JMeter. Et maintenant le temps de réponse de cette requête correspond bien à celui de l’exécution de la servlet j_security_check.

Une autre façon de solutionner ce problème est de tout simplement (aussi) supprimer ou désactiver la requête suivant la requête ayant la redirection. Donc la troisième requête doit être désactivée (ou carrément supprimée).

Ensuite à l’exécution, on a seulement deux requêtes, la deuxième correspondant au temps d’exécution de la servlet j_security_check et la page d’accueil.

Je sais, vous allez me poser la question (que je me suis également posé) : quelle est la meilleure méthode ?

Bien entendu, il n’y a pas de réponse miracle.

• Si on veut le détail des temps de réponses, au niveau échantillon (requête http), il est préférable de ne pas activer les redirections.
• Si le détail ne nous intéresse pas car la requête de redirection fait partie d’un ensemble de requêtes regroupées dans un contrôleur de transaction, et que l’on ne regarde que le temps consolidé, alors la deuxième solution (mais aussi la première) est bonne.

Voilà, donc attention aux redirections dans les scénarios de test qui ont été enregistrés via la fonctionnalité de Serveur Proxy HTTP de JMeter.

Un grand remerciement à Moncef, perfectionniste dans l’âme, qui a détecté ce problème dans un scénario, et m’a inspiré ce billet.

./