Actualités

[22/05/2017] Des Smiliens récompensés lors du Hackathon Carrefour !

Notre équipe, composée en partie de Smiliens, a remporté le Prix du Code et celui de l'Incubation lors du Hackathon Carrefour, organisé ce week-end à Paris !

[18/05/2017] OpenShift, le nouveau livre blanc Smile !

Smile publie aujourd'hui un livre blanc dédié à OpenShift, le PaaS open source orienté DevOps. A télécharger dès maintenant !

[15/05/2017] Smile décroche le label HappyAtWork 2017 !

Pour la 2ème année consécutive, Smile obtient le label HappyAtWork for Starters qui récompense les entreprises où il fait bon débuter sa carrière !

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

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire