Catégorie : JMeter

Deux nouvelles

Voici deux nouvelles :

La version 2.9 de JMeter est cours de préparation, la release candidate 3 est en cours de vote, mais je sens qu’il y aura une RC4 avant. Vous pouvez d’autres et déjà regarder les nouveautés sur ce lien (anglais).

Coté travail, j’ai eu la chance de mettre en place une mini-infrastructure prototype de « cloud » avec la solution CloudStack d’Apache. Je dois continuer en testant également OpenStack. Le but étant de tester des solutions de cloud open source pour en choisir une et la déployer sur une demi-douzaine de gros serveurs hôtes (et deux de plus pour la gestion du cloud) afin de faire un « cloud privé ».

Quelques nouvelles pour ce mois de novembre

Je vois que cela fait longtemps que je n’ai pas écrit un billet sur le blog !

Je corrige, et je vous donne quelques nouvelles.

D’abord, je bosse doucement sur l’intégration de Apache Tika dans Apache JMeter. C’est opérationnel, mais je suis dans le peaufinage de son intégration dans JMeter, et là (en ce moment) je suis occupé, donc c’est en stand-by. L’idée de l’intégration de Tika dans JMeter est de permettre à JMeter d’extraire depuis de nombreux formats de « documents/médias » le texte contenu à l’intérieur dudit document.

Les formats supportés sont Microsoft Office (97/2003 et OpenXML pour les fichiers Word, Excel, PowerPoint), Apache OpenOffice/LibreOffice (OpenFormat, pour les fichiers Writer, Calc et Impress), Adobe PDF, HTML, Mbox, mais également les médias de type MP3, Flac, Mp4, FLV, OGG, etc. Continuer la lecture de Quelques nouvelles pour ce mois de novembre

Apache JMeter 2.8 est sortie

Et voilà ! un nouveau millésime d’Apache JMeter.

Dans les changements notables, on a :

  1. La nouvelle option « Créer les unités seulement quand nécessaire » qui vous permet d’avoir des centaines de milliers d’utilisateurs virtuels exécutant un scénario de « courte durée » c’est-à-dire genre 1 itération. Le tout avec une montée en charge de longue durée. Et ceci sans avoir besoin d’une machine de compétition.
  2. Dorénavant c’est l’implémentation Apache HTTPClient 4 qui sera utilisée par défaut pour les requêtes HTTP.
  3. Un nouveau graphique fait son apparition : le « Graphique évolution temps de réponses », qui vous permet comme son nom l’indique d’avoir une courbe des temps de réponse par rapport au temps. Je pense que l’on peut dire que l’on a (enfin) un ‘beau’ graphique dans le JMeter natif.

Une petite capture :

./

Interview de Stéphane Hoblingre, développeur et committer du projet JMeter Plugins

Avec un-beaucoup de retard, je vous propose de lire cette interview de Stéphane Hoblingre, développeur et committer du projet JMeter-Plugins.

C’est encore une récidive du blog Aliecom, qui porte à 3 les interviews des personnes qui gravitent autour de Apache Jmeter.

Bonne lecture.

 

PS. La release candidate 1 de Jmeter 2.8 est sortie.

Test de performances et analyses avec WebSphere Application Server (et JMeter)

Un petit billet pour pointer sur cet article Performance testing and analysis with WebSphere Application Server, qui décrit comment faire un test (simple) de charge avec Apache JMeter sur une application J2EE hébergée sur un serveur WebSphere Application Server, puis comment procéder pour recherche le goulot d’étranglement avec les outils internes à WebSphere et d’autres outils IBM.

Ce n’est pas le premier billet qui utilisent JMeter sur le site IBM developerWorks, mais j’aime toujours ce type de billet, car d’une part, moi aussi j’utilise JMeter pour ce genre de test, mais également je travaille régulièrement sur des architectures WebSphere (définition, mise en place, recherche de cause de problème et bien entendu tests de charge :-)).

Noter aussi que dans ce billet, la recherche du point de saturation est faite d’un point de vue « débit » (throughput – cf. Figure 7)) sur une seule requête, et non temps de réponses « trop grand » comme généralement dans les tests de charge de site Web.

Passage à Debian 7 (testing), nom de code Wheezy

J’ai fait l’acquisition d’un disque dur de 1 Téra-octet pour remplacer le disque de 500 Go de mon ordinateur portable (le fameux Dell E6500). Et oui, l’espace disque se remplit vite avec des machines virtuelles, les fichiers ISO des quelques distributions Linux que je manipule (Debian, Ubuntu, Centos et RedHat) dans le travail et tout le rester (applications, documents, photos, vidéos, etc.)

Tout cela pour dire que j’ai profité de la migration vers ce nouveau disque pour passer à Debian Wheezy, la future version 7 (dépôt testing donc).

La version testing a été gelée fin juin 2012, donc plus de montée de version majeure des logiciels dans ce dépôt, la priorité est donnée à la correction des anomalies en prévision de la version finale prévu fin d’année ou début 2013. Noter que (il me semble) : une version testing gelée de Debian est plus stable qu’un Ubuntu venant de sortir.

Et donc, me voilà avec Gnome 3 et son gnome-shell qui vient bousculer ma façon de « voir » mes applications quand je travailler sur l’ordinateur. Je ne vais pas vous la jouer « c’est nul, je veux retourner à Gnome 2 » car cela fait un bon moment que je surveille Gnome 3 et le teste sur une machine virtuelle. C’est nouveau, et comme toute nouveauté, il (me) faudra une période d’adaptation, et de prise de nouveaux repères. En espérant que je ne fasse pas un retour-arrière comme à l’époque du passage de Ubuntu 9.10 vers 10.04.

Quelques retours sur mon installation Debian 7 et Gnome 3 : Continuer la lecture de Passage à Debian 7 (testing), nom de code Wheezy

Rapport de (très) gros test de charge avec la solution BlazeMeter

Dans ce premier billet, je vous présentais la solution de test de charge dans les nuages BlazeMeter, basée sur l’outil Apache JMeter, illustré par un petit test. Dans ce nouveau billet, on passe aux choses sérieuses : le (très) gros test de charge.

Mon objectif était le suivant : faire un tir de charge avec 100 000 utilisateurs virtuels actifs.

Pour faire ce type de gros test, depuis les nuages, il faut un serveur cible (ou une solution cible). Pour ma part, j’ai eu la possibilité d’avoir un prêt d’un très gros serveur situé dans un centre de données à Poitiers/France connecté directement sur une importante dorsale Internet via une liaison à 100 MBits/s. Autrement dit le serveur était bien placé sur Internet pour être attaqué par la solution BlazeMeter.

Le serveur en question est un Dell R815, ayant 4 CPU de 12 cœurs chacun (AMD Opteron 6176), soit 48 coeurs, accompagné de 256 Go de mémoire RAM, connecté à 1 Gbits/s (en ip bonding) sur un commutateur en liaison avec un pare-feu BSD (en mode NAT). Le système d’exploitation dudit serveur est GNU/Linux Debian 6.0.5 en 64 bits.

Le serveur était totalement disponible pour ce test (pas d’autres services tournant dessus).

L’idée étant de faire un test de charge pour « tester » la solution BlazeMeter, et non pas de tester la performance du serveur cible, j’ai choisi de ne mettre qu’un serveur Web Apache avec 3 pages HTML statiques. Le serveur Apache est configuré avec mod_deflate et mod_cache.

Le scénario de test sera le suivant :

  1. page d’accueil (+assertion réponse)
  2. page A (+assertion réponse)
  3. page B (+assertion réponse)

 

Apache JMeter dans les nuages : BlazeMeter, mon premier test

Voici un premier billet sur la solution de test de charge BlazeMeter, basée sur Apache JMeter.

 

 

Tout d’abord une petite présentation de BlazeMeter (d’après ma compréhension).

BlazeMeter profite de l’informatique dans les nuages (Cloud Computing), plus précisément de l’offre de serveurs à la demande d’Amazon AWS (ce type d’offre s’appelle PaaS pour Plateform as a Service), sur laquelle, les gens de BlazeMeter orchestre la mise en oeuvre de JMeter sur des serveurs virtuels pour lancer des tests de charge JMeter, avec en plus l’ajout de graphiques pour suivre son tir, ainsi que de rapports de test sur les résultats du test de charge.

Je suis assez admirateur de leur solution, qui montre que l’on peut faire une très belle solution de test de charge sous forme de SaaS (Software as a Service) avec ce beau logiciel Apache JMeter !

Je vous propose donc dans ce premier billet de découvrir la solution BlazeMeter à travers un petit test (micro) de charge sur mon blog. Continuer la lecture de Apache JMeter dans les nuages : BlazeMeter, mon premier test

JMeter article : Tutoriel Réalisation d’un scénario de test de charge pour l’application Spring PetClinic

Voici la suite de la présentation de JMeter par Antonio Gomes-Rodrigues. Dans son billet-tutoriel, on travaille sur l’application Démo Pet Clinic de Spring. Chaque étape pour la mise en place d’un scénario de test de charges y est détaillée, avec son lot d’astuces.

D’ailleurs j’ai même appris une astuce ! Celle qui consiste à mettre un compteur de temps en fils du serveur Proxy HTTP (de JMeter), afin que les requêtes générées lors de la session de navigation modèle aient directement un compteur de temps en fils !

Un dernier mot : merci à Antonio pour ce billet !