En 2008, la lenteur d'une application était ressentie au bout de 4 secondes, elle l'est au bout de 3 secondes en 2014. La performance des applications web est devenue cruciale: la génération Y est beaucoup moins patiente (elle n'a pas connue le modèle 56k !) et switch très facilement. Les impacts business de la performance des applications web sont donc forts: baisse de CA, perte de clients, etc. Au cours de cette session du Performance User Group de Casablanca, j'ai présenté Gatling, un outils de test de charge Open-Source, simple, hautement scalable et intégrable dans une démarche de tests de performance en continue.

1. 1
Performance User Group – Casa
24 septembre 2014
Tél : +212 537 778 843
www.octo.com
Benoît de CHATEAUVIEUX
© OCTO 2014
59, Avenue al Amir Fal Ould Oumeir
10000 Agdal, Rabat - MAROC

2. 2
! Benoît de CHATEAUVIEUX
! Architecte @OCTO Maroc
! @benChato
! Co-organisateur du « Casablanca Hadoop & Big Data User Group »
! Rendez-vous le 15 octobre !
A propos

3. 3
Pourquoi parler de performances ?
! D'après des études, la lenteur d'une application était ressentie au bout de 4
secondes en 2008, elle l'est au bout de 3 secondes en 2014.
! è ce qui dénote bien les enjeux en termes de performances sur le web.
! Google found that a 500ms slowdown equals 20% decrease in ad revenue.
! Microsoft Bing found that a 2-second slowdown means a 2.5% decrease in
queries and overall clicks.
! Amazon finds a 100ms slowdown - one tenth of a second! - can mean a 1%
decrease in revenue.
! Yahoo! found that a 400ms improvement in load time translated to a 9%
increase in traffic.
! Mozilla mapped a 2.2s improvement to 60 million additional Firefox downloads.

4. 4
2 éléments de contexte

5. 5
Contexte #1: la génération Y
! La nouvelle génération née dans la ferveur technologique du 21ème siècle n'a
pas connu les modems 56k contrairement à ses ainés.
! Elle est habituée à l'instantané et est donc bien moins patiente !

6. 6
Contexte #2: le mobile

7. 7
Notre temps en ligne
! Notre temps en ligne se répartie sur 4 grands types de devices:
! Sédentaire: ordi tv
! Nomade: tablette portable
! Mobilité: smartphones
! >50% temps sur des écrans autres que l’ordinateur de bureau

8. 8
1. Welcome to the Pet Clinic
2. Tirer de la charge sur la Clinic
3. Voir ce qui s’y passe
4. Diagnostiquer (RAM et fuite)
Agenda

9. 9
! Nous allons utiliser la Pet Clinic (application de référence Spring)
! https://github.com/spring-projects/spring-petclinic
! Warning: version un peu modifiée qui a des fuites mémoire J
La clinique

10. 10
Gatling

11. 11
Fonctionnement de Gatling

12. 12
! Gatling est composé de
! 3 projets Maven
! 9 modules Maven
! Gatling: Open-Source, Licence Apache
! VTD (ajout de l’extraction Xpath). Basé sur VTD-XML è Licence GPL
! Gatling Highcharts: Pas Open-Source
Projets

13. 13
1. Enregistrement d’un scénario
2. Exécution d’un tir de charge
3. Consultation du rapport
Démonstration
Le dossier d’installation de Gatling est organisé selon l’arborescence suivante :
• /results : Contient les résultats des benchs sous format web
• /bin : Contient les scripts permettant de lancer Gatling
• /target : Contient les fichiers issus de la compilation de nos scénarios + cache
• /conf : Contient les fichiers de configuration (niveau de log…)
• /user-files : Contient les fichiers .scala de définition des scénarios
• /lib : jar de gatling

14. 14
Le recorder Gatling

15. 15
Le DSL Gatling 1/6
Structure
Import scala
Nom de la simulation
Eléments de configuration
valables pour toute la
simulation
Déclaration de header HTTP
(réutilisable pout toute les
requêtes de ressource PNG)

16. 16
Le DSL Gatling 2/6
Déclaration du scénario. Eléments de scénario
Peut contenir:
• Etape d’exécution (exec)
• Groupe d’étapes (group)
• Pause
• De la logique (doIf & doIfOrElse)
• Des boucles (during, asLongAs,
foreach, tryMax)
• Des conditions d’arrêt du thread
(exitBlockOnFailed & exitHereIfFailed)
« http » déclare une requête HTTP qui
peut être
• Get
• Post
• Put
• Delete
• Head
« http » permet également de déclarer:
• queryParam
• Header (un header)
• Headers (une Map de headers)
• BasicAuth
• Body (body de la request)
• FileBody (body stocké dans un fichier Gatling)
• ByteArrayBody
• Param (paramètre du body)
• Upload (pour les requêtes multi-part)

17. 17
! Les vérifications
! Regex (vérifie la présence de patterns sur le body)
! status
! Il y a d’autres vérifications
! currentLocation (test l’URL de la réponse après redirections)
! Header
! responseTimeInMillis & LatencyInMillis
! Xpath & jsonPath & css
! Md5 & sha1 (vérifie le hash de la réponse)
Le DSL Gatling 3/6
Checks
Il y a 5 liens HTTPS dans la réponse
Il y a 2 liens HTTPS dans la réponse et ils
pointent vers …
Le code de statut est 200 - OK
Le code de statut est compris entre 200 et 210
Il y a au moins 2 occurrences du mot aWord
La réponse ne contient pas aWord

18. 18
! Expression Language
! Nous venons de voir que regex permet d’extraire des données de la réponse
! SaveAs("key") stocke la valeur extraite dans la session
! Ex: jSessionID, Token CSRF, référence produit, etc.
! Puis l’expression EL ${"key"} dans une chaîne récupère cette valeur de la session
! "${myKey(i)}" (dans le cas où la variable myKey est multivaluée)
! "${myKey.size()}”
! "${myKey(myRank)}” (où myRank est galement une variable de session)
! Une session est immutable
! Il est possible de debugger ou manipuler la session
Le DSL de Gatling 4/6
Session

19. 19
Le DSL de Gatling 5/6
Variabilisation
! Un Feeder est
! Un objet partagé entre les utilisateurs
! Qui injecte une variable dans la session de l’utilisateur
! A chaque fois qu’il est appelé
! Sources
! Fichiers (csv, ssv, tsv)
! JDBC & Redis
! Custom
! Stratégies
! Queue
! le premier enregistrement est supprimé de la queue et injecté dans la session
! Stratégie par défaut
! Random
! Circular

20. 20
! Permet de tester des statistiques sur l’exécution du scénario
! responseTime
! allRequests (nb de requêtes)
! failedRequests (nb de requêtes en erreur)
! successfulRequests (nb de requêtes en succès)
! requestsPerSec
! Sur l’ensemble du scénario (global) ou un périmètre restreint d’URLs (details)
! Métriques sur les temps de réponse
! Min, max, mean, stdDev, percentile1, percentile2
! Métriques sur le nombre de requêtes
! Percent, count
! Conditions
! lessThan(threshold)
! greaterThan(threshold)
! between(thresholdMin, thresholdMax)
! is(value)
! in(sequence)
! assert(condition, message)
Le DSL de Gatling 6/6
Assertions

21. 21
Tests incluant les ressources statiques
! 2 options pour inclure les ressources statiques
1. On enregistre les ressources statiques au moment de l’enregistrement du
scénario
2. Le script « infère » automatiquement les ressources statiques
! En browsant les pages HTML renvoyées par le serveur à la recherche d’url
! inferHtmlResources()
! silentResources() permet de ne pas « polluer » le rapport avec les request/
responses liées aux ressources statiques (CSS, JS, images, etc.)

22. 22
Consulter les rapports Gatling

23. 23
Intégration Graphite

24. 24
! Enregistrer un scénario
! Le modifier
! Tirer de la charge
! Consulter les rapports
Injecteur

25. 25
Le plugin Maven pour intégrer Gatling dans Jenkins

26. 26
Les rapports Gatling dans Jenkins

27. 27
! Pourquoi intégrer les tests de charge Gatling dans Jenkins ?
! Pour les piloter facilement
! Pour archiver les rapports
! Pour tracer les résultats
! Jenkins peut donc être utilisé pour piloter des tests de charge vers une
plateforme de pré-production, par exemple
! Le source des scénarios de test Gatling se trouve dans un projet versionné
! Il peut être opportun de tester la performance en continu avec le plugin Maven
! Sur une plateforme de recette, par exemple
! Si les données sont stables et significatives (volume, etc.)
! Attention !
! Ces tests ne permettent pas de valider la tenu en charge ni le dimensionnement des
serveurs
! Ils permettent juste de détecter au plus tôt des régressions sur les temps de réponse
! Cela permet également de constituer au fil des itérations un patrimoine de scénarios
de test de charge
Opportunité