© Henri Tremblay 2015
Henri Tremblay
Université de la performance: Initiation aux tests
de charge
2
Amateur de
Stratégie TI
Performance
Productivité
Fait de l’Open Source
Aime être utile
Henri Tremblay
Henri Tremblay
3
Agenda
Test de
performance
unitaire
Test de
charge
Test de
rupture
Test de
vieillissement
4
La mesure de performance
doit être au cœur du
processus de
développement
informatique
Notre vision ?
Source : Les géants du Web
5
PROD
Archi
Dev
Perf
6
PROD
Archi
Dev
Perf
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
4. Exécution auto-
matique des tests
#1 #2 #3
7
Archi
Dev
Perf
PROD
DélaiMEP À L’ARRACHE
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
4. Exécution auto-
matique des tests
#1 #2 #3
8
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
4. Exécution auto-
matique des tests
#1 #2 #3
PROD
Archi
Dev
Tests de charge en continue
9
Premature optimization is the
root of all evil - Donald Knuth
10
Il voulait dire ça:
// Do not use the for(Object o : list)
// because I think it is probably
// slower than doing this… Probably…
for(int i = 0; i < list.size(); i++) {
Object o = list.get(i);
…
}
Stop guessing dam it!!!
11
Code
Mesure
OptimiseLà où
c’est
important
12
LES DIFFÉRENTS TYPES DE TEST• Objectif: mesurer la performance unitaire
• Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque
étape du use case, on mesure le temps passé dans les différents
composants de l’application
Test de
performance
unitaire
• Objectif: mesurer la tenue en charge de l’application sur la population cible
• Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle
pendant 2h
Test de
charge
• Objectif: déterminer les limites de l’application
• Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application
jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus
acceptables
Test de
rupture
• Objectif: déterminer la capacité de l’application à fonctionner sur une
période étendue
• Ex: on simule l’utilisation de l’application pendant 48h, avec une charge
constante et égale à la charge moyenne
Test de
vieillissement
13
Exécution test unitaire
14
Les performances d’un
système sont une
spécification
fonctionnelle implicite
du système
Notre vision ?
Source : www.arthursclipart.org
15
Cible de performance
Exemples:
Temps d’affichage du détail d’un item: < 200ms
Nombre d’utilisateurs concurrents: 200
16
DÉMO
Exécution test unitaire
17
LES DIFFÉRENTS TYPES DE TEST• Objectif: mesurer la performance unitaire
• Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque
étape du use case, on mesure le temps passé dans les différents
composants de l’application
Test de
performance
unitaire
• Objectif: mesurer la tenue en charge de l’application sur la population cible
• Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle
pendant 2h
Test de
charge
• Objectif: déterminer les limites de l’application
• Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application
jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus
acceptables
Test de
rupture
• Objectif: déterminer la capacité de l’application à fonctionner sur une
période étendue
• Ex: on simule l’utilisation de l’application pendant 48h, avec une charge
constante et égale à la charge moyenne
Test de
vieillissement
18
DÉMO
Exécution test de charge
19
LES DIFFÉRENTS TYPES DE TEST• Objectif: mesurer la performance unitaire
• Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque
étape du use case, on mesure le temps passé dans les différents
composants de l’application
Test de
performance
unitaire
• Objectif: mesurer la tenue en charge de l’application sur la population cible
• Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle
pendant 2h
Test de
charge
• Objectif: déterminer les limites de l’application
• Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application
jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus
acceptables
Test de
rupture
• Objectif: déterminer la capacité de l’application à fonctionner sur une
période étendue
• Ex: on simule l’utilisation de l’application pendant 48h, avec une charge
constante et égale à la charge moyenne
Test de
vieillissement
20
DÉMO
Test de rupture
21
LES DIFFÉRENTS TYPES DE TEST• Objectif: mesurer la performance unitaire
• Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque
étape du use case, on mesure le temps passé dans les différents
composants de l’application
Test de
performance
unitaire
• Objectif: mesurer la tenue en charge de l’application sur la population cible
• Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle
pendant 2h
Test de
charge
• Objectif: déterminer les limites de l’application
• Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application
jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus
acceptables
Test de
rupture
• Objectif: déterminer la capacité de l’application à fonctionner sur une
période étendue
• Ex: on simule l’utilisation de l’application pendant 48h, avec une charge
constante et égale à la charge moyenne
Test de
vieillissement
22
DÉMO
Test d’endurance
23
LES DIFFÉRENTS TYPES DE TEST•1 utilisateur
•1 scénario
•Quelques itératinos
Test de
performance
unitaire
• Nombre espéré d’utilisateurs
• Plusieurs scénario
• 10 minutes et plus
Test de
charge
• Nombre croissant d’utilisateurs
• Plusieurs scénario
• Jusqu’à rupture (dégradation)
Test de
rupture
•Nombre espéré d’utilisateurs
•Plusieurs scénario
•Plusieurs heures
Test de
vieillissement
24
Les outils utilisés aujourd’hui
https://jhipster.github.io
https://visualvm.java.net/
https://www.yourkit.com/
https://www.jclarity.com/censum/
http://grafana.org/
https://influxdata.com/
https://www.docker.com/
http://gatling.io
25
@henri_tremblay
henri@tremblay.pro
http://www.montreal-jug.org/
Exemple de benchmark:
http://blog.octo.com/lart-du-benchmark/
http://brownbaglunch.fr

