mardi 9 juillet 2013

Gatling-vs-JMeter



J'ai récemment lu un billet sur le blog SMILE sur Gatling (comparé à JMeter) qui m'a agacé alors j'y ai laissé un commentaire,  j'ai décidé de le développer ici.

L'article de Smile est ici:



Le format de mon article sera le suivant:
--------------------------------------------------------------------------------------------------------

"Citation de l'article"

Mon analyse

--------------------------------------------------------------------------------------------------------


Graphes : 


"JMeter ne génère pas de rapports en soi. Il enregistre des résultats et son interface permet d'afficher des graphes pour aider à l'analyse. Gatling de son côté, enregistre les résultats et génère directement un rapport en HTML naviguable. Les résultats sont clairs et les graphiques élégants. Du Javascript est embarqué dans le rapport pour rendre l'experience utilisateur plus agréable."

Pour cela voir jmeter-plugins, les graphes sont beaucoup plus riches que ceux de Gatling. Tous les utilisateurs JMeter utilisent au moins ce plugin, l'article n'en parle pas.
Exemples de graphes:


Vous me direz c'est un plugin, donc complexe à installer ? Il suffit de dézipper et copier le jar dans jmeter/lib/ext et les dépendances dans jmeter/lib.

Et vous pouvez en rajouter si ceux qui existent ne vous suffisent pas. C'est tout l'intérêt d'un format CSV, on en fait ce qu'on veut.


Format des scripts

 "Alors que JMeter enregistre ses scénarios en XML, Gatling les enregistre en Scala. Cela permet, Gatling gagne énormement en lisibilité et en maintenabilité, ce qui permet à des développeurs de monter des scénarios parametrés complexes plus intuitivement qu'avec JMeter, qui vise lui un public d'administrateurs systèmes"

Cet argument largement répandu par Gatling est totalement faux, aucun utilisateur de JMeter (sauf ceux qui ne l'ont jamais utilisé ou ceux qui veulent en dire du mal :-) ) ne développe en XML.
Ainsi le scénario présenté dans l'article se traduit par autant de composants graphiques JMeter qu'il y a de lignes Scala, ci-dessous l'exacte reproduction du scénario:



Si vous voulez quand même un DSL, alors allez voir:
C'est à base de ruby.

Simplicité:
" monter des scénarios parametrés complexes plus intuitivement qu'avec JMeter,"


Pour la simplicité je vous engage à vous abonner à la mailing list Gatling pour voir la "simplicité" en action.

C'est simple pour un scénario de type "Hello World" beaucoup moins pour un scénario de type "Real World" :-) .

D'après mon expérience assez longue en test de charge, on est toujours plus ou moins confronté à des cas où il faut passer par de la manipulation des requêtes et réponses, pour cela:

  • JMeter propose multitude de langages (du plus simple au moins simples):
    • Groovy
    • Javascript
    • Beanshell
    • Java
    • Scala :-)
    • ...
  • Gatling propose uniquement Scala, à moins d'être un développeur assez "hipster", Scala est puissant mais tout sauf simple



Utilisateurs de JMeter
"JMeter, qui vise lui un public d'administrateurs systèmes"


Le public utilisateur de JMeter va du développeur, en passant par l'expert technique, le testeur QA jusqu'à l'administrateur, le restreindre à un public "d'administrateur systèmes" est la seule affirmation de l'auteur sans doute destinée à dire "JMeter s'adresse à des barbus autistes devant leur PC ?, je n'ai rien contre les administrateurs systèmes :-)".

Je ne dirais pas la même chose de Gatling qui lui semble clairement orienté développeur, et plutôt développeur Scala dès lors qu'on rentre dans le dur, car jusqu'à présent, chaque fois que j'ai eu à faire un test de charge d'applications Internet ou Intranet, j'ai dû passer par du Scala pour Gatling ou du Groovy (mais ça pourrait être autre chose si vous voulez, même du Scala) pour JMeter.

