jeudi 2 janvier 2014


Performances of Gatling-vs-JMeter FACT CHECKING:

"all competitive benchmarking is institutionalized cheating." Guerrilla Manifesto


"Gatling has much better performances than JMeter, See for yourself!" and the following 2 graphs are shown":

Gatling 1.3.2:

JMeter 2.8:


I have been following with interest the hype around Gatling that has been running since a year and few months.
The tool looked interesting (asynchronous system, reactor pattern...), I used it a bit at home and on a non critical project to see it at work, I did not continue using it in a professional context due to highly unstable API, limited features compared to JMeter, incomplete HTTP protocol at the time I started with Gatling 1.
HTTP protocol implementation seems now close to complete, but other issues mentioned remain.
Note I wrote in a previous blog about my experience and thoughts on Gatling.
This page presents a Benchmark made by Gatling Team which is supposed to be the equivalent of a benchmark ran by Apache JMeter team and mentioned on JMeter Wiki:

I don't know what was the exact intention of this page, was it to kind of discredit JMeter by saying it didn't inject in a stable way the load correctly on Tomcat, the conclusion being "how can you trust results guys ?", seems so:

Slide content:

The Mystery
One thing that always disturbed me was the very neat look of their graph "Number of transactions per second" :

I don't know why but it always looked suspicious to me from my experience and technical skills in load testing.

Another thing that annoyed me and looked very non scientific was the following quote on benchmark page which said benchmark was ran in "quite similar conditions" which is:
  • same local Tomcat 6.0.24 with same heap options => OK
  • Mac OS X 10.8.2 => KO, JMeter benchmark mentions 10.6.8
  • Hotspot 1.6.0_35 => KO, JMeter benchmark mentions 1.6.0_29
  • 2.3 GHz Intel Core i7 proc => KOJMeter benchmark mentions 3.06 GHz Intel Core 2 Duo
  • default Gatling JVM options (512Mo heap) => OK
Note also that Benchmark strangely uses a pretty old version of Gatling, the version 1.3.2, while page was updated when newer versions had been released.

In all these "similar conditions", the big key difference that hurt me was the Processor big difference, Intel Core i7 (used in Gatling benchmark) being 50% faster than Intel Core 2 Duo (used in JMeter benchmark):
I tweeted recently with Stéphane Landelle (Developer of Gatling) about it and his answer was that he had made the test on old machine but forgot to update website, I must say this gave me the idea to take some time and work on the benchmark myself:

At time of Gatling 1.3.2, I ran the same benchmark on my machine which is similar to the JMeter benchmark, and what disturbed me was the different behavior of Tomcat instance depending on wether it was Gatling or JMeter running the test (much lower number of connector threads were started when Gatling was the Load Test Engine).

I made again the test with 1.4.2 and still got this difference and always that perfect graph.

So I said to myself, man you're stupid, there's a mystery you don't understand...

Mystery Uncovered:

This became suddenly clear to me with the release of Gatling 2 and backport to Gatling 1.5.0:
  • In Gatling 1 (before 1.5.0), connections are shared amongst users. This behavior does not match real browsers, and doesn't support SSL session tracking.
Then I had to take some time to run the test and write that blog.


Benchmark conditions are the same as the JMeter page , except for the following below in BOLD:
  • Tomcat version 6.0.24
  • Tomcat JVM : -Xms256m -Xmx1024m
  • JMeter JVM : -Xmx512m (Default options) plus the same algorithm as Gatling for GC:
    • -XX:+UseParNewGC 
    • -XX:+UseConcMarkSweepGC 
    • -XX:+CMSParallelRemarkEnabled 
  • Gatling JVM :  -Xmx512m (Default options)
  • Set session timeout in web.xml to 1 minute

In web.xml, add this:



Software versions:
  • JMeter:  the same one mentionned here
  • Gatling: I added disableCaching call to be in the same conditions as JMeter benchmark which does not use Caching feature (no HTTP Cache Manager in Test Plan), script on Gatling website worked in Gatling 1.3.2 because there was also a bug in caching, currently with 1.5.3 it fails on status 200 check, as one GET gets cached (so 304 response).

Gatling script  (in red the only modification I made):



Gatling 1.5.3:

As you can see graph is a bit different from Gatling Home one !, less perfect !

Now lets zoom to be in the same conditions of JMeter (no ramp down):

Wow, the graph looks much less "PERFECT", unzoom is tricky yes !

JMeter 2.11:
This is the result of using the great jmeter-plugins.
To be in the same display conditions as Gatling which has one point per second, I set the option "Limit number of points in row" to 607 (Test lasts 10 minutes and 7 seconds):

And here is what we get:


Now let's scale the JMeter Graph (bottom graph) to have the same display ratio as Gatling one (top one), and here is what we get:

WOW, No graph is perfect and they are pretty the same !!!!

Lessons learned:

  • Beware of Benchmarks conditions and what you think are "quite similar conditions"
  • Beware of Magical Tools and perfect graphs in Load Testing world:
    • Connection sharing gives better performances and cleaner graphs , YEAH BUT it is not realistic, Hey man, we don't want to load test your load test engine we want to load test the customer application ! 
  • Beware of Reports:
    • Unzoom, when something is added (ramp down) it distorts the perception
    • Graph proportions, it distorts the perception
  • Beware of hipsters, "cool nerds", don't be a sheep and never forget Saint Thomas:
    • I'll believe that when I see it!
My moto is even more:
  • I'll believe that when I test it!

Now don't believe me, and go do the test for yourself girls and guys !

UPDATE 03 january 2014:

  • The High Performance link has disappeared from Home Page but Internet is great you can still find an old version here:
I made a screenshot of page as of 2 january 2014:

  • The benchmark page content has changed, I am happy I have been so convincing ! :-) , you can see Gihub page history:

I had made some screenshots of its content:

Regarding what is said in new Benchmark page, the flawed bench is due to 4 factors:
  • Unrealistic behavior due to connection sharing at time of 1.3.2
  • Bug in caching feature as Benchmark page now mentions it
  • Wrong comparison of reports due to ramp down additional part which unzooms the graph
  • Different graph proportions which favored Gatling, graph height being small 

What I find funny is a page made to discredit JMeter and used accross so many presentations including Devoxx, JUGs and Duchess events finally kinds of discredits Gatling, 
"Hung by his own rope"

    mardi 9 juillet 2013


    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.

    " 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, 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 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: