© 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...
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-
mat...
7
Archi
Dev
Perf
PROD
DélaiMEP À L’ARRACHE
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
4...
8
1. Conception
des tests
2. Automatisation
des tests
3. Développement
logiciel
4. Exécution auto-
matique des tests
#1 #2...
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…...
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é pou...
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.art...
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é pou...
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é pou...
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é pou...
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...
24
Les outils utilisés aujourd’hui
https://jhipster.github.io
https://visualvm.java.net/
https://www.yourkit.com/
https://...
25
@henri_tremblay
henri@tremblay.pro
http://www.montreal-jug.org/
Exemple de benchmark:
http://blog.octo.com/lart-du-benc...
Prochain SlideShare
Chargement dans…5
×

Confoo 2016: Initiation aux tests de charge

255 vues

Publié le

Quelques bonnes pratiques et outils à utiliser lors de vos tests de charge

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
255
Sur SlideShare
0
Issues des intégrations
0
Intégrations
20
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • 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é
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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
  • Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • 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
  • 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
  • Dans chrome, on lance un appel et on regarde le temps de réponse

    C’est lent

  • Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • Exécution du test de charge

    Problème du statfilter
  • Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • Test de rupture mais ça serait bien d’avoir un peu de métriques en temps réel

    ThreadPool trop limité
  • Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • Test d’endurance
    Memory leak
    Tuning système
  • Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  • 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




  • Confoo 2016: Initiation aux tests de charge

    1. 1. © Henri Tremblay 2015 Henri Tremblay Université de la performance: Initiation aux tests de charge
    2. 2. 2 Amateur de Stratégie TI Performance Productivité Fait de l’Open Source Aime être utile Henri Tremblay Henri Tremblay
    3. 3. 3 Agenda Test de performance unitaire Test de charge Test de rupture Test de vieillissement
    4. 4. 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. 5. 5 PROD Archi Dev Perf
    6. 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. 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. 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. 9 Premature optimization is the root of all evil - Donald Knuth
    10. 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. 11. 11 Code Mesure OptimiseLà où c’est important
    12. 12. 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. 13. 13 Exécution test unitaire
    14. 14. 14 Les performances d’un système sont une spécification fonctionnelle implicite du système Notre vision ? Source : www.arthursclipart.org
    15. 15. 15 Cible de performance Exemples: Temps d’affichage du détail d’un item: < 200ms Nombre d’utilisateurs concurrents: 200
    16. 16. 16 DÉMO Exécution test unitaire
    17. 17. 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. 18. 18 DÉMO Exécution test de charge
    19. 19. 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. 20. 20 DÉMO Test de rupture
    21. 21. 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. 22. 22 DÉMO Test d’endurance
    23. 23. 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. 24. 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. 25. 25 @henri_tremblay henri@tremblay.pro http://www.montreal-jug.org/ Exemple de benchmark: http://blog.octo.com/lart-du-benchmark/ http://brownbaglunch.fr

    ×