C’est un tutoriel extrêmement complet qui couvre de nombreux domaines qui sont liées à la performance en général, et plus particulièrement sur une application J2EE.

Le tutoriel couvre les procédures de test (préparation, principaux métrics), le test de charges avec JMeter, et une dernière partie sur l’identification et la correction des problèmes. On a donc ainsi, l’entrée, le plat et le dessert pour optimiser nos applications J2EE.

La section sur l’identification et la correction des problèmes est particulière exhaustive sur les problèmes que l’on peut en effet rencontrer dans une application. Elle sera très utile pour faire une check-list de vérification si un souci arrive sur son application.

Voilà, c’est à mettre dans vos marques-pages.

./

La vidéo complète de sa présentation est disponible (46 min, en anglais), c’est extrêmement intéressant et enrichissant. La présentation PDF est téléchargeable également.

Je vous recommande au moins un parcours de la présentation pour voir le « process », la démarche à suivre pour tout problème de performance.

Sa présentation parle de Tomcat, mais certaines parties sont adaptables pour d’autres serveurs d’applications comme Jboss (bien sur), WebSphere, etc.

• La vidéo avec les slides qui défilent
• La présentation au format PDF

./

Pourquoi ce mode non-GUI ? Parce qu’en mode GUI, JMeter peut être gêné par la gestion du ‘graphisme‘ pendant qu’il est en train d’exécuter un test de charges. Et cela peut avoir un impact sur la qualité des résultats du tir.

En effet, sur le poste JMeter, la gestion du mode graphique impacte :

• Le processeur. JMeter doit traiter deux choses : le test de charges (envoi des requêtes, réception des réponses, éventuellement écriture dans un fichier, etc.) et l’affichage des résultats dans les récepteurs (listeners) ainsi que d’éventuels calculs statistiques (total, moyenne, etc.). La puissance du processeur est donc découpée en deux tâches principales : la gestion du tir et la gestion de l’affichage.
• La mémoire. Certains récepteurs comme celui de l’arbre de résultats ou celui de tableau de résultats, sont extrêmement gourmands en mémoire, en effet, pour chaque test d’échantillon, il faut ajouter un petit ‘chouia‘ dans la mémoire. Or quand son test de charge génère de très nombreuses requêtes, le petit chouia devient énorme, ce qui peut même faire des OutOfMemoryError du côté JMeter si on ne prends pas soin d’augmenter la taille de mémoire maximale de la JVM de JMeter (au niveau du script de lancement).

Et pour couronner le tout, la machine virtuelle Java (qui je le rappelle, exécute JMeter), aura parfois besoin de faire passer le garbage collector (GC) pour la gestion de la mémoire, ce qui a un impact sur le traitement des résultats, le GC gelant les threads (donc le tir et le traitement des résultat) lors de l’identification des objets à supprimer de la mémoire.

Ces points montrent que le mode GUI est plutôt à proscrire lors d’un test de charge aussi simple soit-il, car on risque d’avoir des résultats erronés en termes de calcul de temps de réponses, par JMeter lui-même, ce dernier est perturbé par la gestion de l’affichage des résultats de manière graphique, et par le fonctionnement de la JVM au niveau la gestion de la mémoire si le nombre de requêtes/réponses devient très important.

Donc pour résumé, le mode GUI est plutôt à utiliser pour créer et maintenir ses scripts JMeter et lancer des tir de charges « blancs » permettant de vérifier la bonne exécution d’un scénario. Le mode non-GUI est à utiliser pour l’exécution du test de charge « officiel ».

Un petit conseil pour finir : si vous avez une machine JMeter avec un processeur multi-core (dual core), il est préférable d’utiliser une machine virtuelle Java dernière version (6), car la gestion des processeurs (core) y est bien plus optimale que la version 5 (sans parler de la 1.4). Avec une JVM 6, JMeter et tous ses petits threads vont utiliser l’ensemble des CPU disponibles sur le poste de test JMeter.

]]> http://blog.milamberspace.net/index.php/2009/02/01/jmeter-pourquoi-executer-son-test-de-charges-en-mode-non-gui-sans-interface-graphique-192.html/feed 2 http://blog.milamberspace.net/index.php/2008/12/29/bilan-annee-2008-120.html http://blog.milamberspace.net/index.php/2008/12/29/bilan-annee-2008-120.html#comments Mon, 29 Dec 2008 21:21:31 +0000 Milamber http://blog.milamberspace.net/?p=120 En fin d’année, il est de coutume de faire le bilan. Je vous propose donc de partager différents points de vue « bilan de fin d’année », le tout étant totalement subjectif, non-exhaustif et basé sur mon seul vécu.

Windows Vista

Windows Vista est un (le ?) fiasco incroyable de cette année, sans entrer dans les détails techniques, je dirais simplement que je n’ai personne dans mes différents « paysages » : famille, collègues ou clients qui utilisent Vista (certains l’on testé sans le garder).

• Pour le paysage famille, c’est lié au fait qu’il n’y a pas eu de renouvellement de machines (pourquoi upgrader vers Vista sur sa machine courante ?) ou bien qu’ils sont sous Linux (ma filleule de 10 ans en l’occurrence).
• Pour le paysage collègues, c’est lié au fait que les nouvelles machines acquises sont sous Windows XP (licence Downgrade XP), et que cela ne dérange personne (plutôt le contraire).
• Pour le paysage clients, c’est lié également à la livraison de machines avec Windows XP, et aussi à la politique globale des DSI de conserver Windows XP.

J’ai même parfois suscité de l’intéressement de la part de collègues ou de clients avec mon ordinateur utilisant non pas Windows mais Linux / Ubuntu. Intéressement allant même jusqu’à l’installation pour certains, en espérant qu’ils continuent…

Virtualisation

La virtualisation est devenue pour moi (personnellement) très présente en 2008, tant sur mon ordinateur de travail quotidien (avec VirtualBox) pour :

• avoir Windows XP (Home Edition) pour ouvrir certains documents Microsoft et utiliser Adobe Lightroom pour mes photos
• avoir différents environnements de tests (bien souvent des Linux (Centos, Ubuntu ou RedHat))
• pour faire des démonstrations en donnant une formation (WebSphere Administration)

Que sur mes machines/serveurs ‘physiques’ de tests pour :

• tester Liferay (VMWare / Centos)
• mettre en place un cluster Alfresco sur Jboss (VMWare / Centos)
• avoir une machine DVL (VirtualBox / DawnLinuxVulnerable) pour effectuer des tests de sécurité
• tester la mise en cluster de CAS (VMWare / Central Authentification Service)
• etc.

Je n’ai pas fini d’utiliser la virtualisation. Tant mieux, d’autant que les clients commencent à y réfléchir très sérieusement, non pas pour faire des petits environnements de tests comme moi, mais plutôt pour avoir des desktops virtualisés et/ou des environnements serveurs virtualisés. Vmware ESX et le futur oVirt de RedHat vont certainement faire partir des choses à connaître en 2009.

Les performances applicatives, les tests de charges

Dans mon paysage client, tous ont des objectifs de performances pour les nouvelles applications qu’ils lancent. Signe d’une nouvelle maturité ? Oui et non. Certains ont vécus des soucis sur des applicatifs lancés qui se sont révélés peu performants et qui ont nécessité des diagnostics, des corrections et des optimisations à faire dans l’urgence (et souvent sous pression), d’autres n’ont pas envie tout simplement de vivre cela, et incluent le test de performance (de charges) en bout de chaîne avant la mise en production.
Là pour 2009, il va falloir éviter de mettre des « couches supplémentaires » pour palier aux problèmes, mais plutôt inclure la notion de performance et optimisation directement auprès du développeur. Ceci permettant d’avoir des applications avec de la performance en « natif ». Il y a bien des formations pour le développement orientées sécurité, pourquoi pas des formations orientées optimisation…

La sécurité applicative

Pour parler un peu de la sécurité applicative en 2008, je dirais : « encore inconnue » dans la réalité, bien qu’on en parle et que l’on aimerait bien l’avoir dans ses applicatifs, mais pour l’instant on n’a pas le temps de s’en occuper… (je dirais) De toutes les façons, les cabinets d’audit de sécurité vont nous dire quelles sont les failles que nous avons…

Les applications Web
On parle du Web 2.0 (et même d’Entreprise 2.0), des nouvelles façons d’utiliser l’outil Internet. Aujourd’hui (et ici au Maroc), les applications Web sont de « véritables applications ». C’est-à-dire qu’elles fournissent un lot de fonctionnalités important (on s’en doute), de la convivialité (ajax/flex merci), et tout, et tout. Cependant on notera la tendance des clients à demander des interfaces (écrans) qui remplissent complètement la largeur de l’écran de la machine. En gros avoir des applications qui profitent des espaces blancs habituels à gauche et à droite sur les cotés du navigateur (regarder sur ce blog ). Je pense que cela provient 1/ du fait que les écrans de machines (notamment les portables) sont devenus très larges, et 2/ des interfaces de type Gmail/Google qui sont extensibles.

