MilamberSpace - JMeter » HTTP

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

Milamber — Sun, 19 Jul 2009 19:30:11 +0000

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.

Compression HTTP, ou comment réduire le temps réseau dans les performances d’une application

Milamber — Sun, 06 Jul 2008 16:29:06 +0000

Avec JMeter on peut faire des tirs de performances (et d’autres choses) pour une application Web. Pour qu’une application soit performante, il est préférable qu’elle soit développée judicieusement, mais également qu’elle s’exécute sur un environnement performant. Dans ce dernier, il ne faut pas négliger la composante réseau qui peut souvent devenir un goulet d’étranglement au niveau de l’utilisateur.

En effet, vous allez développer une application hyper véloce, la faire fonctionner sur des serveurs hyper-rapides, mais votre utilisateur au bout de la ligne vous dit que c’est lent…

Vous (re)faites vos tir de charges, vous mesurez les performances, c’est excellent… sur votre réseau local. Vous placez un injecteur chez votre utilisateur final, et là c’est la surprise… c’est lent.

Le diagnostic est rapide : trop d’octets à transférer pour afficher un écran, avec une bande passante trop petite donc lenteurs. Et impossible d’augmenter la bande passante. Que faire ?

Bien entendu, il est possible (et il faut) optimiser ses pages HTML / XML, le taux de compression des images, etc. de son application. Tout ceci dans l’objectif de réduire le poids général en octets d’un écran.

Il y a aussi une astuce tout simple. La compression des données transitant entre le serveur Web et l’utilisateur final à travers la compression HTTP.

Cette compression basée sur l’algorithme des fichiers ZIP, est effectuée au niveau du serveur Web qui compresse à la volée les données à transmettre. Ensuite la décompression est assurée du coté des navigateurs Web.

Pour que cela marche, il faut bien entendu un navigateur récent (au moins IE 4.0, Firefox 1.0, etc) mais c’est le cas de tout le monde. Pour le serveur Web, il lui aussi doit être relativement récent (au moins IIS 5.0, Apache 2.x, etc). Il y a ensuite une configuration à faire à son niveau pour activer la compression.

Pour Apache, par exemple, c’est le module mod_deflate (et aussi mod_gzip) qui assure cette fonction. On peut ainsi ajouter dans son virtual host, les lignes suivantes (tirées que la documentation Apache) pour compresser tous les flux sauf les images.

# Insert filter

SetOutputFilter DEFLATE

# Netscape 4.x has some problems...

BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems

BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Don't compress images

SetEnvIfNoCase Request_URI \

\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Après le redémarrage du serveur Apache, le résultat donne, par exemple, pour la page d’accueil de ce blog (juste le contenu HTML) :

Avant, sans compression : 50 198 octets transférés
Après, avec compression : 11 903 octets transférés

Soit une diminution de 38 ko (-76%) à transférer sur le réseau ! C’est pas mal comme optimisation ? Et en plus c’est transparent pour tout le monde.

Ainsi, avec l’activation de la compression, les bons temps de réponses de son application ne seront pas masqués par les temps de transferts réseaux importants, et l’utilisateur au bout trouvera l’application rapide.

[Quelques pointeurs]