Confoo 2016: Initiation aux tests de charge

  • 1.
    © Henri Tremblay2015 Henri Tremblay Université de la performance: Initiation aux tests de charge
  • 2.
    2 Amateur de Stratégie TI Performance Productivité Faitde l’Open Source Aime être utile Henri Tremblay Henri Tremblay
  • 3.
  • 4.
    4 La mesure deperformance doit être au cœur du processus de développement informatique Notre vision ? Source : Les géants du Web
  • 5.
  • 6.
    6 PROD Archi Dev Perf 1. Conception des tests 2.Automatisation des tests 3. Développement logiciel 4. Exécution auto- matique des tests #1 #2 #3
  • 7.
    7 Archi Dev Perf PROD DélaiMEP À L’ARRACHE 1.Conception des tests 2. Automatisation des tests 3. Développement logiciel 4. Exécution auto- matique des tests #1 #2 #3
  • 8.
    8 1. Conception des tests 2.Automatisation des tests 3. Développement logiciel 4. Exécution auto- matique des tests #1 #2 #3 PROD Archi Dev Tests de charge en continue
  • 9.
    9 Premature optimization isthe root of all evil - Donald Knuth
  • 10.
    10 Il voulait direça: // Do not use the for(Object o : list) // because I think it is probably // slower than doing this… Probably… for(int i = 0; i < list.size(); i++) { Object o = list.get(i); … } Stop guessing dam it!!!
  • 11.
  • 12.
    12 LES DIFFÉRENTS TYPESDE TEST• Objectif: mesurer la performance unitaire • Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif: mesurer la tenue en charge de l’application sur la population cible • Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif: déterminer les limites de l’application • Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif: déterminer la capacité de l’application à fonctionner sur une période étendue • Ex: on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  • 13.
  • 14.
    14 Les performances d’un systèmesont une spécification fonctionnelle implicite du système Notre vision ? Source : www.arthursclipart.org
  • 15.
    15 Cible de performance Exemples: Tempsd’affichage du détail d’un item: < 200ms Nombre d’utilisateurs concurrents: 200
  • 16.
  • 17.
    17 LES DIFFÉRENTS TYPESDE TEST• Objectif: mesurer la performance unitaire • Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif: mesurer la tenue en charge de l’application sur la population cible • Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif: déterminer les limites de l’application • Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif: déterminer la capacité de l’application à fonctionner sur une période étendue • Ex: on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  • 18.
  • 19.
    19 LES DIFFÉRENTS TYPESDE TEST• Objectif: mesurer la performance unitaire • Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif: mesurer la tenue en charge de l’application sur la population cible • Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif: déterminer les limites de l’application • Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif: déterminer la capacité de l’application à fonctionner sur une période étendue • Ex: on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  • 20.
  • 21.
    21 LES DIFFÉRENTS TYPESDE TEST• Objectif: mesurer la performance unitaire • Ex: le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif: mesurer la tenue en charge de l’application sur la population cible • Ex: on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif: déterminer les limites de l’application • Ex: on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif: déterminer la capacité de l’application à fonctionner sur une période étendue • Ex: on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  • 22.
  • 23.
    23 LES DIFFÉRENTS TYPESDE TEST•1 utilisateur •1 scénario •Quelques itératinos Test de performance unitaire • Nombre espéré d’utilisateurs • Plusieurs scénario • 10 minutes et plus Test de charge • Nombre croissant d’utilisateurs • Plusieurs scénario • Jusqu’à rupture (dégradation) Test de rupture •Nombre espéré d’utilisateurs •Plusieurs scénario •Plusieurs heures Test de vieillissement
  • 24.
    24 Les outils utilisésaujourd’hui https://jhipster.github.io https://visualvm.java.net/ https://www.yourkit.com/ https://www.jclarity.com/censum/ http://grafana.org/ https://influxdata.com/ https://www.docker.com/ http://gatling.io
  • 25.

