Téléchargé parHenri Tremblay
Perf university
Le document présente une approche détaillée pour mesurer et optimiser la performance des systèmes informatiques à travers des tests variés comme les tests de charge, de performance unitaire, et de rupture. Il souligne l'importance d'intégrer des performances de test au cycle de développement, utilisant des outils spécifiques et des méthodologies pour assurer des performances adéquates des applications. Enfin, des exemples d'architecture et des cas pratiques sont fournis pour illustrer l'application de ces concepts.
Contenu connexe
![[PFE] Master en ingénierie du logiciel](https://cdn.slidesharecdn.com/ss_thumbnails/prezpfebrjuin2010v2-110814125524-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Agile Testing Day] Test & Métiers](https://cdn.slidesharecdn.com/ss_thumbnails/testsmanuels-mikaelkrief-160126180354-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Agile Testing Day] Introduction](https://cdn.slidesharecdn.com/ss_thumbnails/intro-michelperfetti-160126175852-thumbnail.jpg?width=640&height=640&fit=bounds)
Perf university
- 1. 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
- 2. 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
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10. 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
- 11. 1111 Architecte Senior Responsable pôle performance ResponsableR&D Membre fondateur du PerfUG Marc Bojoly
- 12. 1212 Architecte Senior Référent techniquepôle performance Responsable R&D EasyMock lead developer Objenesis lead developer Membre fondateur du PerfUG Henri Tremblay
- 13. 1313 Architecte Senior Pôle Devops Expertoptimisation 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èmesont une spécification fonctionnelle implicite du système Notre vision ? Source : www.arthursclipart.org
- 16. 1616 La mesure deperformance doit être au cœur du processus de développement informatique Notre vision ? Source : Les géants du Web
- 17. 1717 Nous voulons dessystèmes performants Notre vision ? Source : Les géants du Web
- 18. 1818 La démarche detest que nous utilisons TESTS DE CHARGE Mesurer Optimiser TESTS DE PERFORMANCE UNITAIRE
- 19. 1919 La démarche detest 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 planet 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ésaujourd’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 engé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 !
- 24.
- 25.
- 26.
- 27. 2727 Calcul de l’inventairesur un magasin Inventory http://localhost:8080/happystore/inventory? storeId=1234
- 28. 2828 Calcul du chiffred’affaire par groupe de produits Turnover (group by+order by) http://localhost:8080/happystore/turnover? groupId=1
- 29. 2929 LES DIFFÉRENTS TYPESDE 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
- 30.
- 31. 3131 LES DIFFÉRENTS TYPESDE 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
- 32. 3232 Cible de performance Cible: 100 utilisateurs concurrents Volumétrie de la base de données : 19,5 millions de lignes
- 33.
- 34. 3434 Architecture LOCAL SERVER APPLICATIONSERVER DATABASE SERVER Gatling PostgreSQL JVM Tomcat
- 35.
- 36. 3636 Premature optimization is theroot of all evil - Donald Knuth
- 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!!!
- 38.
- 39.
- 40. 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
- 41. 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
- 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 testsde 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
- 45.
- 46. 4646 LES DIFFÉRENTS TYPESDE 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
- 47.
- 48. 4848 Architecture TOOL SERVER APPLICATIONSERVER DATABASE SERVER CI STACK GRAPHITE STACK Jenkins Gatling Maven Graphite Collectd Carbon Git Collectd Whisper PostgreSQL JVM Tomcat
- 49.
- 50. 5050 Un exemple d’outild’APM du marché : AppDynamics
- 51.
- 52. 5252 LES DIFFÉRENTS TYPESDE 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
- 53.
- 54. 5454 Préparer les jeuxde 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érencesur 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 lasemaine 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
- 57.
- 58. 5858 +Henri Tremblay @henri_tremblay htremblay@octo.com +Marc Bojoly @mbojoly mbojoly@octo.com +MikaelRobert @mikaelrob mrobert@octo.com +Ludovic Piot @lpiot lpiot@octo.com
Notes de l'éditeur
- #4 Tuning
- #6 Suivide performance
- #8 Méthodologie… parcequeil en fauttoujours un petit peu
- #36 Recording GatlingExécution du test de chargeProblème du statfilter
- #37 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
- #38 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
- #39 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
- #48 Test de rupture maisçaseraitbiend’avoir un peu de métriques en temps réelMetricsGraphite
- #54 Testd’enduranceMemory leakTuning systèmeIdées:Saturation disqueBuffer TCPTuning paramètres filesystemNIOPool de connexions DBGros log en debugCalcul de la vitesse disque, optimisation
- #58 É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.