SlideShare une entreprise Scribd logo
1  sur  25
© 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

Contenu connexe

Tendances

Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Emmanuel Hugonnet
 
Intégration continue
Intégration continueIntégration continue
Intégration continue
Klee Group
 
Intégration continue transco
Intégration continue transcoIntégration continue transco
Intégration continue transco
laurent_opnworks
 

Tendances (20)

Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
 
20151013 - Réduire les coûts des tests de performance ?
20151013 - Réduire les coûts des tests de performance ?20151013 - Réduire les coûts des tests de performance ?
20151013 - Réduire les coûts des tests de performance ?
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
 
Test unitaires
Test unitairesTest unitaires
Test unitaires
 
[PFE] Master en ingénierie du logiciel
[PFE] Master en ingénierie du logiciel[PFE] Master en ingénierie du logiciel
[PFE] Master en ingénierie du logiciel
 
Mesurer Les Performances Avec JMeter Cours Du Soir Valtech 25 Mars 2010
Mesurer Les Performances Avec JMeter   Cours Du Soir Valtech 25 Mars 2010Mesurer Les Performances Avec JMeter   Cours Du Soir Valtech 25 Mars 2010
Mesurer Les Performances Avec JMeter Cours Du Soir Valtech 25 Mars 2010
 
Qualité Logiciel - Outils Open Source pour Java et Web
Qualité Logiciel - Outils Open Source pour Java et WebQualité Logiciel - Outils Open Source pour Java et Web
Qualité Logiciel - Outils Open Source pour Java et Web
 
Intégration continue
Intégration continueIntégration continue
Intégration continue
 
Presentation tests d'acceptations automatisés sug v1.1
Presentation tests d'acceptations automatisés sug v1.1Presentation tests d'acceptations automatisés sug v1.1
Presentation tests d'acceptations automatisés sug v1.1
 
Les outils d’automatisation de tests (scripting) : Adoption et enjeux (comple...
Les outils d’automatisation de tests (scripting) : Adoption et enjeux (comple...Les outils d’automatisation de tests (scripting) : Adoption et enjeux (comple...
Les outils d’automatisation de tests (scripting) : Adoption et enjeux (comple...
 
Concept de l’Intégration Continue
Concept de l’Intégration ContinueConcept de l’Intégration Continue
Concept de l’Intégration Continue
 
Introduction à la validation de logiciel
Introduction à la validation de logicielIntroduction à la validation de logiciel
Introduction à la validation de logiciel
 
Intégration continue transco
Intégration continue transcoIntégration continue transco
Intégration continue transco
 
Et si mon test était la spécification de mon application ? - JACOB - iWE - So...
Et si mon test était la spécification de mon application ? - JACOB - iWE - So...Et si mon test était la spécification de mon application ? - JACOB - iWE - So...
Et si mon test était la spécification de mon application ? - JACOB - iWE - So...
 
Tester en continu avec le Cloud - GACHE HUCKERT - AXA FRANCE - Soirée du Test...
Tester en continu avec le Cloud - GACHE HUCKERT - AXA FRANCE - Soirée du Test...Tester en continu avec le Cloud - GACHE HUCKERT - AXA FRANCE - Soirée du Test...
Tester en continu avec le Cloud - GACHE HUCKERT - AXA FRANCE - Soirée du Test...
 
Industrialisation des développements logiciels
Industrialisation des développements logicielsIndustrialisation des développements logiciels
Industrialisation des développements logiciels
 
Allons plus loin avec Selenium
Allons plus loin avec SeleniumAllons plus loin avec Selenium
Allons plus loin avec Selenium
 
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
20120612 02 - Automatisation des tests avec squash TA en environnement bancai...
 
Softshake 2015 - Comment tester et optimiser la performance d'un SI ?
Softshake 2015 - Comment tester et optimiser la performance d'un SI ?Softshake 2015 - Comment tester et optimiser la performance d'un SI ?
Softshake 2015 - Comment tester et optimiser la performance d'un SI ?
 
20100608 2 - TNR automatisés (Generali)
20100608 2 - TNR automatisés (Generali)20100608 2 - TNR automatisés (Generali)
20100608 2 - TNR automatisés (Generali)
 

En vedette

Velocidad_y_Aceleracion
Velocidad_y_AceleracionVelocidad_y_Aceleracion
Velocidad_y_Aceleracion
Saul Duque
 
Bf spain residencias ancianos
Bf spain     residencias ancianosBf spain     residencias ancianos
Bf spain residencias ancianos
José Olarreaga
 
18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...
18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...
18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...
Alfredo Alday
 
El escondite perfecto
El escondite perfectoEl escondite perfecto
El escondite perfecto
Evamarribas
 

En vedette (20)

Nicolas maurice - Pefecture de police de Paris
Nicolas maurice - Pefecture de police de ParisNicolas maurice - Pefecture de police de Paris
Nicolas maurice - Pefecture de police de Paris
 
Poetizamos o colexio
Poetizamos o colexioPoetizamos o colexio
Poetizamos o colexio
 
Anexo !!!trabajando el cuero
Anexo !!!trabajando el cueroAnexo !!!trabajando el cuero
Anexo !!!trabajando el cuero
 
Velocidad_y_Aceleracion
Velocidad_y_AceleracionVelocidad_y_Aceleracion
Velocidad_y_Aceleracion
 
Espirógrafo
EspirógrafoEspirógrafo
Espirógrafo
 
cardio cours test
cardio cours testcardio cours test
cardio cours test
 
GF1 - Architecture et image urbaine - François Dugeny
GF1 - Architecture et image urbaine  - François DugenyGF1 - Architecture et image urbaine  - François Dugeny
GF1 - Architecture et image urbaine - François Dugeny
 
Powerpoint carriere
Powerpoint carrierePowerpoint carriere
Powerpoint carriere
 
Diagnostic alimentation lgb v2
Diagnostic alimentation lgb v2Diagnostic alimentation lgb v2
Diagnostic alimentation lgb v2
 
Bf spain residencias ancianos
Bf spain     residencias ancianosBf spain     residencias ancianos
Bf spain residencias ancianos
 
León
LeónLeón
León
 
Licencia Creative Commons
Licencia Creative CommonsLicencia Creative Commons
Licencia Creative Commons
 
2011 sondage aupres de collectivites locales
2011 sondage aupres de collectivites locales2011 sondage aupres de collectivites locales
2011 sondage aupres de collectivites locales
 
betiON en el AAL Summit 2012
betiON en el AAL Summit 2012betiON en el AAL Summit 2012
betiON en el AAL Summit 2012
 
Presentación Emilce Joya
Presentación Emilce JoyaPresentación Emilce Joya
Presentación Emilce Joya
 
Webqwest sur les vacances sportives
Webqwest sur les vacances sportivesWebqwest sur les vacances sportives
Webqwest sur les vacances sportives
 
Ensamble de un p cppt
Ensamble de un p cpptEnsamble de un p cppt
Ensamble de un p cppt
 
18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...
18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...
18 congreso hospitales. betiON un modelo integral de coordinación socio-sanit...
 
Numérique et projets urbains mise en perspective
Numérique et projets urbains mise en perspectiveNumérique et projets urbains mise en perspective
Numérique et projets urbains mise en perspective
 
El escondite perfecto
El escondite perfectoEl escondite perfecto
El escondite perfecto
 

Similaire à Confoo 2016: Initiation aux tests de charge

présentation sur la gestion des projets.pdf
présentation sur la gestion des projets.pdfprésentation sur la gestion des projets.pdf
présentation sur la gestion des projets.pdf
ghiz-
 

Similaire à Confoo 2016: Initiation aux tests de charge (20)

Session #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de productionSession #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de production
 
Les tests utilisateurs pour les petits budgets
Les tests utilisateurs pour les petits budgetsLes tests utilisateurs pour les petits budgets
Les tests utilisateurs pour les petits budgets
 
Load test & performance profiling
Load test & performance profilingLoad test & performance profiling
Load test & performance profiling
 
[Agile Testing Day] Introduction
[Agile Testing Day] Introduction[Agile Testing Day] Introduction
[Agile Testing Day] Introduction
 
Presentation Rex Methodes Agiles
Presentation Rex Methodes AgilesPresentation Rex Methodes Agiles
Presentation Rex Methodes Agiles
 
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet AgileLes cinq bonnes pratiques des Tests Unitaires dans un projet Agile
Les cinq bonnes pratiques des Tests Unitaires dans un projet Agile
 
20171122 03 - Les tests de performance en environnement DevOps
20171122 03 - Les tests de performance en environnement DevOps20171122 03 - Les tests de performance en environnement DevOps
20171122 03 - Les tests de performance en environnement DevOps
 
présentation sur la gestion des projets.pdf
présentation sur la gestion des projets.pdfprésentation sur la gestion des projets.pdf
présentation sur la gestion des projets.pdf
 
Remettons les tests au coeur des projets
Remettons les tests au coeur des projetsRemettons les tests au coeur des projets
Remettons les tests au coeur des projets
 
20111004 04 - Présentation ATDD
20111004 04 - Présentation ATDD20111004 04 - Présentation ATDD
20111004 04 - Présentation ATDD
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
 
Webinar Ferpection - le succès de vos sites et applications mobiles grâce aux...
Webinar Ferpection - le succès de vos sites et applications mobiles grâce aux...Webinar Ferpection - le succès de vos sites et applications mobiles grâce aux...
Webinar Ferpection - le succès de vos sites et applications mobiles grâce aux...
 
RA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptxRA et CCDS - Séance 1.pptx
RA et CCDS - Séance 1.pptx
 
Dossier de plan_de_tests_v1.00
Dossier de plan_de_tests_v1.00Dossier de plan_de_tests_v1.00
Dossier de plan_de_tests_v1.00
 
Flex Unit Testing
Flex Unit TestingFlex Unit Testing
Flex Unit Testing
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Augmenter sa rentabilité grâce au test utilisateur
Augmenter sa rentabilité grâce au test utilisateurAugmenter sa rentabilité grâce au test utilisateur
Augmenter sa rentabilité grâce au test utilisateur
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Equipes Agiles & DevOps : Testez la valeur d’abord !
Equipes Agiles & DevOps : Testez la valeur d’abord ! Equipes Agiles & DevOps : Testez la valeur d’abord !
Equipes Agiles & DevOps : Testez la valeur d’abord !
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 

Plus de Henri Tremblay

Plus de Henri Tremblay (16)

DevNexus 2020: Discover Modern Java
DevNexus 2020: Discover Modern JavaDevNexus 2020: Discover Modern Java
DevNexus 2020: Discover Modern Java
 
OracleCode One 2018: Java 5, 6, 7, 8, 9, 10, 11: What Did You Miss?
OracleCode One 2018: Java 5, 6, 7, 8, 9, 10, 11: What Did You Miss?OracleCode One 2018: Java 5, 6, 7, 8, 9, 10, 11: What Did You Miss?
OracleCode One 2018: Java 5, 6, 7, 8, 9, 10, 11: What Did You Miss?
 
Confoo 2018: Être pragmatique
Confoo 2018: Être pragmatiqueConfoo 2018: Être pragmatique
Confoo 2018: Être pragmatique
 
DevNexus 2018: Learn Java 8, lambdas and functional programming
DevNexus 2018: Learn Java 8, lambdas and functional programmingDevNexus 2018: Learn Java 8, lambdas and functional programming
DevNexus 2018: Learn Java 8, lambdas and functional programming
 
Do you know your mock? - Madras JUG 20171028
Do you know your mock? - Madras JUG 20171028Do you know your mock? - Madras JUG 20171028
Do you know your mock? - Madras JUG 20171028
 
Be Pragmatic - JavaOne 2017
Be Pragmatic - JavaOne 2017Be Pragmatic - JavaOne 2017
Be Pragmatic - JavaOne 2017
 
Generics and Lambda survival guide - DevNexus 2017
Generics and Lambda survival guide - DevNexus 2017Generics and Lambda survival guide - DevNexus 2017
Generics and Lambda survival guide - DevNexus 2017
 
JavaOne 2016 - Learn Lambda and functional programming
JavaOne 2016 - Learn Lambda and functional programmingJavaOne 2016 - Learn Lambda and functional programming
JavaOne 2016 - Learn Lambda and functional programming
 
Java 8, lambdas, generics: How to survive? - NYC Java Meetup Group
Java 8, lambdas, generics: How to survive? - NYC Java Meetup GroupJava 8, lambdas, generics: How to survive? - NYC Java Meetup Group
Java 8, lambdas, generics: How to survive? - NYC Java Meetup Group
 
Generics and Lambdas cocktail explained - Montreal JUG
Generics and Lambdas cocktail explained  - Montreal JUGGenerics and Lambdas cocktail explained  - Montreal JUG
Generics and Lambdas cocktail explained - Montreal JUG
 
Réactif, parallèle, asynchrone. Pourquoi!
Réactif, parallèle, asynchrone. Pourquoi!Réactif, parallèle, asynchrone. Pourquoi!
Réactif, parallèle, asynchrone. Pourquoi!
 
Microbenchmarking with JMH
Microbenchmarking with JMHMicrobenchmarking with JMH
Microbenchmarking with JMH
 
Lambdas and Generics (long version) - Bordeaux/Toulouse JUG
Lambdas and Generics (long version) - Bordeaux/Toulouse JUGLambdas and Generics (long version) - Bordeaux/Toulouse JUG
Lambdas and Generics (long version) - Bordeaux/Toulouse JUG
 
Vivre en parallèle - Softshake 2013
Vivre en parallèle - Softshake 2013Vivre en parallèle - Softshake 2013
Vivre en parallèle - Softshake 2013
 
Performance perpétuelle (Devopsdays Paris 2013)
Performance perpétuelle (Devopsdays Paris 2013)Performance perpétuelle (Devopsdays Paris 2013)
Performance perpétuelle (Devopsdays Paris 2013)
 
DevoxxFR 2013: Lambda are coming. Meanwhile, are you sure we've mastered the ...
DevoxxFR 2013: Lambda are coming. Meanwhile, are you sure we've mastered the ...DevoxxFR 2013: Lambda are coming. Meanwhile, are you sure we've mastered the ...
DevoxxFR 2013: Lambda are coming. Meanwhile, are you sure we've mastered the ...
 

Confoo 2016: Initiation aux tests de charge

  • 1. © Henri Tremblay 2015 Henri Tremblay Université de la performance: Initiation aux tests de charge
  • 2. 2 Amateur de Stratégie TI Performance Productivité Fait de l’Open Source Aime être utile Henri Tremblay Henri Tremblay
  • 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
  • 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 is the 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!!!
  • 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
  • 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 Cible de performance Exemples: Temps d’affichage du détail d’un item: < 200ms Nombre d’utilisateurs concurrents: 200
  • 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
  • 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
  • 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
  • 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 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

Notes de l'éditeur

  1. Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  2. 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é
  3. 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
  4. 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
  5. 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
  6. 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.
  7. 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
  8. 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
  9. 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
  10. Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  11. 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
  12. 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
  13. Dans chrome, on lance un appel et on regarde le temps de réponse C’est lent
  14. Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  15. Exécution du test de charge Problème du statfilter
  16. Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  17. Test de rupture mais ça serait bien d’avoir un peu de métriques en temps réel ThreadPool trop limité
  18. Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  19. Test d’endurance Memory leak Tuning système
  20. Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
  21. 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