Notes de l'éditeur

  • #4 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • #5 Tout développeur ayant mis en production sait apprécier l’effort que cela requiert. « Cela marche sur mon poste » Pourquoi la performance est moins bonne? Les plus expérimentés savent que le problème est rarement là où on le pensait même avec un flair aiguisé
  • #6 04- Archi, tunnel, tests de perf, prod (donc on a fait ça) Henri: Traditionnellement, au début du projet on fait une belle archi Ensuite on se lance dans un tunnel de développement Quand on a fini on fait des tirs de perf et à la fin on va en prod
  • #7 05- Archi, tunnel avec un cycle agile dedans, tests de perf, prod (on a raffiné comme ça mais on a oublié les tests de perf) Henri: Ensuite, on s’est dit que ça allait pas le tunnel. Il vaut mieux faire des itérations de développement pour avoir un feedback plus rapide Donc on fait ça… et à la fin on fait des tirs de perf et on va en prod
  • #8 06- Archi, tunnel, avec un cycle agile dedans, tests de perf, délai de correction à l'arrache des perfs, prod (mais en fait c'est ça) Henri: Le problème c’est qu’en fait, ça se passe plutôt comme ça: On fait les tirs de perf Ça tient juste pas la charge On retarde la mise en production On optimise au petit bonheur la chance parce que maintenant que l’appli est fini on a pas trop le choix Et on met en prod un truc plus ou moins performant
  • #9 07- Archi, cycle avec tests de perfs en continue, prod, (Mais pourquoi on fait pas ça?) Henri: C’est dommage parce qu’on a eu la bonne idée de faire des itérations mais pas d’y mettre les tests de perfs Et pourtant, le feedback, c’est intéressant aussi pour les perfs. Donc nous on vous dit qu’il faut faire ca.
  • #10 02- L’optimisation prématurée est la source du mal (tout à commencé par ça) Henri: C’est là où tout à commencé. On l’apprend très tôt à l’école, ne pas optimisé prématurément, ça sert à rien et souvent c’est pire. Les problèmes c’est qu’en disant ça, Knuth pensait à ça
  • #11 03- Code early optimisé pour rien (en fait c'était pour ça) Henri: C’est-à-dire faire une niaiserie qui sert à rien, mélange le compilateur, complique le code et ne sert à rien du tout. Reprenons du début et voyons comment se déroule un projet
  • #12 03- Code early optimisé pour rien (en fait c'était pour ça) Henri: Là où il faut écouter Knuth, c’est qu’en pratique, on code, on mesure et on optimise là où c’est important Mais reprenons du début
  • #13 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • #14 Utiliser un client REST comme REST client Exécution test unitaire dans Chrome Thread dump Long queries : /var/log/postgresql/postgresql-9.1-main.log Explain plan : explain analyse verbose select sum(saleoperation.amount) as col_0_0_, saleoperation.currency as col_1_0_ from SaleOperation saleoperation where saleoperation.groupId=1 and saleoperation.OPERATIONDATE>='2010-04-15 00:21:31.529' group by saleoperation.currency order by SUM(saleoperation.amount) desc; Rejeu des stats Ajout d’indexes CREATE INDEX saleoperation_groupid_idx ON saleoperation (groupid); CREATE INDEX saleoperation_groupid_operationdate ON saleoperation (operationdate); explain statement vacuumdb –d happystore
  • #15 Qu’est-ce qu’on appelle une application performante ? Tout utilisateur de système informatique s’attend à recevoir un système Qui répond de façon stable quelque soit sa charge Qui répondre en un temps cohérent par rapport à l’action qu’il réalise Bref un système performant Les performances d’un système sont une spécification fonctionnelle implicite du système
  • #17 Dans chrome, on lance un appel et on regarde le temps de réponse C’est lent
  • #18 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • #19 Exécution du test de charge Problème du statfilter
  • #20 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • #21 Test de rupture mais ça serait bien d’avoir un peu de métriques en temps réel ThreadPool trop limité
  • #22 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • #23 Test d’endurance Memory leak Tuning système
  • #24 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • #25 Quels outils allons nous utiliser concrètement ? Pour la génération de données : benerator Anonymisation et script de migration depuis la production Génération de jeux de données Pour la mise en charge Gatling : outil écrit en scala - Enregistrement - Faire varier les données saisies en entrée Simuler un grand nombre d’utilisateur Pour la prise de mesure Pour avoir des mesures et les corréler à la charge Tout en open source : graphite, vmstat