Je sors la tête de l’eau, cela fait un moment que je n’ai pas pu écrire un billet (la faute au boulot bien sûr, et peut-être un peu de paresse -non, je confirme, c’est le boulot-).
Une nouvelle version de JMeter vient de sortir, il s’agit de la version 2.3.2, c’est une petite mise à jour qui apporte des corrections de bugs et quelques améliorations.
Parmi les nouveautés notables :
- Le fichier de l’élément CSV Data Set Config peut maintenant être partagé à différents niveaux : pour tous les thread groups, par thread, par identifiant. Ceci permet d’avoir un seul fichier utilisé par plusieurs threads avec une lecture des données identiques et dans le même ordre.
- L’élément Response Assertion peut être utilisé pour tester la présence d’une chaîne (substring) dans la réponse.
- Un nouveau bouton apparaît dans les éléments de rapport Summary et Aggregate pour permettre la sauvegarde dans un fichier CSV des données affichées (et calculées) de ces rapports.
- Dans l’élément View Results Tree, le rendu XML des réponses utilise la bibliothèque Tidy.
L’ensemble des changements est visible ici.
./
Je débute dans le domaine des tests de charge et j’aurai voulu savoir si la dernière version de JMETER prenait en charge l’IP spoofing ( la capacité depuis un injecteur de simuler plusieurs @IP de plusieurs clients virtuels). Autre question je suis à la recherche d’un tutoriel qui permettent de mettre en place une solution entièrement avec Jmeter solution basée sur un conducteur et n injecteurs.
Par avance merci
Non, il n’y a pas de trace de possibilité de faire de l’IP spoofing au niveau des injecteurs (tant au niveau de l’interface graphique de Jmeter que dans son code source), ce qui est bien normal.
En effet, l’IP spoofing n’est pas (à ma connaissance) de nature à permettre le retour des paquets IP ce qui ne permet donc pas la mesure des performances.
Je suppose qu’il vaudrait mieux parler d’IP Aliasing (la capacité donné par le système d’exploitation à avoir plusieurs IP sur une même carte réseau (réponses ARP (même adresse MAC) indiquent pour plusieurs IP sur la même machine), mais là encore, JMeter ne gère pas l’adresse IP « sortant » (l’interface réseau à utiliser) pour lancer la requête (il utilise les API Java standard pour la couche réseau niveau TCP/IP)
Pour finir, je ne vois pas le besoin de simuler plusieurs adresses IP pour un même robot injecteur pour faire un tir de charges, à moins que tu souhaites tester un mécanisme de contrôle basé sur l’adresse IP (genre nombre de licence simultanée ? mais il serait défaillant car un bête proxy pourrait le contourner).
Pour le tutoriel sur les tests à distances (contrôleur+injecteurs), il faut que j’en fasse un!
En attendant tu peux voir (en anglais) :
http://jakarta.apache.org/jmeter/usermanual/jmeter_distributed_testing_step_by_step.pdf
ou carrément la documentation Jmeter :
http://jakarta.apache.org/jmeter/usermanual/remote-test.html
A+
Merci pour les infos (c’est bien d’IP Aliasing que je voulais évoquer). Certains loadbalancer (répartitieurs de charge) et selon l’algorithme choisi, effectuent leur répartition de charge selon l’@IP source du client. Si l’on dispose d’une seule IP source on sollicite toujours le même serveur web et serveur d’application alors que l’application que l’on a à tester dispose d’une grappe de serveurs.