Tests de performance au YaJUG

J’ai uploadé les slides de la présentation sur les tests de performance que j’ai faite au YaJUG fin Octobre.

Les présentations, la mienne, celle de Stéphane Landelle sur Gatling, et celle d’Antonio Gomes Rodrigues sur JMeter ont été filmées par le YaJUG et seront disponibles sur Parleys dans l’espace du YaJUG http://www.yajug.org/confluence/display/Public/Past+Events+2012.

A cette occasion je me suis rendue compte qu’on connait des petits trucs que les autres n’utilisent pas forcément.

Mon truc c’est d’utiliser les profils Firefox pour éviter la reconfiguration du proxy.

JMeter, comme la plupart des outils de test de charge, utilise un proxy HTTP pour enregister une séquence d’actions  que vous jouez dans votre navigateur et générer un squelette de scénario de test. Pour que cela fonctionne, il faut configurer un HTTP Proxy Server dans JMeter, puis aller dans la configuration du navigateur pour indiquer  le port du proxy et enregistrer le scénario. Si vous ne l’avez jamais fait, la procédure complète se trouve là http://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf

Première chose, le HTTP Proxy Server n’est pas toujours sur un port pratique. Il est par défaut sur le port 8080, ce qui est ennuyeux si vous avez aussi un Tomcat sur la même machine. Le navigateur trouvera bien quelque chose sur le port 8080, mais ça n’est pas votre proxy.

Une fois le port changé et les options de filtrage configurées, je sauve cet élément en utilisant « Save Selection As … ». Ceci permet de le réimporter plus tard en utilisant la fonction « Merge » dans le menu. Donc voilà, mon port est 4567.

 

Ensuite, il faut créer un profil dans Firefox qui passera toujours par Proxy sur le port 4567.

Il faut activer le Profile Manager car il n’est pas actif par défaut. La procédure varie selon les OS. Pour MacOSX, la procédure se trouve ici, pour Windows il faut ajouter -ProfieManager à la fin de  la ligne de commande du raccourci.

Au prochain démarrage, Firefox vous proposera de choisir un des profils existants et vous pourrez créer un profil JMeter.

Il y a un autre intérêt à passer par un profil spécifique. Vous laisserez ce profil vierge de tout add-on et vous éviterez ainsi de devoir configurer des filtres au niveau du proxy pour ignorer les requêtes émises en continu par ces extensions.

La prochaine fois, il n’y a plus rien à faire. Vous importez l’élément HTTP Proxy Server sauvegardé, vous le démarrez, vous lancez Firefox avec le profil JMeter et tout marche.

Publicités

Petit tour des nouveautés Jakarta JMeter 2.4

La version 2.4 est une version majeure qui apporte quelques fonctionnalités et corrige plusieurs bugs.
Côté scripting Web pas de changement profond :
  • le proxy d’enregistrement a maintenant une vrai gestion des sessions HTTPS. En 2.3, il faisait du spoofing, ce qui marchait dans la plupart des cas, mais pas toujours. Par ailleurs, il fallait penser à changer le protocole pour http: et souvent on oubliait ce détail et on galérait longtemps.
  • l’option par défaut du HTTP Redirect change. La valeur par défaut n’est plus « Follow Redirects » mais « Redirect Automatically » pour permettre la capture des cookies placés pendant les redirects. Cela n’affecte pas les scénarios existants, seulement les nouveaux HTTP Samplers
Attention pour les gens qui aiment les sasfepu, JMeter nécessite maintenant Java 5.
Les évolutions ont plutôt porté sur les autres protocoles et l’outillage :
  • l’ajout de protocoles mail supplémentaires
  • des améliorations sur le protocole JMS (support des Topics et des Queues et en Publish/Subscribe et corrections de bugs)
  • le support des samplers en JUnit4
  • l’intégration de la JSR 223 – Scripting for the JavaTM Platform
  • l’amélioration des listeners qui reportent les résultats (ResultTree, outils de statistiques)
La liste complète des changements et des corrections se trouve sur la release note http://jakarta.apache.org/jmeter/changes.html
Passons à l’expérimentation
Toujours le même problème de menus à moitié en anglais et à moitié en français si on choisit la langue anglais sur un OS en français.
Enregistrons un script vite fait pour une recherche sur Google. Le proxy d’enregistrement, n’a pas changé. Le script généré non plus.

view Results Tree - réponse en affichage texte

Une nouvelle assertion la Comparison Assertion qui permet de lever une erreur s’il y a un écart trop grand entre un relevé initial de référence et les suivants, sur la base du contenu ou du temps de réponse.
Quelques surprises du côté du view Results Tree (arbre de résultats). Tiens au passage changer la langue fait un clear des résultats. Heureusement que mon test dure 10s.
Un nouveau mode d’affichage du résultat du sample en tableau (mode décodé ou parsed en anglais).
Pas de changement pour la requête.
Pour la réponse, une fonctionnalité de recherche dans le résultat a été ajoutée.  Elle permet de rechercher un texte dans le résultat en mode exact ou en expression régulière (voir schéma ci-dessus).

view Result Tree - réponse en HTML

