démo gatling au performance user group de casablanca - 25 sept 2014

Post on 18-Jun-2015

223 Views

Category:

Engineering

6 Downloads

Preview:

Click to see full reader

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.

TRANSCRIPT

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é

top related