On dit souvent que le navigateur est devenu le « nouveau » système d’exploitation, c’est à dire que finalement l’utilisateur ne voit plus que la dernière couche de ses applications. La tendance des « applications à écrans larges » est juste dans la continuité des choses.

OpenOffice(.org)

L’intérêt d’OpenOffice, sans forcément donner lieu à des passages vers OpenOffice, est grandissant. Mes interlocuteurs connaissent cette suite bureautique, et ont envie de savoir si c’est « compatible » avec la suite Microsoft Office, d’autant que parfois le passage à Office 2007 n’a pas toujours été bien vécu (pour mes interlocuteurs professionnels). Quant à mon entourage familial, je pratique la conversion à OpenOffice (sous Windows ou Linux) avec une petite formation à l’appui plutôt que leur installer une suite MS Office (je rappelle aussi que c’est payant : en France, ~99 euros pour Office 2007 en pack Etudiant / Famille !). Ensuite on ne me demande plus d’avoir MS Office…

On ajoutera que Microsoft dans le SP2 d’Office 2007 va permettre de lire des fichiers OpenOffice, ce qui viendra ajouter à la compatibilité bi-directionnelle des formats bureautiques.

SPAM

Le SPAM, bien que toujours (et même extrêmement) présents sur les ‘câbles’ Internet, n’est plus l’ennui récurent qu’il était. En effet, les filtres anti-spams tant du côté des serveurs de messageries que du coté des postes clients (outlook, thunderbird) sont devenus performants, à tels points que je n’ai que très épisodiquement un mail de spam sur mes différentes boîtes aux lettres. Merci.

Ubuntu

Sans dire qu’il s’agit de la meilleure distribution pour poste de travail, son petit coté « si il existe des drivers non-opensource pour un périphérique, alors on le distribue aussi » est bien pratique par rapport à d’autres distributions. Toujours est-il que je suis très satisfait d’avoir un poste de travail Linux / Ubuntu qui fonctionne bien, rapide, stable et qui sait profiter de mes 4 Go de mémoire (le coté 64 bits).

La future release de Ubuntu (9.04 Jaunty Jackalope, prévue le 23 avril 2009) s’annonce exceptionnelle avec OpenOffice 3, Xorg 1.6, le dernier noyau Linux 2.6.28, Firefox 3.1, Thunderbird 3, etc… (on en reparlera…)

Je finis ce bilan, par quelques notes :

1. Le blog n’a pas été toujours facile à maintenir à jour cette année, bon gré, mal gré, des événements et actualités professionnelles et personnelles. Mais cela reste très gratifiant à tous les points de vue.
2. JMeter fait son petit bout de chemin, les billets relatifs à ce sujet ont leurs visites qui augmentent de mois en mois. Peut-être est-ce dû au fait qu’il y a peu de documentation francophone sur JMeter (ce blog est assez bien placé sur google.fr avec le mot-clé Jmeter du coup). Le groupe « JMeter en français » n’est pas un groupe très actif, mais se réveille de temps en temps pour soulever des points souvent très intéressants.

Pour conclure, une bonne année 2008 d’un point de vue informatique pour moi. Les choses bougent, Linux est vraiment bien en tant que desktop.

J’en profite pour vous souhaiter une excellente année 1430 (calendrier musulman, car aujourd’hui c’est le 1er Moharem) et une excellente année 2009 (calendrier grégorien/international) !

./

Voici donc un petit tutoriel qui donne la démarche pour faire un test de charge distribué avec JMeter.

L’intérêt principal pour ce type de test, est que la charge à produire par JMeter pour simuler ses utilisateurs virtuels est répartie sur plusieurs machines JMeter. Cela évite ainsi les problèmes de saturation de bande passante du JMeter, de surcharge CPU, mémoire, etc quand vous simulez un très grand nombre d’utilisateurs.

Ce tutoriel donne aussi quelques bons conseils pour réaliser ce type de tir.

Bons tests !

./

Je suis l’initiateur du groupe, vous pouvez vous inscrire afin de participer au démarrage du groupe.

Ce groupe espère aider à l’assistance à l’utilisation de JMeter (tests de charges, stress, fonctionnel, performances, etc), les techniques (ou astuces) sur son utilisation et également les méthodologies de tests ainsi que l’analyse des résultats.

L’idée étant de progresser ensemble dans l’utilisation de JMeter.

L’adresse du groupe est : jmeter-fr@googlegroups.com, les archives sont lisibles par tout le monde, et il faut être membre pour envoyer des messages.

En espérant que ce groupe vivra longtemps et qu’il sera actif ! On compte sur vous !

Abonnement au groupe JMeter en français

E-mail :

Visiter ce groupe

(titre en anglais : Performance Testing Guidance for Web Applications)

C’est un livre de 221 pages, découpé en 8 parties (pour un total de 18 chapitres) :

1. Une introduction aux tests de performances, qui vous donnera un aperçu des différents types de tests de performances, les concepts clés et le vocabulaire utilisé.
2. Une approche modèle sur le test de performance, à travers 7 macro activités. Cette partie montre également comment intégrer les tests de performances dans les environnements Agile et CMMI.
3. Identification de l’environnement de test, qui montre comme collecter les informations nécessaires sur un projet à tester, allant des architectures systèmes au activités utilisateurs, etc.
4. L’identification des critères d’acceptance du tir de charges, qui permettent de déterminer les objectifs du tir.
5. La conception et la planification des tests, qui montrent comment modéliser la charge tout en prenant compte des retours des utilisateurs pour concevoir un test de performance adéquat.
6. L’exécution à proprement parlée, des tests des performances.
7. L’analyse des résultats du tir, et la génération du rapport, qui montrent comment organiser et présenter les données de façon faire passer l’information du rapport de manière efficace.
8. Pour finir, deux techniques de tests de performances pour une application Web, le tir de charges et le tir de stress.

Comme on peut le voir il s’agit d’un programme complet et méthodologique sur les tests de performances.

Je ne vous donne le contenu détaillé du livre, mais on en a pour « son argent » d’autant qu’il est gratuit. On en tire des enseignements, de la méthodologie, du vocabulaire et une vision très professionnelle du test de performances.

En conclusion, je vous recommande sa lecture.

./

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]

• Apache – module mod_deflate
• Wiki : la compression HTTP
• La compression HTTP par son inventeur

./

]]> http://blog.milamberspace.net/index.php/2008/07/06/compression-http-ou-comment-reduire-le-temps-reseau-dans-les-performances-dune-application-80.html/feed 2 http://blog.milamberspace.net/index.php/2008/05/18/petit-tutorial-sur-la-jmeterisation-dune-requete-de-tir-de-charges-dun-webservice-via-soap-avec-jmeter-76.html http://blog.milamberspace.net/index.php/2008/05/18/petit-tutorial-sur-la-jmeterisation-dune-requete-de-tir-de-charges-dun-webservice-via-soap-avec-jmeter-76.html#comments Sun, 18 May 2008 17:48:37 +0000 Milamber http://blog.milamberspace.net/index.php/2008/05/18/petit-tutorial-sur-la-jmeterisation-dune-requete-de-tir-de-charges-dun-webservice-via-soap-avec-jmeter-76.html Tout est dans le titre !

Par curiosité j’ai testé la fonctionnalité de requêtage de JMeter sur les WebServices avec SOAP. Voici un petit tutorial du résultat.

./

Redbooks : Linux Performance and Tuning Guidelines

Ce livre nous propose ainsi une large introduction au fonctionnement interne de Linux au niveau de la gestion des processus, les architectures mémoire (en particulier les différences entre systèmes 32 bits et 64 bits), les systèmes de fichiers (ext3, ext2, etc.), la gestion des entrées / sorties et la gestion du réseaux. C’est extrémement instructif.

La suite est un panorama des outils disponibles sur les distributions Linux pour la supervision et le benchmark. Chaque outil est expliqué, en particulier l’interprétation des données affichées.

Les deux derniers chapitres nous montrent d’une part les méthodes d’identifications des goulots d’étranglements (bootlenecks) au niveau CPU, mémoire, disques et réseaux. Et d’autre part des techniques d’optimisation de sa machine Linux (orienté serveur).

Pour résumé, ce document doit être une référence pour tout bon administrateur système qui s’occupe de serveurs Linux ou tout personne soucieuse (comme moi) des performances des bécanes !

Bon lecture.
./