Quand à cette affirmation très à la mode issue du mouvement "DevOps" du développeur qui teste les performances de ses développements, je la mets très fortement en doute pour les raisons suivantes:
  • Est-ce que n'importe quel développeur est capable de tester son développement et surtout de le faire là où c'est nécessaire ? saura-t-il lui même dès le début déterminer les parties les plus utilisées ? les parties les plus critiques ?
  • Sur une base de développement, les tests sont-ils représentatifs ?
  • N'est-ce pas finalement une perte de temps et d'argent de tester trop tôt les performances ? Mon expérience me le prouve
  • Dans les projets que je connais, les budgets sont déjà assez ric rac pour souvent mettre de côté les tests unitaires, alors les tests de charge dès le développement, chez les grands du web peut être mais ailleurs ?
  • Quel regard critique un développeur a-t-il sur ses propres développements ? je ne parle pas du développeur expérimenté mais du développeur débutant qui constitue malgré tout la majorité des développeurs (malheureusement ? )

Simple à lancer

"Il est ainsi possible de faire tourner un test de charge sur n'importe quelle machine qui possède une JVM plus simplement qu'avec JMeter, qui lui nécessite de copier séparément le programme et le scénario."


C'est exactement la même chose pour JMeter. Argument tendancieux car je ne vois pas en quoi le fait d'avoir un fichier de test séparé complexifie en quoi que ce soit la configuration.


"Avant d'être fournis au scénario via la fonction feed, les paramètres sont chargés depuis le fichier CSV de façon «circulaire». Cela permet de ne jamais être à court de valeurs quelque soit le nombre d'utilisateurs qui jouerons le scénario. Ainsi le premier utilisateur à jouer le scénario utilisera la première ligne de valeurs (la seconde dans le CSV), le second la suivante et le troisième jouera son scénario avec les mêmes valeurs que le premier utilisateur."

Ceci existe aussi dans JMeter, c'est la config par défaut de CSV Data Set Config:



Tenue en charge

 "Gatling gère bien mieux les resources du système sur lequel il tourne et est donc beaucoup moins gourmand que JMeter."
Cette affirmation est encore issue de l'historique JMeter (et des présentations Gatling), qui a connu sur d'anciennes versions des problèmes de fuite mémoire, mais qui n'est plus du tout d'actualité sur les versions récentes de JMeter, sauf à faire les erreurs classiques des débutants décrites ici:


Pour les OutOfMemory, je vous laisse également vous abonner à la mailing list Gatling.
On lira aussi par exemple:



Même Stéphane Landelle le créateur de Gatling, a reconnu récemment (après un JMeter Bashing assez fabuleux) que les performances JMeter étaient devenues bonnes :-) (moi je les ai toujours connues très bonnes):


On notera de façon ironique que Gatling a évolué sur la critique de JMeter:

  • Au début, ils disaient "JMeter n'arrive pas à monter en charge, il génère des OutOfMemoryExceptions, bien sûr le plan de test contenait les erreurs classiques
  • Après il y a eu la critique de la forme de la courbe sur http://wiki.apache.org/jmeter/JMeterPerformance, lire mon article sur ce sujet . Après mon article, l'argument a été supprimé de leur site.
  • Il reste le XML (Gatling présent ce dernier comme le DSL de JMeter alors que comme dit plus haut, aucun utilisateur de JMeter (hormis les débutants mal orientés ?)) ne manipule ce XML
  • Quel sera le prochain argument ?


Enfin sur la tenue en charge, il serait pertinent de comparer les performances sur un vrai scénario.

Le scénario exposé par exemple dans l'article de SMILE contient au passage un anti-pattern classique du testing qui consiste à ne pas vérifier les réponses du serveurs. Peut être est-ce pour la simplicité mais je vois tellement souvent ce genre de tests...


On lira avec attention ce Benchmark qui montre qu'un JMeter arrive à simuler 10000 Utilisateurs Virtuels sur une JVM à 4Go sur une machine de type m1.xlarge (configuration assez standard finalement) :
Et on notera au passage que:
  • Certes le comportement du GC est meilleur pour Gatling du fait de son architecture asynchrone (avec beaucoup de contraintes que j'essaierai d'expliquer dans un prochain blog)
  • Mais la consommation CPU n'est pas très éloignée de celle de JMeter 2.10

Il n'est donc pas dit que vous ne serez pas obligé d'avoir la même configuration machine pour le même nombre d'Utilisateur Virtuels avec les 2 outils soit du fait de la CPU soit du fait du débit réseau nécessaire.


JMeter vs Gatling

"En conclusion, Gatling apporte simplicité et performance, ce qui permet de réaliser des tests de charges de façon plus rapide et productive qu' avec JMeter, tout en supportant une volumétrie plus importante."

Cette conclusion a sans doute été "naïvement" recopiée des présentations Gatling car sauf à être un débutant comment peut-on comparer ces 2 outils sans prendre en compte les aspects suivants:

  • Fournisseur : JMeter est un projet Apache TOP LEVEL(indépendant), Gatling dépend d'une seule société (Excilys)
  • Jeunesse de Gatling et instabilité de son API:
    • Je parle en connaissance de cause, je l'ai utilisé au début, et d'une version mineure à l'autre l'API changeait et change encore constamment. L'API V2 change encore de façon importante. Du coup je devais constamment mettre à jour mon script pour suivre les versions... Comment justifier cette charge en entreprise ?
  • Jusqu'à la sortie de la V2 (puis rétro sur une 1.5), la gestion des connexions HTTP n'était pas réaliste, voir:
  • On note encore un support de HTTP incomplet puisqu'il a fallu attendre le bench de flood.io pour que les 304 soient gérées correctement
  • Et la liste des fonctionnalités de JMeter absente de Gatling est longue comme le bras (Téléchargement des ressources (toujours en cours de dev le 11/2013), scaling horizontal, pacing très jeune, support de protocoles (LDAP, JDBC, JMS (plugin tiers très jeune), MongoDB, appels Natif, foison de fonctionnalités le rendant hyper flexible)...
  • Difficulté de la corrélation dans Gatling (La corrélation consiste à injecteur dans une requête N+X un élément provenant d'une réponse N-X) car contrairement à JMeter il n'y a pas de présentation des requêtes/réponses dans un arbre. Il faut utiliser le debugging Scala ou les logs ... bon courage. Etrangement je ne lis jamais aucune mention de ce point critique, est-ce à dire que les tests écrits ne sont pas vraiment réalistes ?
  • JMeter a 14 ans d'âge (même s'il est activement développé), dans le monde du test cela a un énorme intérêt, il a de ce fait été utilisé pour tester multitude d'applications pas tout à fait standards en terme d'encodages, d'URLs (et d'après mon expérience, c'est monnaie plus que courante), tous ces cas se présenteront à Gatling, ils sont déjà traités par JMeter.
  • Documentation, ressources, blogs, formations diverses
  • Quelques exemples de modestes utilisateurs :
  • Une intégration continue à l'aide de Maven, Jenkins:
  • La possibilité de tirer des centaines de milliers à millions d'utilisateurs à travers des solutions Cloud déjà préconfigurées:
  • Des plugins à foison:
    • JMeter a des plugins gratuits ou commerciaux pour de multiples technologies:
      • Cassandra (Plugin développé par Netflix , un petit du web :-) ?)
      • GWT
      • Flex
      • Java Serialisation
      • Websocket (HTML5)
      • MongoDB
      • ...

....


En bref, ma conclusion est plutôt:
Gatling est intéressant mais restons sérieux, JMeter est encore loin devant en terme de couverture fonctionnelle et reste très actif malgré son âge (4 versions en 18 mois) et les versions 2.10 et 2.11 apportent encore plein d'améliorations:


Hormis des Cas d'utilisation hors normes (> Millions d'utilisateurs SIMULTANES à ne pas confondre avec utilisateurs enregistrés sur un site web par exemple) JMeter peut répondre à une charge très élevée sans problèmes.

Quelques liens utiles sur JMeter pour voir sa popularité et sa qualité:
Le compte twitter de JMeter: