SlideShare une entreprise Scribd logo
1 
1 
Université de la 
Performance
2 
2 
Présentation de 
l’équipe 
Tél : +41 21 312 94 15 
www.octo.com 
© OCTO 2014 
Avenue du théâtre 7 
CH-1005 Lausanne - SUISSE
3 
3 
Jean-Philippe Briend 
! Software Architect 
! Référent technique Pôle 
Performance 
! PerfUG Paris co-leader 
! Opensource commiter
4 
4 
Philippe Kernévez 
! Directeur Technique 
! Référent technique pôle 
performance 
! OSSGTP Member 
! JUGLausanne co-leader 
! Commiter MOJO
5 
5 
Agenda 
Tél : +41 21 312 94 15 
www.octo.com 
© OCTO 2014 
Test de 
performance 
unitaire 
Avenue du théâtre 7 
CH-1005 Lausanne - SUISSE 
Test de charge 
Test de 
Test de rupture vieillissement
6 
6 
Applicatif Système
7 
7 
Développement Production
8 
8 
Méthodologie
9 
9 
DÉMO
101 
0 
DÉMO
111 
1 
Les performances d’un 
système sont une 
spécification 
fonctionnelle implicite 
du système 
Notre vision ? 
Source : www.arthursclipart.org
121 
2 
La mesure de performance 
doit être au coeur du 
processus de 
développement 
informatique 
Notre vision ? 
Source : Les géants du Web
LES 4 DIFFÉRENTS TYPES DE TEST 
131 
3 
• 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
141 
4 
La démarche de test que nous utilisons 
Global vers Local puis Local vers Global 
TESTS DE CHARGE 
TESTS DE PERFORMANCE 
UNITAIRE 
Mesurer Optimiser
151 
5 
La démarche de test que nous utilisons 
TESTS DE CHARGE 
TESTS DE PERFORMANCE 
UNITAIRE 
Mesurer Optimiser 
Scénarios 
+ 
Monitoring 
Exécution 
des 
scénarios 
Optimisations 
Estimation gains 
potentiels 
• Environnements de 
production 
• Scénarios 
représentatifs 
• Jeux de données 
• Cible à atteindre 
• Simulation 
• (Correction) 
• Mesure 
• Investigations 
• Sur un poste de 
développement 
• Validation des 
hypothèses 
• Tuning des « hot 
spots »
161 
6 
Définition du plan et des 
cas de test 
Méthodologie d’un test de charge 
Plan de test Cas de test 
Création des scénarii et 
des scripts de tests 
Enregistrement des 
métriques 
Consolidation des 
métriques et édition 
d’un rapport de test 
Métriques 
Rapport de test 
Analyse du rapport de 
test et émission des 
préconisations Rapport d’analyse 
Contrôleur 
Scripts 
de test 
Scénarii 
de test 
Application 
à tester 
Injecteurs 
Données 
de test 
Création des jeux de 
données 
1 
2 
3 
3 
Monitoring 
3 Exécution 
4 
5 
2
171 
7 
Les outils utilisés aujourd’hui 
GÉNÉRER LES DONNÉES 
! Migrer les données depuis la production mais 
il faut souvent l’anonymiser. 
! Générer un jeux de données mais il doit être 
représentatif 
! Rétablir le jeux de données dans son état 
initial une fois le tir effectué 
TESTER EN CHARGE 
! Enregistrer et rejouer de manière fidèle un 
ensemble d’actions utilisateurs. 
! Variabiliser ces actions utilisateurs pour être 
représentatif de l’usage réel 
! Simuler un grand nombre d’utilisateurs 
MONITORER LA CONSOMMATION DE 
RESSOURCES 
! Identifier les ressources en quantité limitante 
! Identifier les impacts sur les différentes 
machines lorsque l’application est distribuée 
! Corréler l’évolution des temps de réponse et 
les consommations de ressources sur les 
différentes machines
181 
8 
Les outils en général 
HPJMeter 
Analyse de log GC 
Injection 
Profiling 
APM
191 
9 
Notre fil rouge : Happy Store 
Navigateur Tomcat PgSQL 
Une application comme on en 
rencontre souvent, pas très loin de 
l’état de l’art.. Sauf pour les 
performances !
202 
0 
Architecture 
APPLICATION SERVER 
DATABASE SERVER 
Tomcat 
JVM 
PostgreSQL
212 
1 
Modèle de base de données 
Store 
0,n 
1 
Stock 
Category Family Product Sales Operation 
VAT Country Sales Transaction 
1 0,n 
0,n 
0,n 
0,n 1 
0,n 1 
0,n 1 
1 
1,n 
1 
0,n
222 
2 
Acheter des produits
232 
3 
Finaliser sa commande 
Total
242 
4 
Calcul de l’inventaire sur un magasin 
Inventory
252 
5 
Calcul du chiffre d’affaire par groupe de produits 
Turnover 
(group by+order by)
262 
6 
Cible de performance 
! Cible : 100 utilisateurs concurrents 
! Volumétrie de la base de données : 13 millions de lignes 
Store 
0,n 
1 
Stock 
10'000'000 
1'000 1'000 
Category Family Product Sales Operation 
VAT Country Sales Transaction 
1 0,n 
0,n 
0,n 
0,n 1 
0,n 1 
0,n 1 
1 
1,n 
1 
0,n 
260 
1'000 
10'000 
3'000'000 
0
LES DIFFÉRENTS TYPES DE TEST 
272 
7 
• 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
282 
8 
DÉMO 
28 
Exécution test unitaire
292 
9 
Que fais le serveur applicatif pendant ce temps ? 
! Identifier la JVM 
! Faire un threadump pendant la requête
303 
0 
! C’est le seul à exécuter du code applicatif 
Identifier notre Thread 
! Il attend la base… mais quelle est la requête ?
313 
1 
! Vérification de la configuration des traces 
! Les requêtes de plus de 700ms sont tracées 
! On obtient la requête et ses paramètres d’appel 
Allons voir la DB
323 
2 
Pourquoi cette requête est lente ? 
select sum(amount), …. 
from SaleOperation 
where groupId=1 and operationdate >= '2010-04-15 00:21:31.529' 
group by saleoperation.currency 
order by sum(saleoperation.amount) desc; 
! Demandons au moteur du SGBD… 
! Un index pourrait aider à mieux filtrer les lignes…
333 
3 
DÉMO 
33 
Exécution test unitaire
343 
4 
Remplissage des données : Benerator 
! Principes : la base de données est alimentées avec 2 sources 
! Une (petite) partie des données est maitrisée 
! Généralement le jeux de données utilisés pour les tests d’intégration 
! Cohérent avec les scripts d’injection (permet de faire des assertions) 
! Une (grosse) partie des données est générée aléatoirement 
xxx 
xxx 
Store 
0,n 
1 
Stock 
10'000'000 
4 
16 
4 4 
1'000 1'000 
Category Family Product Sales Operation 
VAT Country Sales Transaction 
1 0,n 
0,n 
0,n 
0,n 1 
0,n 1 
0,n 1 
1 
1,n 
1 
0,n 
260 
1'000 
10'000 
3'000'000 
0 
260 256 
1 
2
353 
5 
Configuration Benerator
363 
6 
! Temps de création de happystore è 1h20 
! 8 tables / 13 M de lignes 
! (un thread sur MB avec VM) 
! Temps de rechargement è 25 min 
Temps de génération
LES DIFFÉRENTS TYPES DE TEST 
383 
8 
• 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
393 
9 
Architecture 
LOCAL SERVER APPLICATION SERVER 
DATABASE SERVER 
Gatling 
Tomcat 
JVM 
PostgreSQL
404 
0 
Gatling - Recorder
414 
1 
Gatling – DSL Scala 
URL + header http 
page1 
page2 
Nb utilisateurs + durée
424 
2 
Montée en charge 
nombre d'utilisateurs 
durée 
20 min 2h 
delay ramp up duration
434 
3 
Exécution Gatling
444 
4 
Résultats Gatling
454 
5
474 
7 
Premature optimization is the 
root of all evil - Donald Knuth
484 
8 
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 damn it!!!
494 
9 
Code 
Mesure 
Optimise Là où 
c’est 
important
505 
0 
DÉMO 
50 
Visual VM
515 
1 
Architecture 
TOOL SERVER APPLICATION SERVER 
Collectd 
DATABASE SERVER 
CI STACK 
Jenkins 
GRAPHITE STACK 
Gatling 
Maven 
Graphite 
Git 
Whisper 
Carbon Collectd 
PostgreSQL 
JVM 
Tomcat
525 
2 
DÉMO 
52 
Graphite & Metrics
535 
3 
Un exemple d’outil d’APM du marché : AppDynamics
545 
4
555 
5 
Développement 
Production 
Architecture 
Perf.
565 
6 
3. Développement 
2. Automatisation 
Architecture Développement 
Perf. 
1. Conception 
des tests 
des tests 
logiciel 
4. Exécution auto-matique 
des tests 
#1 #2 #3
575 
7 
3. Développement 
2. Automatisation 
des tests 
#1 #2 #3 
Délai 
Perf. 
PERFORMANCES 
CATASTROPHIQUES 
MEP À L’ARRACHE 
logiciel 
4. Exécution auto-matique 
des tests 
1. Conception 
des tests 
Développement 
Architecture 
Résultats 
Production
585 
8 
3. Développement 
2. Automatisation 
1. Conception 
des tests 
des tests 
logiciel 
4. Exécution auto-matique 
des tests 
#1 #2 #3 
Architecture 
Développement Production 
Tests de charge en continue
595 
9 
Intégrer les tests de performances au cycle de 
développement? 
Hyperviseur 
AppServer 
Chef 
DbServer 
Chef 
1 
2 
3 
Créer environnement 
Tir de performance 
Destruction environnement
626 
2 
DÉMO 
62 
Automatisation des tests
LES DIFFÉRENTS TYPES DE TEST 
636 
3 
• 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
646 
4 
Test de rupture 
100 
requêtes par secondes 
nombre d'utilisateurs
656 
5 
Montée en charge 
nombre d'utilisateurs 
durée 
2h 0 min 
delay ramp up duration
666 
6 
Montée en charge et retour à la normal 
nombre d'utilisateurs 
durée 
delay ramp up duration
676 
7 
Mesure Gatling
686 
8 
Mesures Graphite
696 
9 
Mesure GC
LES DIFFÉRENTS TYPES DE TEST 
707 
0 
• 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
717 
1 
! Déterminer la capacité de l’application à fonctionner sur une 
période étendue 
! Durant ce tests on va surveiller les dérives au cours du temps : 
! Temps de réponse 
! Consommation de ressource (espace disk, CPU, mémoire, etc.) 
! Libération des ressources (connexions, file, etc.) 
! Mémoire 
Objectif
727 
2 
Montée en charge 
nombre d'utilisateurs 
durée 
20 min 24h 
delay ramp up duration
737 
3 
DÉMO 
73 
Test d’endurance
747 
4 
Memory Leak [1/3] 
! Analyse des logs GC avec HPJMeter (ou Censum) 
! -Xloggc:gc.log -XX:+PrintTenuringDistribution -XX:+PrintGCDetails
757 
5 
! Heapdump puis Eclipse Memory Analyzer (statique) 
! Rapport sur les suspects 
Memory Leak [2/3]
767 
6 
! Visual VM (dynamique) 
Memory Leak [3/3] 
! On cherche les objets vivants avec un grand nombre de génération 
! Jdk 8+ pour les JVM remote
777 
7 
Résumé de la session 
Préparer les jeux de données Benerator 
Exécuter une mesure unitaire Chrome developer tools 
Identifier un problème d’index jstack, explain plan 
Exécuter des tests de charge Gatling 
Automatisation des tests de 
charge 
Jenkins, Capistrano, Chef 
Problème de contention VisualVM, jstack 
Mise en place du monitoring Metrics, collectd et Graphite 
Identifier une fuite mémoire VisualVM, EMA, HPJMeter 
Tuning système Bonnie++
787 
8 
! Tunning Système 
! Exemple Bonnie++ 
Pour aller plus loin
808 
0 
! La conférence originale à Devoxx FR 2014 : 
https://parleys.com/play/536749d1e4b04bb59f502709 
! Exemple de benchmark: 
http://blog.octo.com/lart-du-benchmark/ 
! Conférence sur l’industrialisation (USI 2013): 
https://www.youtube.com/watch?v=BXO3LYQ9Vic 
! Tests de performance SQLFire: 
http://blog.octo.com/en/sqlfire-from-the-trenches/ 
Liens utiles
818 
1 
! Remerciement à Henri Tremblay, Marc Bojoly, Mickaël Robert & Ludovic Piot
828 
2 
+Jean Philippe Briend 
@jpbriend 
jpbriend@octo.com 
+Philippe Kernevez 
@pkernevez 
pkernevez@octo.com

Contenu connexe

En vedette

Quicky
QuickyQuicky
Quicky
pkernevez
 
Flex Unit Testing
Flex Unit TestingFlex Unit Testing
Flex Unit Testing
Christophe Keromen
 
Test unitaire
Test unitaireTest unitaire
Test unitaire
IsenDev
 
Cloud : en 2017, sortez du stratus !
Cloud : en 2017, sortez du stratus !Cloud : en 2017, sortez du stratus !
Cloud : en 2017, sortez du stratus !
OCTO Technology Suisse
 
Workshop : Innovation Games at NSSpain
Workshop : Innovation Games at NSSpainWorkshop : Innovation Games at NSSpain
Workshop : Innovation Games at NSSpain
Ben Sykes
 
Champfrogs
ChampfrogsChampfrogs
Champfrogs
Jurgen Appelo
 
Management 3.0 - Empower Teams
Management 3.0 - Empower TeamsManagement 3.0 - Empower Teams
Management 3.0 - Empower Teams
Jurgen Appelo
 
Intro sur les tests unitaires
Intro sur les tests unitairesIntro sur les tests unitaires
Intro sur les tests unitairesPHPPRO
 
2 4 a trip to madrid
2 4 a trip to madrid2 4 a trip to madrid
2 4 a trip to madrid
js428843mhs
 
Volei
VoleiVolei
Volei
verduribes
 
Proporcionalidad
Proporcionalidad Proporcionalidad
Proporcionalidad
ALUMNOSDIVER
 
Las drogas y sus efectos
Las drogas y sus efectosLas drogas y sus efectos
Las drogas y sus efectos
aitor_usera
 
Propuestas del PP de La Coruña aparcamientos accesibles
Propuestas del PP de La Coruña aparcamientos accesiblesPropuestas del PP de La Coruña aparcamientos accesibles
Propuestas del PP de La Coruña aparcamientos accesibles
Carlos Negreira
 
Ejercicios diego
Ejercicios diegoEjercicios diego
Ejercicios diego
Eduardo Ramirez Rodriguez
 
Herramientas mantenimiento
Herramientas mantenimientoHerramientas mantenimiento
Herramientas mantenimiento
J Ospina
 
Srikini tortitas de formatge
Srikini tortitas de formatgeSrikini tortitas de formatge
Srikini tortitas de formatgexaviete
 
Publicidad
PublicidadPublicidad
m2
 m2 m2

En vedette (20)

Quicky
QuickyQuicky
Quicky
 
Test unitaire
Test unitaireTest unitaire
Test unitaire
 
Flex Unit Testing
Flex Unit TestingFlex Unit Testing
Flex Unit Testing
 
Test unitaire
Test unitaireTest unitaire
Test unitaire
 
Cloud : en 2017, sortez du stratus !
Cloud : en 2017, sortez du stratus !Cloud : en 2017, sortez du stratus !
Cloud : en 2017, sortez du stratus !
 
Workshop : Innovation Games at NSSpain
Workshop : Innovation Games at NSSpainWorkshop : Innovation Games at NSSpain
Workshop : Innovation Games at NSSpain
 
Champfrogs
ChampfrogsChampfrogs
Champfrogs
 
Management 3.0 - Empower Teams
Management 3.0 - Empower TeamsManagement 3.0 - Empower Teams
Management 3.0 - Empower Teams
 
Intro sur les tests unitaires
Intro sur les tests unitairesIntro sur les tests unitaires
Intro sur les tests unitaires
 
2 4 a trip to madrid
2 4 a trip to madrid2 4 a trip to madrid
2 4 a trip to madrid
 
Volei
VoleiVolei
Volei
 
Proporcionalidad
Proporcionalidad Proporcionalidad
Proporcionalidad
 
Las drogas y sus efectos
Las drogas y sus efectosLas drogas y sus efectos
Las drogas y sus efectos
 
Propuestas del PP de La Coruña aparcamientos accesibles
Propuestas del PP de La Coruña aparcamientos accesiblesPropuestas del PP de La Coruña aparcamientos accesibles
Propuestas del PP de La Coruña aparcamientos accesibles
 
Ejercicios diego
Ejercicios diegoEjercicios diego
Ejercicios diego
 
Herramientas mantenimiento
Herramientas mantenimientoHerramientas mantenimiento
Herramientas mantenimiento
 
Srikini tortitas de formatge
Srikini tortitas de formatgeSrikini tortitas de formatge
Srikini tortitas de formatge
 
Publicidad
PublicidadPublicidad
Publicidad
 
1 jaienvie.de
1 jaienvie.de1 jaienvie.de
1 jaienvie.de
 
m2
 m2 m2
m2
 

Similaire à Université de la performance

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
DEFO KUATE Landry
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
Christophe Rochefolle
 
Morning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesMorning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slides
Oxalide
 
Oxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceOxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performance
Ludovic Piot
 
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
Benoît de CHATEAUVIEUX
 
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Normandy JUG
 
Load test & performance profiling
Load test & performance profilingLoad test & performance profiling
Load test & performance profiling
MSDEVMTL
 
Documentation - Database Tuning (Oracle)
Documentation - Database Tuning (Oracle)Documentation - Database Tuning (Oracle)
Documentation - Database Tuning (Oracle)
BD3C
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
Ippon
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Agile Montréal
 
Cerberus Testing
Cerberus TestingCerberus Testing
Cerberus Testing
CIVEL Benoit
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
Radoine Douhou
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
neuros
 
Integration continue - Introduction
Integration continue - IntroductionIntegration continue - Introduction
Integration continue - Introduction
Olivier ETIENNE
 
L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
Michel Bruchet
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
Laurent PY
 
Comment construire son laboratoire de tests mobiles avec HP Mobile Center
Comment construire son laboratoire de tests mobiles avec HP Mobile CenterComment construire son laboratoire de tests mobiles avec HP Mobile Center
Comment construire son laboratoire de tests mobiles avec HP Mobile Center
Guillaume Deshayes
 
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
Publicis Sapient Engineering
 
Quelles stratégies de Recherche avec Cassandra ?
Quelles stratégies de Recherche avec Cassandra ?Quelles stratégies de Recherche avec Cassandra ?
Quelles stratégies de Recherche avec Cassandra ?
Victor Coustenoble
 
JFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à ZJFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à Z
Cedric GAUTIER
 

Similaire à Université de la performance (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
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Morning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slidesMorning tech #2 - Démarche performance slides
Morning tech #2 - Démarche performance slides
 
Oxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performanceOxalide Morning tech #2 - démarche performance
Oxalide Morning tech #2 - démarche performance
 
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
"La Performance en Continue" à JMaghreb 3.0 - 05/11/2014
 
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
 
Load test & performance profiling
Load test & performance profilingLoad test & performance profiling
Load test & performance profiling
 
Documentation - Database Tuning (Oracle)
Documentation - Database Tuning (Oracle)Documentation - Database Tuning (Oracle)
Documentation - Database Tuning (Oracle)
 
Présentation Rex GWT 2.0
Présentation Rex GWT 2.0Présentation Rex GWT 2.0
Présentation Rex GWT 2.0
 
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie TrudelHa zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
Ha zut, le DevOps a mangé ma vélocité par Jean-Marc Lavoie & Sylvie Trudel
 
Cerberus Testing
Cerberus TestingCerberus Testing
Cerberus Testing
 
Dev opsday case study
Dev opsday   case studyDev opsday   case study
Dev opsday case study
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
 
Integration continue - Introduction
Integration continue - IntroductionIntegration continue - Introduction
Integration continue - Introduction
 
L’informatique efficience
L’informatique efficienceL’informatique efficience
L’informatique efficience
 
Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)Développement d'un grand projet piloté par les tests (BDD)
Développement d'un grand projet piloté par les tests (BDD)
 
Comment construire son laboratoire de tests mobiles avec HP Mobile Center
Comment construire son laboratoire de tests mobiles avec HP Mobile CenterComment construire son laboratoire de tests mobiles avec HP Mobile Center
Comment construire son laboratoire de tests mobiles avec HP Mobile Center
 
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
XebiCon'17 : Migration d’une application web vers un Paas Openshift - Akram B...
 
Quelles stratégies de Recherche avec Cassandra ?
Quelles stratégies de Recherche avec Cassandra ?Quelles stratégies de Recherche avec Cassandra ?
Quelles stratégies de Recherche avec Cassandra ?
 
JFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à ZJFTL2015 - Tester une application mobile de A à Z
JFTL2015 - Tester une application mobile de A à Z
 

Université de la performance

  • 1. 1 1 Université de la Performance
  • 2. 2 2 Présentation de l’équipe Tél : +41 21 312 94 15 www.octo.com © OCTO 2014 Avenue du théâtre 7 CH-1005 Lausanne - SUISSE
  • 3. 3 3 Jean-Philippe Briend ! Software Architect ! Référent technique Pôle Performance ! PerfUG Paris co-leader ! Opensource commiter
  • 4. 4 4 Philippe Kernévez ! Directeur Technique ! Référent technique pôle performance ! OSSGTP Member ! JUGLausanne co-leader ! Commiter MOJO
  • 5. 5 5 Agenda Tél : +41 21 312 94 15 www.octo.com © OCTO 2014 Test de performance unitaire Avenue du théâtre 7 CH-1005 Lausanne - SUISSE Test de charge Test de Test de rupture vieillissement
  • 6. 6 6 Applicatif Système
  • 7. 7 7 Développement Production
  • 11. 111 1 Les performances d’un système sont une spécification fonctionnelle implicite du système Notre vision ? Source : www.arthursclipart.org
  • 12. 121 2 La mesure de performance doit être au coeur du processus de développement informatique Notre vision ? Source : Les géants du Web
  • 13. LES 4 DIFFÉRENTS TYPES DE TEST 131 3 • 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. 141 4 La démarche de test que nous utilisons Global vers Local puis Local vers Global TESTS DE CHARGE TESTS DE PERFORMANCE UNITAIRE Mesurer Optimiser
  • 15. 151 5 La démarche de test que nous utilisons TESTS DE CHARGE TESTS DE PERFORMANCE UNITAIRE Mesurer Optimiser Scénarios + Monitoring Exécution des scénarios Optimisations Estimation gains potentiels • Environnements de production • Scénarios représentatifs • Jeux de données • Cible à atteindre • Simulation • (Correction) • Mesure • Investigations • Sur un poste de développement • Validation des hypothèses • Tuning des « hot spots »
  • 16. 161 6 Définition du plan et des cas de test Méthodologie d’un test de charge Plan de test Cas de test Création des scénarii et des scripts de tests Enregistrement des métriques Consolidation des métriques et édition d’un rapport de test Métriques Rapport de test Analyse du rapport de test et émission des préconisations Rapport d’analyse Contrôleur Scripts de test Scénarii de test Application à tester Injecteurs Données de test Création des jeux de données 1 2 3 3 Monitoring 3 Exécution 4 5 2
  • 17. 171 7 Les outils utilisés aujourd’hui GÉNÉRER LES DONNÉES ! Migrer les données depuis la production mais il faut souvent l’anonymiser. ! Générer un jeux de données mais il doit être représentatif ! Rétablir le jeux de données dans son état initial une fois le tir effectué TESTER EN CHARGE ! Enregistrer et rejouer de manière fidèle un ensemble d’actions utilisateurs. ! Variabiliser ces actions utilisateurs pour être représentatif de l’usage réel ! Simuler un grand nombre d’utilisateurs MONITORER LA CONSOMMATION DE RESSOURCES ! Identifier les ressources en quantité limitante ! Identifier les impacts sur les différentes machines lorsque l’application est distribuée ! Corréler l’évolution des temps de réponse et les consommations de ressources sur les différentes machines
  • 18. 181 8 Les outils en général HPJMeter Analyse de log GC Injection Profiling APM
  • 19. 191 9 Notre fil rouge : Happy Store Navigateur Tomcat PgSQL Une application comme on en rencontre souvent, pas très loin de l’état de l’art.. Sauf pour les performances !
  • 20. 202 0 Architecture APPLICATION SERVER DATABASE SERVER Tomcat JVM PostgreSQL
  • 21. 212 1 Modèle de base de données Store 0,n 1 Stock Category Family Product Sales Operation VAT Country Sales Transaction 1 0,n 0,n 0,n 0,n 1 0,n 1 0,n 1 1 1,n 1 0,n
  • 22. 222 2 Acheter des produits
  • 23. 232 3 Finaliser sa commande Total
  • 24. 242 4 Calcul de l’inventaire sur un magasin Inventory
  • 25. 252 5 Calcul du chiffre d’affaire par groupe de produits Turnover (group by+order by)
  • 26. 262 6 Cible de performance ! Cible : 100 utilisateurs concurrents ! Volumétrie de la base de données : 13 millions de lignes Store 0,n 1 Stock 10'000'000 1'000 1'000 Category Family Product Sales Operation VAT Country Sales Transaction 1 0,n 0,n 0,n 0,n 1 0,n 1 0,n 1 1 1,n 1 0,n 260 1'000 10'000 3'000'000 0
  • 27. LES DIFFÉRENTS TYPES DE TEST 272 7 • 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
  • 28. 282 8 DÉMO 28 Exécution test unitaire
  • 29. 292 9 Que fais le serveur applicatif pendant ce temps ? ! Identifier la JVM ! Faire un threadump pendant la requête
  • 30. 303 0 ! C’est le seul à exécuter du code applicatif Identifier notre Thread ! Il attend la base… mais quelle est la requête ?
  • 31. 313 1 ! Vérification de la configuration des traces ! Les requêtes de plus de 700ms sont tracées ! On obtient la requête et ses paramètres d’appel Allons voir la DB
  • 32. 323 2 Pourquoi cette requête est lente ? select sum(amount), …. from SaleOperation where groupId=1 and operationdate >= '2010-04-15 00:21:31.529' group by saleoperation.currency order by sum(saleoperation.amount) desc; ! Demandons au moteur du SGBD… ! Un index pourrait aider à mieux filtrer les lignes…
  • 33. 333 3 DÉMO 33 Exécution test unitaire
  • 34. 343 4 Remplissage des données : Benerator ! Principes : la base de données est alimentées avec 2 sources ! Une (petite) partie des données est maitrisée ! Généralement le jeux de données utilisés pour les tests d’intégration ! Cohérent avec les scripts d’injection (permet de faire des assertions) ! Une (grosse) partie des données est générée aléatoirement xxx xxx Store 0,n 1 Stock 10'000'000 4 16 4 4 1'000 1'000 Category Family Product Sales Operation VAT Country Sales Transaction 1 0,n 0,n 0,n 0,n 1 0,n 1 0,n 1 1 1,n 1 0,n 260 1'000 10'000 3'000'000 0 260 256 1 2
  • 35. 353 5 Configuration Benerator
  • 36. 363 6 ! Temps de création de happystore è 1h20 ! 8 tables / 13 M de lignes ! (un thread sur MB avec VM) ! Temps de rechargement è 25 min Temps de génération
  • 37. LES DIFFÉRENTS TYPES DE TEST 383 8 • 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
  • 38. 393 9 Architecture LOCAL SERVER APPLICATION SERVER DATABASE SERVER Gatling Tomcat JVM PostgreSQL
  • 39. 404 0 Gatling - Recorder
  • 40. 414 1 Gatling – DSL Scala URL + header http page1 page2 Nb utilisateurs + durée
  • 41. 424 2 Montée en charge nombre d'utilisateurs durée 20 min 2h delay ramp up duration
  • 42. 434 3 Exécution Gatling
  • 43. 444 4 Résultats Gatling
  • 44. 454 5
  • 45. 474 7 Premature optimization is the root of all evil - Donald Knuth
  • 46. 484 8 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 damn it!!!
  • 47. 494 9 Code Mesure Optimise Là où c’est important
  • 48. 505 0 DÉMO 50 Visual VM
  • 49. 515 1 Architecture TOOL SERVER APPLICATION SERVER Collectd DATABASE SERVER CI STACK Jenkins GRAPHITE STACK Gatling Maven Graphite Git Whisper Carbon Collectd PostgreSQL JVM Tomcat
  • 50. 525 2 DÉMO 52 Graphite & Metrics
  • 51. 535 3 Un exemple d’outil d’APM du marché : AppDynamics
  • 52. 545 4
  • 53. 555 5 Développement Production Architecture Perf.
  • 54. 565 6 3. Développement 2. Automatisation Architecture Développement Perf. 1. Conception des tests des tests logiciel 4. Exécution auto-matique des tests #1 #2 #3
  • 55. 575 7 3. Développement 2. Automatisation des tests #1 #2 #3 Délai Perf. PERFORMANCES CATASTROPHIQUES MEP À L’ARRACHE logiciel 4. Exécution auto-matique des tests 1. Conception des tests Développement Architecture Résultats Production
  • 56. 585 8 3. Développement 2. Automatisation 1. Conception des tests des tests logiciel 4. Exécution auto-matique des tests #1 #2 #3 Architecture Développement Production Tests de charge en continue
  • 57. 595 9 Intégrer les tests de performances au cycle de développement? Hyperviseur AppServer Chef DbServer Chef 1 2 3 Créer environnement Tir de performance Destruction environnement
  • 58. 626 2 DÉMO 62 Automatisation des tests
  • 59. LES DIFFÉRENTS TYPES DE TEST 636 3 • 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
  • 60. 646 4 Test de rupture 100 requêtes par secondes nombre d'utilisateurs
  • 61. 656 5 Montée en charge nombre d'utilisateurs durée 2h 0 min delay ramp up duration
  • 62. 666 6 Montée en charge et retour à la normal nombre d'utilisateurs durée delay ramp up duration
  • 63. 676 7 Mesure Gatling
  • 64. 686 8 Mesures Graphite
  • 66. LES DIFFÉRENTS TYPES DE TEST 707 0 • 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
  • 67. 717 1 ! Déterminer la capacité de l’application à fonctionner sur une période étendue ! Durant ce tests on va surveiller les dérives au cours du temps : ! Temps de réponse ! Consommation de ressource (espace disk, CPU, mémoire, etc.) ! Libération des ressources (connexions, file, etc.) ! Mémoire Objectif
  • 68. 727 2 Montée en charge nombre d'utilisateurs durée 20 min 24h delay ramp up duration
  • 69. 737 3 DÉMO 73 Test d’endurance
  • 70. 747 4 Memory Leak [1/3] ! Analyse des logs GC avec HPJMeter (ou Censum) ! -Xloggc:gc.log -XX:+PrintTenuringDistribution -XX:+PrintGCDetails
  • 71. 757 5 ! Heapdump puis Eclipse Memory Analyzer (statique) ! Rapport sur les suspects Memory Leak [2/3]
  • 72. 767 6 ! Visual VM (dynamique) Memory Leak [3/3] ! On cherche les objets vivants avec un grand nombre de génération ! Jdk 8+ pour les JVM remote
  • 73. 777 7 Résumé de la session Préparer les jeux de données Benerator Exécuter une mesure unitaire Chrome developer tools Identifier un problème d’index jstack, explain plan Exécuter des tests de charge Gatling Automatisation des tests de charge Jenkins, Capistrano, Chef Problème de contention VisualVM, jstack Mise en place du monitoring Metrics, collectd et Graphite Identifier une fuite mémoire VisualVM, EMA, HPJMeter Tuning système Bonnie++
  • 74. 787 8 ! Tunning Système ! Exemple Bonnie++ Pour aller plus loin
  • 75. 808 0 ! La conférence originale à Devoxx FR 2014 : https://parleys.com/play/536749d1e4b04bb59f502709 ! Exemple de benchmark: http://blog.octo.com/lart-du-benchmark/ ! Conférence sur l’industrialisation (USI 2013): https://www.youtube.com/watch?v=BXO3LYQ9Vic ! Tests de performance SQLFire: http://blog.octo.com/en/sqlfire-from-the-trenches/ Liens utiles
  • 76. 818 1 ! Remerciement à Henri Tremblay, Marc Bojoly, Mickaël Robert & Ludovic Piot
  • 77. 828 2 +Jean Philippe Briend @jpbriend jpbriend@octo.com +Philippe Kernevez @pkernevez pkernevez@octo.com