12. 1212
Architecte Senior
Référent technique pôle
performance
Responsable R&D
EasyMock lead developer
Objenesis lead developer
Membre fondateur du PerfUG
Henri Tremblay
13. 1313
Architecte Senior
Pôle Devops
Expert optimisation système
Co-organisateur du concours
de performance Billion-user
challenge en 2011
Intervenant PerfUG
Ludovic Piot
14. 1414
Architecte
Expert Infra & Devops
Responsable de l’infrastructure
OCTO
Commiter :
Master-chef
Master-cap
Mikaël Robert
15. 1515
Les performances d’un
système sont une
spécification
fonctionnelle implicite
du système
Notre vision ?
Source : www.arthursclipart.org
16. 1616
La mesure de performance
doit être au cœur du
processus de
développement
informatique
Notre vision ?
Source : Les géants du Web
17. 1717
Nous voulons des systèmes
performants
Notre vision ?
Source : Les géants du Web
18. 1818
La démarche de test que nous utilisons
TESTS DE CHARGE
Mesurer
Optimiser
TESTS DE PERFORMANCE
UNITAIRE
19. 1919
La démarche de test que nous utilisons
TESTS DE CHARGE
TESTS DE PERFORMANCE
UNITAIRE
Mesurer
Optimiser
Mise en place
des mesures
et scénarios
Exécution des
scénarios
• Simulation
• Correction
• Mesure
Optimisation
Estimation des
gains potentiels
• Sur un poste de
développement
• Validation des
hypothèses
• Tuning des « hot
spots »
• Environnements de
production
• Scénarios
représentatifs
• Jeux de données
• Cible à atteindre
20. 2020
Définition du plan et des
cas de test
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
Analyse du rapport de
test et émission des
préconisations Rapport d’analyse
Métriques
Rapport de test
Contrôleur
Scripts de test Scénarii de test
Capture des
métriques
Application cible
Injecteurs
Données de test
Création des paliers
de données
Exécution : simulation
d’utilisateurs
Méthodologie d’un test de charge
1 1
2
3
3
3
4
5
21. 2121
Les outils utilisés aujourd’hui
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
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
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é
GÉNÉRER LES DONNÉES
TESTER EN CHARGE
MONITORER LA CONSOMMATION DE
RESSOURCES
22. 2222
Les outils en général
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
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
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é
GÉNÉRER LES DONNÉES
TESTER EN CHARGE
MONITORER LA CONSOMMATION DE
RESSOURCES
23. 2323
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 !
27. 2727
Calcul de l’inventaire sur un magasin
Inventory
http://localhost:8080/happystore/inventory?
storeId=1234
28. 2828
Calcul du chiffre d’affaire par groupe de produits
Turnover
(group by+order
by)
http://localhost:8080/happystore/turnover?
groupId=1
29. 2929
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
31. 3131
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
37. 3737
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!!!
42. 4242
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
43. 4343
Intégrer les tests de performances au cycle de
développement?
Hyperviseur
Jenkins
AppServer
Chef
DbServer
Chef
1
3
2
Créer environnement
Tir de performance
Destruction environnement
44. 4444
Jenkins
Deploiement d’environnement automatisé : exemple avec Chef & Capistrano
Git
Nexus
Capistrano
Node
Chef
Hyperviseur
API hyperviseur
Node
Chef
Node
Chef
Dép. app.
2
1
1
3
• Capistrano demande VM à l’hyperviseur
• Installation OS par PXE ou clone
2 • Création & mise à disposition VMs
• SSH ouvert, IP temporaire
3
• Scripts de démarrage (maison, cloud-init…)
• Personnalisation VM, IP, Reseau etc
• Installation Chef
4
4
4
• Capistrano lance Chef sur Node
• Chef récupère les cookbooks via Git
• Installation packages et configurations
5
5
5
• Capistrano lance déploiement application
• Exécute sur machine téléchargement application
• Déploie application
• Administrateur
lance job
0
46. 4646
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
52. 5252
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
54. 5454
Préparer les jeux de données Benerator
Exécuter une mesure unitaire Chrome developer tools
Identifier un problème d’index jstack, explan 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
Tuning système Bonnie++
Identifier une fuite mémoire VisualVM
Résumé de la journée
55. 5555
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/
Cet après-midi:
13h30: Hackergarten EasyMock
17h10: Microbenchmarking with JMH
Liens utiles
http://brownbaglunch
.fr
56. 5656
Retrouvez nous la semaine prochaine
http://perfug.github.io
/
Prochain épisode: Jeudi 24
avril
Performance Hadoop temps
réel
Sofian Djamaa (Criteo)
Sessions précédentes
sur le site
Méthodologie… parcequeil en fauttoujours un petit peu
Recording GatlingExécution du test de chargeProblème du statfilter
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 importantMais reprenons du début
Test de rupture maisçaseraitbiend’avoir un peu de métriques en temps réelMetricsGraphite
Testd’enduranceMemory leakTuning systèmeIdées:Saturation disqueBuffer TCPTuning paramètres filesystemNIOPool de connexions DBGros log en debugCalcul de la vitesse disque, optimisation
Évidemment, on a un peu simplifier pour les besoins de la présentation. Ce qu’il faut retenir c’est que c’est tout à fait possible à mettre en place. Et en cas de besoin, Mikaël et moi sommes là pour vous aider.
