Les version 5.6.x seront les dernières versions qui supporteront Java 8. La prochaine version majeure de Apache JMeter demandera Java 17 ou plus (et non plus Java 11 comme annoncé lors de la sortie de la version 5.6.1).
Les changements sont visibles ici.
Et le téléchargement se passe par ici.
Bons tests!
Apache JMeter 2.10, c’est beaucoup de choses à dire, car il y a eu pas mal de changements et d’améliorations.
Tout d’abord, au niveau des performances de JMeter lui-même, il y a eu plusieurs améliorations. JMeter 2.10 est plus performant que les versions précédentes, vous pouvez réaliser des test de charges avec plus d’utilisateurs virtuels à configuration identique.
L’une d’elle permet de réaliser de manière plus optimale des tests de charges à fort débit (ceux qui n’ont pas de temps de pause entre le requête). Continuer la lecture de Apache JMeter 2.10 est sortie
Avec Tomcat ou Jboss, il est possible d’enregistrer le temps de traitement d’une requête HTTP. Il y a en effet une valve AccessLogValve (désactivée par défaut) qui trace les accès (requêtes) HTTP qui sont effectués sur le serveur. Avec une petite modification du format du log, on peut ajouter l’enregistrement du temps de traitement coté Tomcat ou Jboss de la requête.
Ceci est particulièrement utile pour décorréler le temps de traitement par rapport au temps de réponse enregistré dans un outil de test de charge, comme JMeter.
Voici comme faire dans Tomcat :
Au niveau du fichier Tomcat_Home/conf/server.xml, on trouve la section suivante en commentaires :
<!-- <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/> --->
Continuer la lecture de Tomcat ou Jboss, enregistrer le temps de traitement des requêtes HTTP
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. Continuer la lecture de Bilan année 2008
Voici un très bon ebook en anglais, il s’agit d’un guide sur les tests de performances, proposé en téléchargement et gratuitement par Microsoft via son site CodePlex.
(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) :
Avec JMeter on peut faire des tirs de performances (et d’autres choses) pour une application Web. Pour qu’une application soit performante, il est préférable qu’elle soit développée judicieusement, mais également qu’elle s’exécute sur un environnement performant. Dans ce dernier, il ne faut pas négliger la composante réseau qui peut souvent devenir un goulet d’étranglement au niveau de l’utilisateur.
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 ? Continuer la lecture de Compression HTTP, ou comment réduire le temps réseau dans les performances d’une application
Linux ayant une place importante dans mon utilisation informatique, il est bien normal d’être à l’affût de bons documents dessus. IBM via son site de publications Redbooks nous propose un excellent document sur les performances et l’optimisation de Linux (il s’agit en réalité d’une mise à jour d’un document déjà sorti en juillet 2007).
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.
./
Pour les « grands » tirs de charges dont l’objectif est de tester une nouvelle application J2EE (ou JEE) avant sa mise en production, et afin d’éviter les crashs le jour du lancement, on mobilise en général une équipe des différents « corps de métier » informatiques.
On aura ainsi :
Tout cela fait beaucoup de monde, on ajoutera en général un responsable général, chargé entre autre de synchroniser toutes les actions, et donner le GO du lancement.
Une fois que le tir lancé et terminé, l’expérience montre que c’est en général du coté du serveur d’applications J2EE que les problèmes sont visibles. Où s’ils ne sont pas visibles, on pense à lui en premier car c’est lui qui supporte l’application. Alors quand c’est vous le responsable de la supervision du cluster de serveurs d’applications, tout ce beau monde se retourne vers vous pour avoir l’explication, le comment du pourquoi, afin de comprendre la raison du non succès du tir de charge…
Pourtant vous avez fait une configuration des serveurs d’applications clustérisés aux petits oignons :
Alors avec ce tunning de folie, difficile de comprendre pourquoi le serveur d’applications souffre lors du tir de charges… Continuer la lecture de Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications