Interview de Milamber – développeur et membre PMC du projet Apache JMeter

Présentation

Bonjour Milamber, peux-tu te présenter rapidement ?

Du point de vue d'Apache JMeter, je suis développeur et membre PMC. Ce travail est fait sur mon temps libre (soir & weekend). La semaine, je travaille comme expert et consultant informatique.
J'habite au Maroc depuis 10 ans (Casablanca puis Rabat), où je travaille dans la prestation de service informatique pour quelques grands comptes marocains et certains français (via des missions en France).
J'ai commencé à travailler en France dans une société 'Internet' en tant que développeur et administrateur systèmes, avant l'époque des start-up. Et donc j'ai acquis pas mal d'expériences et de retours d'expériences dans les technologies autour de l'Internet.
Ce qui m'amène sur mes occupations actuelles : Architecte technique web/j2ee et expert performances/sécurité.

Apache JMeter

Pourquoi participer à JMeter et pas un autre ?

Tout d'abord je l'utilise dans mon travail depuis longtemps (2003), et je programme en Java et suit très habitué de son eco-système (Eclipse, SVN, etc.).
Ensuite, ce fut de fil en aiguille, les articles / tutoriels sur JMeter ont vite eu une certaine audience sur le blog, malheureusement, à l'époque la version française de JMeter était peu encourageante, donc j'ai eu envie de participer avec les traductions et à l’internationalisation de certains éléments afin d'avoir des tutoriels plus sympas avec des captures en français.
Ensuite, j'ai proposé des correctifs ou améliorations de certaines fonctionnalités.
Voilà, une fois embarquée, c'est-à-dire une fois que l'on a fait l'effort de rentrer dans le code d'un projet aussi ancien que JMeter (qui contient du code de différentes époques / différentes conceptions) on essaye de capitaliser dessus.

Que pense tu des nouveaux concurrents open source de JMeter (en particulier Gatling et Tsung) ?

Gatling a une approche différente de JMeter pour aborder le test de charge (i.e. le coté asynchrone, et l'optimisation des ressources du serveur de test), par ailleurs c'est un projet très jeune sur lequel il manque des fonctionnalités. Il semble séduisant (en particulier les graphiques), même si le coté "codage" en scala l'éloigne des utilisateurs qui ne sont pas des développeurs (dans les sens : informaticien ayant l'habitude de manipuler du code de programmation dans leur travail)
Je ne connaissais pas Tsung. Pas d'avis particulier.

Souvent, on me dit que la partie injection et reporting de JMeter est son point faible, qu'en penses-tu ?

Je ne sais pas ce que tu entends par "partie injection"? (de données?)

Pour la partie rapport c'est un point où il y a des choses à améliorer.
JMeter dispose d'éléments Récepteurs pour avoir des consolidations ou agrégation de résultats, et également de la génération de graphiques. Malheureusement, ces derniers ne sont pas très 'sexy'.
Par ailleurs pour la notation de rapport (au sens document qui contient du texte explicatif sur le tir, des graphiques, des tableaux et du texte d'analyse), JMeter a un embryon d'une sorte de 'compositeur' de rapport (bin/jmeter-report). (Je viens de le découvrir il y quelques semaines!). Par contre, il ne semble pas fonctionnel.

Bon après, j'ai vu des rapports automatiques avec des outils payants. Effectivement c'est rapidement généré, mais le travail d'analyse des résultats est souvent manquant ou peu clair.
Le fait de devoir prendre le fichier CSV et générer ses graphiques avec un tableau (Excel/Calc) permet de voir / réfléchir sur les résultats, et préparer ainsi le texte du rapport d'analyse.

Si oui, que fais-tu pour pallier cette faiblesse ?

Dernièrement, j'ai amélioré le récepteur Graphique Agrégé en lui ajoutant plus d'options paramétrables (couleurs, polices, dimensions, etc.). Depuis, je pense qu'un graphique agrégé JMeter peut parfaitement s'intégrer dans un rapport (fait avec un logiciel de traitement de texte).
J'aimerais avoir aussi un récepteur graphique qui affiche la courbe des temps de réponse par rapport au temps. (je n'ose pas dire que je travaille dessus, car j'avance très (trop) doucement dessus par manque de temps)
Je me dis aussi que ce serait bien que je regarde de plus près ce jmeter-report.

Et les points forts ?

Je pense que les points forts de JMeter sont :

  • Son coté graphique dans la manipulation des éléments de tir (son arbre), et ses formulaires. Il n'est pas nécessaire de savoir coder pour utiliser JMeter, et pour les cas pointus on peut se rabattre vers du code, et en plus choisir le langage! (java, javascript, groovy, bsf, jexl, jython, perl, ruby, prolog, etc.)
  • Son coté "couteau suisse", car il dispose de plein de sorte d'échantillons de test en plus de la traditionnelle requête HTTP.
  • JMeter est léger, son installation est juste une décompression (bien entendu avec un environnement Java installé au préalable). Il est donc très facile à déployer et à utiliser (en particulier à distance sur des serveurs de tests). La conception du tir est fait localement, et le tir est fait à distance. (Les gens de BlazeMeter l'ont très bien compris d'ailleurs)

Peux-tu nous parler de quelques cas extrêmes (beaucoup de virtual user, protocole pas supporté par d'autres outils...) où tu as utilisé JMeter ?

Sur les cas extrêmes, genre des millions d'utilisateurs, je n'ai pas encore eu cette chance. Je me suis pour l'instant arrêter à un test de charge en dizaines de milliers d'utilisateurs (par seconde). Noter qu'il n'y a pas besoin de beaucoup d'injecteurs pour faire cela, aujourd'hui un bon gros serveur (JVM en 64 bits, Linux) avec un JMeter avec une taille de mémoire Java large sait très bien le faire.

Après Apache JMeter ce n'est pas que pour les tests de charges. Par exemple, JMeter peut jouer le rôle d'un ETL.
JMeter peut aussi (du coup) pomper une base de données entière via les pages d'un site web. Par exemple, il y a quelque temps, je m'étais amusé à récupérer la base de données complête des noms de famille en France via le site de l'Internaute (Journal des femmes).
JMeter c'est aussi la possibilité de faire des attaques informatiques de type brute-force sur des mires de connexion (page de login/mot de passe). Ce n'est pas rien que JMeter est inclus dans des distributions spécialisées sur les tests d'intrusions comme Backtrack 😉

Pour peu que l'on pense différemment, on peut faire pas mal de choses avec JMeter.

Ta réponse tombe bien, car lorsque je parlais de la partie injection, je parlais du nombre d'injecteurs nécessaire pour simuler une forte charge. Peux-tu m'en dire plus sur le test de dizaines de milliers d'utilisateurs à la seconde et nous donner des conseils ?

Lorsque j'ai fait le test de dizaines de milliers d'utilisateurs à la seconde, c'était sur 1 seul serveur (16 cores, 16 Go de RAM) avec une Heap à 8 Go pour JMeter.
Il y a certainement le préjugé périmé datant de quelques années, que comme JMeter c'est Java, il faut beaucoup de ressources mémoire de base, et aussi beaucoup de ressources si beaucoup d'utilisateurs.
Et surement aussi le fait que bien souvent les testeurs qui débutent sur JMeter lancent leurs premiers tests de charge en mode graphique (avec bien souvent un Arbre de résultat activé !) ! donc le OutOfMemoryError arrive assez vite. Donc ensuite il est facile de penser : si je fais un OOME avec 50 utilisateurs, il va falloir passer au mode distribué avec plein d'injecteurs si je veux simuler 2000 utilisateurs !
Et ensuite, il arrive même que le testeur mette en place sa dizaine d'injecteurs, et continue à lancer le tir avec un JMeter contrôleur en mode graphique ! et rebelote !

Il suffit pourtant de suivre ces principes pour les gros tirs de charge :

  • on fait le scénario avec un JMeter en mode graphique (et pas forcément le JMeter qui lancera le tir)
  • on modifier la taille de la mémoire Java allouée (dans le jmeter(.bat)) (en fonction du nombre d'utilisateurs et de la complexité du scénario)
  • on lance son tir en mode non graphique
  • on exploite les résultats (CSV généralement) dans un JMeter en mode graphique, ou autres outils.

Peux-tu nous parler des futures évolutions de JMeter ?

Cela c'est super difficile. Il n'y a pas de plan d'évolutions défini. La prochaine version devrait demander au minimum un Java 6 (actuellement un Java 5). J'ai bien envie d'avoir un System tray (icône dans la barre de tâche) dans le mode graphique de JMeter (fonctionnalité de l'API Java 6). Bien qu'avec les nouvelles interfaces des OS (Gnome 3, Metro) ce genre d'icône disparaissent) Et comme dis, j'aimerai aussi avoir un ou deux graphiques natifs plus sympas dans JMeter.

Bon après, JMeter c'est 14 ans d'existences, il a pas mal de fonctionnalités et une certaine stabilité à maintenir. Il est donc difficile de faire des gros changements sans apporter des régressions ou en gardant une compatibilité dans l'API JMeter (pour les plugins).

Test de charge

Peux-tu nous donner 2-3 exemples qui montrent l'importance d'un test de charge avant la mise en production d'une application ?

On ne peut pas parler d'importance de faire un test de charge avant une mise en production. C'est en réalité une obligation.
Je ne cherche pas à être alarmiste ou pro-test de charges. Je travaille aussi dans la sécurité (de l'information et du système d'information), et si on regarde les questionnaires des audits de sécurité tel que MEHARI (ou ISO 27002:2005), on retrouve des questions relatives à l'exécution de test de charge avant les MEP (Mise En Production).
Bien souvent, donc, les campagnes de tests de charge que j'exécute, le sont pour répondre à ce type d'exigences de sécurité : "avant toute mise en production, il faut faire un test de charge". On retrouve cette exigence, généralement dans la Politique de Sécurité du Système d'Information (PSSI) des (grandes) entreprises ou les administrations.

Par ailleurs, c'est parfois obligatoire de manière indirecte au sens légal pour les sociétés cotées à la bourse aux Etats-Unis à cause de la loi Sarbanes-Oxley. Je ne suis pas un expert de cette loi et de ses conséquences, mais l'une d'elle (à travers la gestion des risques) est de faire des tests de charges sur les nouvelles applications (liées au cœur d'activité) avant toute mise en production. Car si on passe en production une application non-testée, et que cette dernière ne tient pas la charge, alors cela peut faire perdre beaucoup d'argent à l'entreprise côtée, et donc faire baisser le cours de la bourse, etc... Et oui, au Maroc, il est des filiales, de filiales, de filiales, etc. qui ont leur maison-mère cotée à la bourse de New York.

Quel est pour toi l'aspect le plus important dans les tests de charge ?

Définir les objectifs du test de charge (nombre d'utilisateurs, temps de réponses max désirés / acceptable / refusés, etc.). Il faut que tout le monde soit d'accord sur les objectifs avant de faire le test, et surtout avant de communiquer les premiers résultats, histoire d'éviter les analyses à la va-vite des responsables qui ne lisent pas le rapport.

J'ajoute un deuxième poing important : celui de bien superviser l'application et l'ensemble des services associés (base de données, serveur web, environnement d'exécution, réseau, etc.) lorsque l'on fait un test de charge.

Quel est le plus grand changement que tu as vu dans le monde du test de charge depuis tes débuts ?

Je ne sais pas si j'ai vu de 'grands' changements. Il y a deux choses qui me viennent à l'esprit :

  • une montée en maturité des décideurs sur la sécurité du système d'information, et donc de l'obligation de faire un test de charge des applications,
  • De plus en plus d'applications "web" sont au cœur des entreprises / administrations et qui sont donc critiques pour leurs activités (souvent, il y a des impacts financiers si l'application est en panne ou ne supportent pas la charge)

Peut-être aussi un grand changement c'est aussi que JMeter est souvent une bonne réponse pour faire des tests de charges par rapport à des solutions propriétaires qui sont très (très) onéreuses en termes de licences, mais également en charges jour/homme, et du coup délai d'exécution pour faire le test de charge avant la MEP (Mise En Production).

Quels sont les problèmes que tu rencontres le plus souvent lors d'une campagne de test de charge ?

L'application (ou la solution) à tester n'est pas supervisée. JMeter ne faisant pas de supervision (nativement hormis Tomcat). On ne peut faire un test de charge sans supervision, car sinon l'analyse des résultats et la recherche de la cause (ou des causes) des problèmes est quasi impossible.
Dans le même genre : les plate-formes d'hébergement de l'application/solution n'ont pas été optimisées (tuning de l'OS, du serveur Web, serveur J2EE, base, etc.), et donc là on fait un premier test de charge "bidon" car il va juste montrer qu'il faut faire les optimisations classiques (file d'attente TCP, nombre de connexions concurrents, taille mémoire Java, etc.)

Que penses-tu des outils de test de charge dans les nuages ?

Je pense que tu fais référence à ces choses comme BlazeMeter ? Tout d'abord, avec des offres comme celle d'Amazon EC2, j'exécute déjà depuis quelques années des tests de charges 'externes' avec JMeter installé sur une ou plusieurs machines virtuelles EC2. La location est payée à l'heure, donc ce n'est pas cher, et efficace.
Pour revenir sur des offres comme BlazeMeter, c'est une très bonne utilisation de Apache JMeter couplée avec une interface d'administration et de reporting.
Cependant ces offres s'appliquent aux applications / sites des entreprises qui sont "ouverts" à l'extérieur (site e-commerce, site selfcare, etc.). Pour les applications Intranet qui sont souvent bien plus importantes aux yeux de l'entreprise, les offres SaaS ne sont pas encore courantes (genre une appliance BlazeMeter).

Quelles qualités sont importantes pour devenir un bon testeur ?

Un bon testeur doit avoir beaucoup de qualités, d'autant que souvent on lui demande de participer aux diagnostics et à la recherche de la cause de la mauvaise performance qu'il a relevé avec son test de charge.
Du coup, un bon testeur doit connaître le fonctionnement des choses qu'il teste pour mieux comprendre les résultats. C'est-à-dire, comprendre pour un serveur J2EE son fonctionnement (pool de connexions, pool d'unités d'exécutions, timeout session, sessions partagées ou non, etc.), le serveur de base de données, les frameworks applicatifs utilisés (leurs limites, les options anti-performances (ex. le mode développeur sur Struts, la verbosité des logs, etc.), le protocole TCP/IP (et les choses autour comme les répartiteurs de charges, les firewalls, les switchs, le STP (spanning tree protocol), etc.). Souvent, j'ai dû démontrer aux équipes (dev ou système ou réseau) que le problème vient de chez eux.

Il doit aussi savoir communiquer tant avec les équipes techniques (développeurs ou administrateurs) qu'avec les chefs (qui veulent savoir le pourquoi du comment). Par ailleurs, il y a parfois des enjeux 'politique-financiers-tensions client-fournisseur-etc', et il faut mesurer ses mots dans les rapports pour rester le plus impartiale possible.

En gros, un bon testeur est polyvalent.

Ton parcours

Concernant ton blog peux-tu nous dire :

Pourquoi l'avoir créé ?

A l'époque, dans la société dans laquelle je travaillais, je faisais une sorte de newsletter/revue de presse interne dans laquelle j'ajoutais un point de vue sur une actualité (liée à l'informatique).
Cela avait un certain impact vis-à-vis des collaborateurs et collègues, mais peu sur les chefs (genre pas de merci). D'autant que je le faisais généralement sur mon temps personnel.
Alors à un moment, je me suis dis, autant le faire dans un blog.

Ce qu'il t'a apporté ?

A travers les articles/tutoriels sur JMeter, une sorte de publicité et une (re)connaissance de mon expertise au-delà des villes de Casablanca et Rabat. J'ai pu par exemple faire des missions en France grâce à ce blog (formations et tests de charge).
D'un point de vue plus personnel, le blog permet de publier quelques idées ou astuces pour moi-même (une sorte de pense bête) tout en les partageant (exemple le billet sur GnuCash en Français sur un Ubuntu/Debian en anglais, que je consulte à chaque fois que je mets à jour ma distribution (ou que je teste une prochaine version de distribution dans une machine virtuelle)

Combien de temps passes-tu dessus ?

Je ne sais pas trop.
C'est assez ponctuel comme activité, car d'une part je n'ai plus autant de temps libre et d'autre part, il commence à être complet en termes de tutoriels sur JMeter.
Comme mes activités de développement sur JMeter le sont aussi sur mon temps libre, je dois souvent choisir entre ouvrir Eclipse et avancer sur JMeter ou rédiger un billet sur le blog.

On peut voir sur ton blog que depuis l’été 2010, tu es devenu « committer » à la fondation Apache (ASF), sur le projet JMeter. Puis en janvier 2011, tu es passé membre du PMC (Project Management Committee) JMeter.

Tu peux nous détailler un peu plus ton parcours ?

Je suppose que tu parles du parcours du coté de la fondation Apache et surtout du projet Apache JMeter.
J'ai commencé par m'abonner à la mailing-list des développeurs Jakarta-JMeter pour voir comment cela fonctionne. Ensuite après une période d'observation et la lecture des recommandations pour envoyer un patch (cf site Apache), j'ai commencé tout simplement à revoir la traduction française de JMeter, qui était une traduction "google" généralement. Donc j'ai envoyé quelques patchs de correction du fichier messages_fr.properties. Puis, c'est passé à l’internationalisation (i18n) de certains éléments de l'interface graphique de JMeter pour pouvoir les avoir en français également.
A l'époque, il y avait aussi le problème de l'enregistrement d'un scénario avec le proxy JMeter pour les sites en HTTPS qui n'était pas supporté directement par JMeter. Là aussi, j'ai préparé un patch, etc.
Ensuite, après un certain temps, les PMC Jakarta-JMeter ont lancé l'idée de m'inviter à devenir Committer sur leur mailing-list privée (on peut consulter les archives si on devient PMC ensuite), l'idée a été acceptée, et j'ai reçu l'invitation. A l'époque, j'étais en mission en Tunisie, à la lecture du mail, je me souviens avoir levé les bras avec un gros 'YES' dans le hall de l'hôtel (où il y avait le wifi).
Ensuite le rôle PMC est venu 6 mois après.

Tes conseils pour réaliser le même parcours que toi ?

Je ne sais pas quoi répondre, d'autant que mon parcours (coté JMeter) n'est pas forcément un modèle.
Je préfère juste dire que participer à un projet open source et en particulier un projet de la fondation Apache (qui a ses règles de codage et de qualité) est très formateur. Cela apporte une vision différente du développement, de la gestion du changement, de la documentation d'un logiciel, etc. C'est assez en contradiction avec ce que l'on peut voir ou vivre dans les sociétés de services qui font du développement au forfait (si vous voyez ce que je veux dire...).
Par ailleurs, mettre dans son CV : participe au développement d'un logiciel Apache en tant que committer c'est toujours un beau plus.

Mot de la fin

Quelque chose à ajouter ?

Merci de m'avoir proposé cet interview.
J'en profite également pour te remercier des différents articles / tutoriels que tu as fait sur Apache JMeter et les tests de charge ici et ailleurs. En espérant que cela continue sous cette forme ou d'autre forme.

Laisser un commentaire

Merci d'effectuer cette opération simple pour valider le commentaire *

Mots-clés
RSS Feed