Apache – Page 4 – MilamberSpace

Quelques nouvelles

Cela fait un bout de temps que je n’ai pas publié quelque chose sur le blog, alors voici quelques nouvelles en vrac.

Tout d’abord, j’ai changé d’ordinateur portable pour un Samsung New Series 9 (NP900X3D), dont les caractéristiques sont : processeur Core i5, 1,7 GHz (i5-3317U), 4 Go de RAM, disque dur SSD de 128 Go (que j’ai changé par un 256 Go), un poids plume de 1,1 Kg, un look clean et très silencieux.

J’ai retiré le Windows 8 pré-installé pour le remplacer par une Debian Wheezy avec Gnome 3. Ce dernier fonctionne carrément plus vite que sur mon ancien Dell E6500 (normal la carte vidéo est bien plus performante).

Le portable est vraiment rapide (merci au disque SSD en particulier) et plutôt agréable à l’utilisation. Dans les petits bémols, j’ai dû acheter l’adaptateur VGA pour pourvoir projeter mon écran sur des datashows, car le portable n’a pas de connecteur VGA « standard ». (idem pour le port RJ45 (réseau), mais un adaptateur est livré). Autre bémol, seulement 4 Go de mémoire non-upgradable (directement soudé à la carte mère). Continuer la lecture de Quelques nouvelles

Apache JMeter 2.9 est sortie

On est décidément dans un rythme rapide de livraison des nouvelles versions de JMeter. Eh hop, une nouvelle version de JMeter !

Il y a dedans quelques nouveautés intéressantes :

Un nouvel extracteur CSS/JQuery qui permet d’extraire rapidement des valeurs de fichiers Html via des expressions simples utilisant CSS ou JQuery
Il est désormais possible de manipuler les « documents » c’est-à-dire les fichiers Microsoft Office (Word, Excel, PowerPoint), Apache OpenOffice/LibreOffice (Writer, Calc, Impress), fichiers PDF, mais aussi les meta-données dans les mp3, mp4, ogg, etc. via trois éléments :

Dans l’extracteur d’expression régulière afin d’extraire du texte d’un document
Dans l’assertion réponse pour vérifier la présence ou non d’un texte (ou une regexp) dans un document
Dans l’Arbre de résultats pour voir une représentation textuelle du document

De grosses améliorations sur les performances de JMeter lui-même ainsi que la gestion de la mémoire en internet
La possibilité de faire un copier/coller entre deux instances de JMeter

On notera au passage que dorénavant il faut un environnement d’exécution Java 6 ou supérieur pour faire fonctionner JMeter 2.9

La liste complète des nouveautés est accessible ici.

Sinon, un message pour les personnes qui utilisent GNOME 3 avec JMeter, il y a un problème au niveau des menus avec Java 6 et les interfaces Swing (API graphique utilisée par JMeter). Pour le contourner, il suffit d’utiliser Java 7 (openjdk ou Oracle JDK)

JMeter est téléchargeable ici.

Bonne continuation avec JMeter !

Apache JMeter 2.8 est sortie

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

Dans les changements notables, on a :

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.
Dorénavant c’est l’implémentation Apache HTTPClient 4 qui sera utilisée par défaut pour les requêtes HTTP.
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 :

page d’accueil (+assertion réponse)
page A (+assertion réponse)
page B (+assertion réponse)

pas de ressources statiques (pour préserver la bande passante)
5 secondes de pause entre chaque page
1 itération par minute pour chaque utilisateur virtuel
les requêtes HTTP utilisent l’implémentation HttpClient 4 Continuer la lecture de Rapport de (très) gros test de charge avec la solution BlazeMeter