Bon , là  je me suis demandée pendant un bon moment où était la case à cocher pour afficher en HTML, parce que quand même c’est pratique pour vérifier ce qu’on a reçu.
En fait, le sélecteur à été déplacé sous la liste des samples. Il permet de choisir entre HTML, JSON, XML, texte brut et un testeur de RegExp (schéma à droite). Attention, les fichiers manipulés et générés sont stockés dans le répertoire où est lancé jmeter. C’est un peu le bazar à la longue.
Tiens, tiens, un évaluateur d’expressions régulières. Ce truc là devrait être bien pratique pour tester les expressions régulières des assertions et des extractions de texte dans les résultats sans aller chercher des outils externes comme QuickREx.

Testeur d'expressions régulières

Les Aggregate report et Summary report ne semblent pas avoir changé, ni la vue tableau. JMeter annonce des optimisations de consommation de ressources sur ces composants. Je n’utilise jamais les autres vues car je ne suis jamais en mode GUI pendant les tests et je fais toujours les stats et les courbes avec R à partir du log.
Que fait le nouveau listener JSR 223 ? Il permet d’utiliser du code de script dans le traitement des résultats. C’est l’équivalent des listeners BeanShell et BSF mais en plus standard, avec le support de plus de langage et en particulier Groovy.
Vous trouverez là un article très complet sur le scripting dans JMeter en JSR 223 dans les différents composants et les prérequis : http://blog.zenika.com/index.php?post/2009/07/29/INTEGRATION-DU-SUPPORT-DU-JSR223-DANS-JMETER
J’ai aussi trouvé un autre article en français sur JMeter 2.4 en cherchant des informations sur la JSR 223 dans JMeter. Il est plus général et couvre certains aspects que je n’ai pas couvert parce que je ne les utilise pas en ce moment : http://blog.milamberspace.net/index.php/2010/07/14/apache-jmeter-2-4-est-sorti-694.html
Le format d’enregistrement des résultats en mode non-gui est resté identique.
<?xml version="1.0" encoding="UTF-8"?>
<testResults version="1.2">

<httpSample t="207" lt="57" ts="1279471780513" s="true" lb="/search" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="54101"/>
<sample t="1209" lt="752" ts="1279471780049" s="true" lb="Contrôleur Transaction" rc="200" rm="Number of samples in transaction : 8, number of failing samples : 0" tn="Thread Group 1-1" dt="" by="190509"/>

</testResults>

Si cet article vous a intéressé, vous trouverez ici d’autres articles de ce site qui peuvent vous intéresser

Présentation JMeter



Le 25 mars 2010, j’ai fais une présentation dans le cadre des cours du soir Valtech.

Le but était de présenter JMeter (des gens ne savent pas qu’on peut enregistrer un scénario avec JMeter), mais aussi de comprendre les pièges qui influent sur la pertinence et la communication des résultats des tests de performance.

Les slides utilisés pendant le cours sont en Creative Commons sur SlideShare.

Utiliser Redmine pour gérer les tests de performance

Redmine (http://www.redmine.org/) est un outil open source qui se présente lui même comme une application Web de gestion de projet.
redmine
Redmine est par défaut orienté développement.
Les demandes que l’on peut gérer sont des évolutions ou des anomalies. Mais il est très facile de créer de nouveaux trackers pour créer des demandes qui concernent des opérations à réaliser sur la plate-forme de test ou des épreuves de test afin d’adapter le vocabulaire et les attributs.

Un outil de rapport permet d’afficher les demandes en filtrant les données selon les trackers et les attributs et de décider des colonnes à afficher. Les demandes qui ont une date de début et de fin sont présentes dans des vues calendrier ou gantt. Il est aussi possible de faire une gestion du temps passé sur ces demandes et de faire des synthèses.

L’outil est bien adapté aux petits projets que sont les campagnes de tests de performance.

Redmine permet de partager via un site Web toutes les informations qui contribuent à un projet de test :
– les documents de spécification ou des rapports via l’onglet document
– des informations de statut au jour le jour via les annonces
– des informations plus permanences sur les tests réalisés, les informations techniques peuvent être notées dans le wiki
– les résultats de test générés sous forme de pages Web peuvent être déployés dans la partie Web statique et référencés dans le wiki

Redmine a aussi quelques fonctions d’intégration intéressantes.
– il permet de gérer une liste de participants et d’envoyer automatiquement des mails via les annonces, lorsque des demandes sont crées ou changent,
– il permet de s’interfacer avec des SCM tels que Subversion pour partager des sources d’utilitaires ou de script
– il existe des plug-ins qui permettent de s’interfacer avec des outils d’intégration continue qui peuvent être utilisés pour générer automatiquement certains documents

En fait j’ai décidé de tester Redmine après une campagne de test ou les participants étaient sur 5 sites en France et en Belgique et où je constatais que je passais une bonne partie de mon temps à renvoyer des informations de planning, des documents et des fichiers de suivi excel par mail à des gens nouvellement arrivés sur le projet ou remplaçant quelqu’un.

Ce qui m’avait arrêtée jusque là pour utiliser des outils comme Trac c’était le temps nécessaire pour installer l’outillage. Je fais des campagnes sur des sites différents à chaque fois et je préfère voyager léger.

Alors pourquoi Redmine ?

Parce que c’est du Rails. InstantRails s’installe (enfin se dézippe) dans le bon répertoire en quelques minutes. Une fois copié l’application rails Redmine dans le bon répertoire, on démarre InstantRails, on lance deux scripts pour créer la base et l’initialiser et l’application est accessible. C’est magique !

Il faut environ une demi journée pour avoir en place les utilisateurs, les sous projets, les trackers spécifiques et les tâches de base … et beaucoup plus de tranquillité par la suite pour se concentrer sur les tests.