Compte rendu de la soirée Tests de charge avec Gatling

Un petit problème de salle, nous a fait découvrir les magnifiques locaux de Col’In.Et donc au au final, ça c’est bien passé !
La présentation s’est déroulée en trois parties :

• Stéphane fait des rappels sur les tests de charge, performance, stress …
• présentation Gatling en duo avec Pierre
• une session de questions / réponses et démonstration immédiate par le code

Gatling, faites tomber la foudre

Ce qu’on a particulièrement retenu

1. L’insoupçonnée influence du [ISP]aaS sur les tests de charge:
   C’est fini le temps du serveur surdimensionné qu’on budgète pour le projet. Aujourd’hui, avec la location de services, la facture vous rappelle chaque mois que des tests de charges pourraient vous faire gagner de l’argent !
   Le Green-IT est aussi un bon argument pour ces tests.
2. L’effet « intervention extérieure ».

Oui, c’est souvent ce qu’il faut pour se rendre-compte que la dette technique est partie à la dérive.
Donc avant même de démarrer les tests de charge, il faut s’assurer que le frein à main est desserré:

• Regarder ce qui se passe sur le client (Javascript, utiliser Firebug, PageSpeed Insight …)
• Regarder sur le serveur : VisualVM, loguer les requêtes SQL …

D’un autre coté, cela peut être l’occasion de présenter des améliorations de 200%, là où la plupart des projets sont contents de gagner 10%.

Le projet Gatling est sous une licence Apache très libre. Ainsi, certaines sociétés proposent des services de tests de charge en embarquant du Gatling sous le capot.
Le projet est né d’un réel besoin de consultant réalisant des prestations de tests de charge. JMeter a ses limites et avait jusqu’à  peu guère de concurrents sérieux.
Donc, il y a un an et demi environs, naissance du projet avec 4 points clés:

• Asynchrone
• Sortir du paradigme 1 utilisateur =  1 thread
• IO non bloquantes
• du texte ! « Un DSL oui, du XML éditable à travers une interface ad-hoc non ! »

Pour l’implémentation, Play! semble avoir été une source d’inspiration, l’équipe a donc choisit Scala, le modèle Actors et DSL. Puissant à l’intérieur, simple à l’extérieur.
L’API est très bien pensée, Gatling est utilisé pour des tests de charge sur HTTP, mais dès le départ, il a été conçu « protocol agnostique » et donc il existe des modules pour d’autres protocoles (hélas pas disponibles en opensource).
C’est d’ailleurs sans doute la force de l’outil d’avoir découplé le DSL, les API et le moteur d’exécution. Cela lui donne beaucoup de marge de progression : il sera possible de remplacer certaines parties sans tout casser.
Par exemple passer de Netty à Spray, utiliser le support du clustering d’Akka et surtout écrire des « drivers » pour d’autres protocoles: JDBC, LDAP, WebSockets … et même pour des API Java.

L’idéal en terme d’outils de tests de charge HTTP serait bien sûr d’émuler le navigateur. C’est l’approche de Sélenium pour les tests fonctionnels. Mais comment passer à l’échelle pour des milliers de navigateurs ? Bien que les performances s’améliorent pour les outils simulant les navigateurs, mais elles suffisent à peine à couvrir l’évolution des sites web. Combien d’onglets ouverts avant que votre machine ne soit à la ramasse: 20 ? 30 ?
Donc on n’échappera pas à Gatling.

Une question récurrente avec les tests concerne la maintenance. En quelques jours l’équipe de developpement peut ruiner des mois de travail. Quelque soit l’outil, il existe des solutions simples.
Ne pas laisser pourrir la situation:
– intégrer les tests de charge au processus de CI. Sans forcement bourriner le serveur, il suffit d’une exécution pour vérifier que le scénario passe.
– dans le cadre d’une équipe agile, les tests de charge ne sont pas isolé, séparé du reste des développeurs. Ca tombe bien, c’est du code, il est versionné comme du code, c’est développeurs friendly. (Pas clickodrome à la JMeter).

Ensuite le DSL de Gatling permet de factoriser les scénarios de tests. Une procédure de login ne s’écrit qu’une fois. En évitant les répétitions, en utilisant des identifiants clairs, comme « #id-button-ok » au lieu de « //div/form[7]/input[3] », on peut au moins limiter les dégâts.

Et comme ces questions amènent forcément à parler de DevOps : mention spéciale à Henry Gomez qui n’était pas là, malheureusement pour recueillir ses éloges.

Grand merci pour cette conférence à la fois proche du terrain et utilisant des techno de pointe.