Actualités

[21/07/2017] Smile lance les premiers vélos solaires connectés à l’occasion du Sun Trip Tour 2017

Smile, leader des solutions IoT et open source, confirme sa solide expertise sur le marché de l’embarqué en participant activement à la course de vélos solaires du Sun Trip Tour.

[03/07/2017] Smile remporte le Drupagora d'Or 2017 du meilleur site e-commerce

Le vendredi 30 juin, la 3ème édition des Drupagora d'Or s'est déroulée à Paris.

[30/06/2017] Découvrez les projets de nos équipes au Hackathon Data Énergie

Les 29 et 30 juin, le Hackathon Data Énergie s'est déroulé au Liberté Living Lab à Paris.

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

Gatling, une alternative à JMeter

Au même titre qu'Apache Benchmark ou Apache JMeter, Gatling est un outil de stress d'applications . Apache Benchmark est un outil utile pour des tests de charge basiques (stress d'une seule URL) mais dès que l'on souhaite tester un scénario, il est indispensable d'utiliser des outils plus complets comme JMeter ou Gatling.
Jmeter n'est plus à présenter tant il est utilisé depuis de nombreuses années. Toutefois, il n'a pas réellement évolué afin de s'adapter aux enjeux actuels dans le domaine des tests de charge, c'est précisément ce que tente de faire Gatling.

Commençons par leurs points communs :

  • Tous les deux tournent sur une Java Virtual Machine (JVM). JMeter étant écrit directement en Java, Gatling en Scala, un langage compilé en byte code Java.
  • JMeter et Gatling permettent d'enregistrer un sénario grâce à un mode dit «proxy». Ce mode vous permet de naviguer sur le site que vous voulez tester afin de définir un scénario qui sera joué lors de votre test de charge.
  • Tous les deux permettent de créer des scénarios complexes et paramétrés via des fichiers externes.
  • Gatling, malgré sa jeunesse, est déjà parfaitement intégrable au sein d'un build process Maven au même titre que JMeter. Cela permet de réaliser des tests de charge automatiques dans le cadre d'une intégration continue, et ainsi vérifier automatiquement que les dernières modifications n'ont pas dégradé les performances de l'application.

Passons au différences :

  • Les tests JMeter peuvent être lancés en mode graphique et en ligne de commande. Gatling, lui,  ne lance des tests qu'en ligne de commande.
  • 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.

La différence la plus notable est le format de desciption des scénarios. 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. Un autre avantage  du scala sur le XML est qu'il est possible de le packager dans un jar executable. 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. Cela se révèle très utile lorsque l'on désire faire un test de charge sur des machines distantes. Voici un exemple de scénario écrit en Scala :

val valuesFeeder = csv("datas.csv").circular
val scn = scenario("Mon test")
    .feed(confFeeder)
    .exec(http("Home page")
      .get("http://monsite.com/"))
    .pause(10)
    .exec(http("Recherche de base")
      .get("http://monsite.com/recherche")
      .param("monParam", "${maValeur}")
      .param("monAutreParam", "${maAutreValeur}")
   .users(5)
   .ramp(10)
setUp(scn)

Accompagné d'un fichier datas.csv comme celui-ci :

maValeur,monAutreValeur
3,test
19,ma valeur

Ce sénario aura pour effet de :

  • Charger la page d'accueil de monsite.com
  • Attendre 10 secondes
  • Faire une recherche en passant deux paramètres dont les valeurs sont fournies dans le fichier csv.
  • Le tout est joué par cinq utilisateurs qui se connectent un à un en 10 secondes (soit une nouvelle connexion toutes les deux secondes).

Le fonctionnement des paramètres mérite une attention particulière. 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.

Enfin, grâce au framework Akka et à son pattern acteur, Gatling gère bien mieux les resources du système sur lequel il tourne et est donc beaucoup moins gourmand que JMeter. Cela permet de faire des simulations plus volumineuses et de retarder grandement la mise en place d'un cluster de machines de tests.

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.

Xavier DETANT
picto

Commentaires

       
Philippe Bossu
Graphes : Voir JMeter plugins, les graphes sont beaucoup plus riches

XML : Cet argument largement répandu par Gatling est totalement faux, personne ne développe en XML avec JMeter,
et le scénario que vous présentez se traduit par autant de composants JMeter qu'il y a de lignes Scala.
Enfin si vous souhaitez vraiment écrire un DSL, alors voir Gridinit-JMeter.
Quant à la simplicité je vous engage à vous abonner à la mailing list Scala pour voir la "simplicité".
Le CSV "circulaire" est tout à fait faisable dans JMeter.

Le public JMeter va du développeur, au testeur jusqu'à l'administrateur, c'est votre seule affirmation.
Voir tous les plugins qui existent.


Concernant l'exécution plus simple sur n'importe quelle machine, 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 le tir.


Enfin sur la tenue en charge, il serait pertinent de comparer un vrai scénario.
Le scénario que vous exposez par exemple dans cet exemple contient un anti-pattern du testing,
puisque vous ne vérifiez même pas les réponses obtenues.

Enfin vous ne parlez nulle part de la jeunesse de Gatling et de ses impacts:
- APIs qui change constamment, vos tests sont à modifier d'une version à l'autre. Avec la V2 vous pouvez tout réécrire
- Stabilité (voir mailing list)
- Côté réaliste (voir la façon dont Gatling gérait les connexions jusqu'à il y a très peu de temps
- La difficulté de debugger pour variabiliser
....

En bref, article du type "Hello World" .
Mais bien sûr je doute que mon commentaire soit publié.

mercredi 10 juillet 2013 @ 8:30
       

       
Philippe De Oliveira
"Graphes : Voir JMeter plugins, les graphes sont beaucoup plus riches"

=> Oui mais il faut des plugins

"XML : Cet argument largement répandu par Gatling est totalement faux, personne ne développe en XML avec JMeter,
et le scénario que vous présentez se traduit par autant de composants JMeter qu'il y a de lignes Scala."

=> Si personne ne "développe" en XML avec JMeter c'est précisément parce que c'est impossible ! Or avec du Scala (ou tout autre DSL) c'est quand même beaucoup plus simple, surtout pour un public de développeurs. D'expérience, je sais pertinemment que les développeurs sont rebutés par la GUI de JMeter et pas par le Scala. En bonus, on peut versionner efficacement son scenario alors que versionner le XML de JMeter... comment dire... autant le traiter en binaire et pas en texte :-)

"Enfin si vous souhaitez vraiment écrire un DSL, alors voir Gridinit-JMeter."

=> Pas mal en effet (à part que c'est du Ruby, mais c'est une autre histoire :-)), mais encore un outil de plus.

"Quant à la simplicité je vous engage à vous abonner à la mailing list Scala pour voir la "simplicité"."

=> Et moi je vous engage (?) à faire un sondage auprès de développeurs sur ce qu'ils pensent du XML de JMeter. Sinon, on peut aussi regarder la complexité que représente l'utilisation de tous ces plugins (DSL, Graphes, etc.)

"Le CSV "circulaire" est tout à fait faisable dans JMeter."

=> A-t-on dit le contraire ? Nous expliquons simplement son usage dans ce scénario.

"Enfin sur la tenue en charge, il serait pertinent de comparer un vrai scénario.
Le scénario que vous exposez par exemple dans cet exemple contient un anti-pattern du testing,
puisque vous ne vérifiez même pas les réponses obtenues."

=> Le but ici était de présenter la syntaxe du scenario de façon concise, rien de plus.

"Enfin vous ne parlez nulle part de la jeunesse de Gatling et de ses impacts:
- APIs qui change constamment, vos tests sont à modifier d'une version à l'autre. Avec la V2 vous pouvez tout réécrire
- Stabilité (voir mailing list)
- Côté réaliste (voir la façon dont Gatling gérait les connexions jusqu'à il y a très peu de temps)
- La difficulté de debugger pour variabiliser
...."

=> C'est chose faite grace à votre commentaire, merci :-)

"En bref, article du type "Hello World".
Mais bien sûr je doute que mon commentaire soit publié. "

Vraiment ?
mercredi 10 juillet 2013 @ 11:50
       

       
Philippe Bossu - http://t.co/a4HDmX9aOb
Je ne m'attendais pas à ce que mon commentaire soit publié, je suis agréablement surpris, bravo pour cet honnêteté !

Merci pour vos réponses, bien sûr je ne suis pas d'accord mais je les entends :-)

On verra avec la version à venir de JMeter, il paraît qu'il y a plein d'améliorations ergonomiques.
Pour le DSL pour moi c'est une vision développeur.
En effet si le développeur teste son application, il sait quelle URL a changé et peut le faire évoluer.
C'est aussi faisable en JMeter dans ce cas.

Par contre quand vous n'êtes pas le développeur de votre application, il est très difficile de savoir quelles URLS ont changé, vous êtes donc bon pour réenregistrer et là je doute que Gatling ou JMeter vous permettent de réutiliser beaucoup votre script.

Or dans mon expérience, je teste en charge beaucoup plus d'application que je n'ai pas développées, donc ça s'applique finalement assez peu.

Je vous accorde néanmoins l'argument du versionning :-).

Sinon j'ai développé beaucoup des arguments ici:
http://bit.ly/18LjAX8
vendredi 12 juillet 2013 @ 8:10
       
Ecrire un nouveau commentaire