11
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2014
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Université de la
Performance
22
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2014
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Agenda
33
44
Applicatif Système
55
66
Développement Production
77
Méthodologie
88
DÉMO
99
Pause
2x10 minutes
1010
Tél : +33 (0)1 58 56 10 00
Fax : +33 (0)1 58 56 10 01
www.octo.com© OCTO 2014
50, avenue des Champs-Elysées
75008 Paris - FRANCE
Présentation de
l’équipe
1111
Architecte Senior
Responsable pôle
performance
Responsable R&D
Membre fondateur du PerfUG
Marc Bojoly
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
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
1414
Architecte
Expert Infra & Devops
Responsable de l’infrastructure
OCTO
Commiter :
Master-chef
Master-cap
Mikaël Robert
1515
Les performances d’un
système sont une
spécification
fonctionnelle implicite
du système
Notre vision ?
Source : www.arthursclipart.org
1616
La mesure de performance
doit être au cœur du
processus de
développement
informatique
Notre vision ?
Source : Les géants du Web
1717
Nous voulons des systèmes
performants
Notre vision ?
Source : Les géants du Web
1818
La démarche de test que nous utilisons
TESTS DE CHARGE
MesurerOptimiser
TESTS DE PERFORMANCE
UNITAIRE
1919
La démarche de test que nous utilisons
TESTS DE CHARGE
TESTS DE PERFORMANCE
UNITAIRE
MesurerOptimiser
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
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
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
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
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 !
2424
Architecture
APPLICATION SERVER
DATABASE SERVER
JVM
PostgreSQL
Tomcat
2525
Acheter des produits
http://localhost:8080/happystore/transaction?
countryCode=FRA&productId=1234&storeId=1234
http://localhost:8080/happystore/transaction?
countryCode=FRA&productId=1234&storeId=1234&txId=1
2626
Finaliser sa commande
http://localhost:8080/happystore/total?
txId=1
Total
2727
Calcul de l’inventaire sur un magasin
Inventory
http://localhost:8080/happystore/inventory?
storeId=1234
2828
Calcul du chiffre d’affaire par groupe de produits
Turnover
(group by+order by)
http://localhost:8080/happystore/turnover?
groupId=1
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
3030
DÉMO
Exécution test unitaire
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
3232
Cible de performance
Cible : 100 utilisateurs concurrents
Volumétrie de la base de données : 19,5 millions de lignes
3333
DÉMO
Remplissage des données
3434
Architecture
LOCAL SERVER APPLICATION SERVER
DATABASE SERVER
Gatling
PostgreSQL
JVM
Tomcat
3535
DÉMO
Exécution test de charge
3636
Premature optimization is the
root of all evil - Donald Knuth
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!!!
3838
Code
Mesure
OptimiseLà où
c’est
important
3939
PROD
Archi
Dev
Perf
4040
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
4141
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
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
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
4444
Jenkins
Deploiement d’environnement automatisé : exemple avec Chef & Capistrano
GitNexus
Capistrano
Node
Chef
Hyperviseur
API hyperviseurNode
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 job0
4545
DÉMO
Automatisation des tests
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
4747
DÉMO
Test de rupture
4848
Architecture
TOOL SERVER APPLICATION SERVER
DATABASE SERVER
CI STACK
GRAPHITE STACK
Jenkins Gatling
Maven
Graphite
Collectd
Carbon
Git
Collectd
WhisperPostgreSQL
JVM
Tomcat
4949
DÉMO
Metrics
5050
Un exemple d’outil d’APM du marché : AppDynamics
5151
DÉMO
Tuning
5252
Bonnie++
5353
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
5454
DÉMO
Test d’endurance
5555
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
5656
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
5757
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
5858
5959
+Henri Tremblay
@henri_tremblay
+Marc Bojoly
@mbojoly
+Mikael Robert
@mikaelrob
+Ludovic Piot
@lpiot
Top Related