View
223
Download
6
Category
Tags:
Preview:
DESCRIPTION
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.
Citation preview
1 Tél : +212 537 778 843 www.octo.com
© OCTO 2014
59, Avenue al Amir Fal Ould Oumeir 10000 Agdal, Rabat - MAROC
Performance User Group – Casa 24 septembre 2014
Benoît de CHATEAUVIEUX
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
! 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.
Pourquoi parler de performances ?
4
2 éléments de contexte
5
! 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 !
Contexte #1: la génération Y
6
Contexte #2: le mobile
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
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
! 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
Gatling
11
Fonctionnement de Gatling
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
1. Enregistrement d’un scénario 2. Exécution d’un tir de charge 3. Consultation du rapport
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
Démonstration
14
Le recorder Gatling
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
Le DSL Gatling 2/6 Eléments de scénario Déclaration du 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
! 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
! 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
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
! 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
! 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.)
Tests incluant les ressources statiques
22
Consulter les rapports Gatling
23
Intégration Graphite
24
! Enregistrer un scénario ! Le modifier ! Tirer de la charge ! Consulter les rapports
Injecteur
25
Le plugin Maven pour intégrer Gatling dans Jenkins
26
Les rapports Gatling dans Jenkins
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é
Recommended