Performance User Group #1Marc BOJOLY, OCTO TechnologyHenri TREMBLAY, OCTO Technology
• Wifi• Récupérer le labgit clone https://github.com/perfug/sampleapp1.git• Compiler et tester l’exécution– Voir README.MD...
• Introduction (5 min.)– Le Performance User Group Paris• Présentation (30 min.)– Performance for the dummies : introducti...
Wikipedia« [Les tests de performance] vont avoir pour objectifde mesurer les temps de réponse dunsystème applicatif en fon...
5NOTRE VISION ?Source : www.arthursclipart.orgLes performancesd’un système sont unespécificationfonctionnelle implicitedu ...
6NOTRE VISION ?Source : Les géants du WebLa mesure deperformance doit êtreau cœur du processusde développementinformatique
7Notre vision ?Source : Les géants du WebNous voulons dessystèmes performants
8NOTRE DEVISE ?LES TEMPS DE RÉPONSE NOUS DIMINUERONSLES DÉBITS NOUS AUGMENTERONSLES RESSOURCES NOUS ÉPARGNERONSLA HAUTE DI...
9NOTRE MISSION?Source : Paris JUGOffrir un lieud’échanges informelsoù toutes lespersonnes intéresséespar l’optimisation et...
10NOTRE MISSION ?Faciliter la diffusiondes derniers outils etdes meilleurestechniques pourmaîtriser au plus tôt laperforma...
PerfUG - Performance for thedummiesIntroduction aux tests de charge11
Un exemple de démarche12Et ensuite?Les tests de performanceLes tests de chargeSOMMAIRE
13Et ensuite?Les tests de performanceLes tests de chargeUn exemple de démarcheSOMMAIRE
14LES DIFFÉRENTS TYPES DE TEST• Objectif : mesurer la performance unitaire• Ex : le use case de souscription est testé pou...
Démarche de test que nous utilisonsMise en placedes mesureset scénariosExécution desscénariosOptimisationEstimation desgai...
16Et ensuite?Les tests de performanceLes tests de chargeUn exemple de démarcheSOMMAIRE
Méthodologie d’un test de chargeDéfinition du plan et descas de testPlan de test Cas de test2 Création des scénarii etdes ...
GÉNÉRER LES DONNÉESIdentifier les ressources en quantité limitanteIdentifier les impacts sur les différentesmachines lorsq...
LES GRANDS TYPES DE GOULETS D’ÉTRANGLEMENTINSTABILITÉ DU SYSTÈME = ECHEC DU TEST !Toute exception doit être analyséeLes ca...
20Les nouveautésLes tests de performanceLes tests de chargeUn exemple de démarcheSOMMAIRE
LES TESTS DE PERFORMANCE21OBJECTIFSAffiner l’analyse et la compréhension des problèmes de performance.Tester différentes a...
L’optimisation de performances se fait en intervenant sur plusieurs niveauxPrincipes d’optimisation22• Ex : optimisation a...
La mesure est un point essentiel dans l’optimisation des performances.POINTS DE VIGILANCEL’infrastructure doit être proche...
Hands-on Lab24
• Une application « POC »– 5 actions possibles / 9 tables– API exposée sous forme d’URL GETpour faciliter la testabilité– ...
• READMEcd frontrun.bat<MyBrowser> http://localhost:8080/cd injectorrun.bat• 1er tir avec Gatling– Environ 60 s. de tir– 3...
Le scénario se trouve dansinjector/src/test/scala/NewSqlSimulation.scalaCONFIGURATION DE GATLING27
• 1 utilisateur effectuant 1 scénario en boucle• 1 tir de chauffe– Permet de charger les caches– Permet de stabiliser la J...
• users = 1/0/0• rampUp = 0• duration = 30• 1 scénario à la fois (séquentiellement?)• checkStatus + regexpÉtape 1: Configu...
• Suivi GC-XX:+PrintGCDetails -XX:+PrintTenuringDistribution -Xloggc:gc.log• Suivi compilation-XX:-PrintCompilationÉtape 1...
• Nombre d’utilisateurs cible effectuant lesscénarii en boucle• 1 tir de chauffe– Permet de charger les caches– Permet de ...
• users = 80/10/10• rampUp = 10• duration = 40• Tous les scénarii simultanémentÉtape 2: Configuration Gatling
• Moyenne– Donne une idée des performances– Haute: Pas bon– Basse: Peut-être bonÉtape 2: Les métriques01000200030004000500...
• Écart-type– Donne une idée de la stabilité du système– Haut: Pas bon– Basse: Peut-être bon– Mais en pratique, doit être ...
• Centile 95 et 99 (ou autres)– Très utile pour connaître les ralentissementsqu’auront un certain pourcentage de vosutilis...
• Ajout constant d’utilisateurs effectuant lesscénarii en boucle• On arrête dès que l’on reçoit des erreursou que les temp...
• users = 640/80/80• rampUp = 160• duration = 860• Tous les scénarii simultanément• Ctrl+C et générer le rapport– ro.batÉt...
• Nombre d’utilisateurs cible effectuant lesscénarii en boucle• Think times minimaux• On surveille– Une potentielle dégrad...
• users = 160/20/20• rampUp = 10• duration = 2000• think ratio = 0• Tous les scénarii simultanémentÉtape 4: Configuration ...
SommaireLes tests de performanceLes tests de chargeUn exemple de démarcheEt ensuite?
QUELQUES PISTES POUR LES PROCHAINES SÉANCES41L’ÉVOLUTION DES ARCHITECTURES PHYSIQUESOptimisation de la parallélisation pou...
Qu’est-ce qui vous donnerait envie de participer à ceUser Group ?ET VOUS ?42
Prochain SlideShare
Chargement dans…5
×

Performance ug#1

2 056 vues

Publié le

1ère séance du Perfug, 21 mai 2013

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 056
Sur SlideShare
0
Issues des intégrations
0
Intégrations
235
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Performance ug#1

  1. 1. Performance User Group #1Marc BOJOLY, OCTO TechnologyHenri TREMBLAY, OCTO Technology
  2. 2. • Wifi• Récupérer le labgit clone https://github.com/perfug/sampleapp1.git• Compiler et tester l’exécution– Voir README.MD• L’importer dans votre IDE préféré• Récupérer GCViewer (optionnel)2Avant de commencer
  3. 3. • Introduction (5 min.)– Le Performance User Group Paris• Présentation (30 min.)– Performance for the dummies : introduction aux tests de charge• Hands-on-lab (55 min.)– Une application modélisant un front-office– Un injecteur : gatling– De quoi s’amuser !• Questions / réponses (15 min.)3CONTENU DE LA SOIREE
  4. 4. Wikipedia« [Les tests de performance] vont avoir pour objectifde mesurer les temps de réponse dunsystème applicatif en fonction de sasollicitation. Cette définition est donc trèsproche de celle de test de charge où lonmesure le comportement dun système enfonction de la charge dutilisateurs simultanés.Seuls les tests de charge permettent de validercorrectement une application ou un systèmeavant déploiement, tant en Qualité de Servicequen consommation de ressources. »4BIENVENUE AU PERFORMANCE USER GROUPLarousseRésultat chiffré (en tempsou en distance) dunathlète ou dun cheval àlissue dune épreuve.La performance d’unsystème informatiqueest caractérisée par lestemps de traitementdans un contexte etsous une sollicitationdonnés.
  5. 5. 5NOTRE VISION ?Source : www.arthursclipart.orgLes performancesd’un système sont unespécificationfonctionnelle implicitedu système
  6. 6. 6NOTRE VISION ?Source : Les géants du WebLa mesure deperformance doit êtreau cœur du processusde développementinformatique
  7. 7. 7Notre vision ?Source : Les géants du WebNous voulons dessystèmes performants
  8. 8. 8NOTRE DEVISE ?LES TEMPS DE RÉPONSE NOUS DIMINUERONSLES DÉBITS NOUS AUGMENTERONSLES RESSOURCES NOUS ÉPARGNERONSLA HAUTE DISPONIBILITÉ NOUSPRÉCONISERONS
  9. 9. 9NOTRE MISSION?Source : Paris JUGOffrir un lieud’échanges informelsoù toutes lespersonnes intéresséespar l’optimisation et laperformance sont lesbienvenues quel quesoit leur niveau
  10. 10. 10NOTRE MISSION ?Faciliter la diffusiondes derniers outils etdes meilleurestechniques pourmaîtriser au plus tôt laperformance d’unsystème informatique
  11. 11. PerfUG - Performance for thedummiesIntroduction aux tests de charge11
  12. 12. Un exemple de démarche12Et ensuite?Les tests de performanceLes tests de chargeSOMMAIRE
  13. 13. 13Et ensuite?Les tests de performanceLes tests de chargeUn exemple de démarcheSOMMAIRE
  14. 14. 14LES DIFFÉRENTS TYPES DE TEST• Objectif : mesurer la performance unitaire• Ex : le use case de souscription est testé pour 1 utilisateuret, pour chaque étape du use case, on mesure le tempspassé dans les différents composants de l’applicationTest deperformance• Objectif : mesurer la tenue en charge de l’application sur lapopulation cible• Ex : on simule l’utilisation de l’application par 200 utilisateursen parallèle pendant 2hTest decharge• Objectif : déterminer les limites de l’application• Ex : on augmente le nombre d’utilisateurs en parallèle surl’application jusqu’à ce que le taux d’erreurs / les temps deréponse ne soient plus acceptablesTest derupture• Objectif : déterminer la capacité de l’application à fonctionnersur une période étendue• Ex : on simule l’utilisation de l’application pendant 48h, avecune charge constante et égale à la charge moyenneTest devieillissement
  15. 15. Démarche de test que nous utilisonsMise en placedes mesureset scénariosExécution desscénariosOptimisationEstimation desgains potentiels• Vérifier lesenvironnements• Définition des scénariosreprésentatifs pourl’étape de tests decharge• Génération des jeux dedonnées• Définition d’une cible àatteindre• Tests de charge avecune volumétriereprésentative de laproduction• Exécution de tests deperformance locaux surles « hot spot » ettuning en fonction durésultat• Validation deshypothèsesTests de charge Tests de performance15
  16. 16. 16Et ensuite?Les tests de performanceLes tests de chargeUn exemple de démarcheSOMMAIRE
  17. 17. Méthodologie d’un test de chargeDéfinition du plan et descas de testPlan de test Cas de test2 Création des scénarii etdes scripts de tests3 Enregistrement desmétriques4Consolidation desmétriques et éditiond’un rapport de test5Analyse du rapport detest et émission despréconisations Rapport d’analyseMétriquesRapport de testContrôleurScripts de test Scénarii de testCapture desmétriquesApplication cibleInjecteursDonnées de test1 Création des paliers dedonnéesExécution : simulationd’utilisateurs13317
  18. 18. GÉNÉRER LES DONNÉESIdentifier les ressources en quantité limitanteIdentifier les impacts sur les différentesmachines lorsque l’application est distribuéeCorréler l’évolution des temps de réponse et lesconsommations de ressources sur lesdifférentes machinesMONITORER LA CONSOMMATION DERESSOURCESEnregistrer et rejouer de manière fidèle unensemble d’actions utilisateurs.Variabiliser ces actions utilisateurs pour êtrereprésentatif de l’usage réelSimuler un grand nombre d’utilisateursTESTER EN CHARGEMigrer les données depuis la production mais il fautsouvent l’anonymiser.Générer un jeux de données mais il doit êtrereprésentatifRétablir le jeux de données dans son état initial unefois le tir effectué18WindowsLES OUTILS À UTILISERNMonUn outil fantastiquedont vous souhaiteriezpartager?
  19. 19. LES GRANDS TYPES DE GOULETS D’ÉTRANGLEMENTINSTABILITÉ DU SYSTÈME = ECHEC DU TEST !Toute exception doit être analyséeLes causes peuvent être multiples et liées à la charge (fuitemémoire, fuite de connection, fuite de threads…)Ou pas INFO: Server startup in 7722 msApr 7, 2013 7:57:38 PM org.apache.tomcat.util.net.NioEndpoint processSocket SEVERE: Errorallocating socket processorjava.util.concurrent.RejectedExecutionExceptionatjava.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1956)at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:816)at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1337)at org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:1272)at org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:1259)at org.apache.tomcat.util.net.NioEndpoint.processSocket(NioEndpoint.java:1251)at org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:1689)at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1627)at java.lang.Thread.run(Thread.java:679)SATURATION DES RESSOURCESLa saturation d’une ressource est un début ou un aboutissementGoulet d’étrangement à adresser pour passer à l’échelleOu point de départ de l’optimisationCPU19I/OLOCKS ET DEAD LOCKSL’absence de toute autre cause est souvent ce qui met sur la voied’un problème de lock.L’analyse des deadlocks peut en soit nous occuper toute uneséance….CPUI/O
  20. 20. 20Les nouveautésLes tests de performanceLes tests de chargeUn exemple de démarcheSOMMAIRE
  21. 21. LES TESTS DE PERFORMANCE21OBJECTIFSAffiner l’analyse et la compréhension des problèmes de performance.Tester différentes alternatives d’optimisation possible et mesurer les améliorations qu’ellesapportent.Itérer facilement entre différentes optimisations possibles.MÉTHODOLOGIEL’objectif ici n’étant pas d’obtenir des mesures exactes, des instrumentations plus intrusives sontenvisageablesLes investigations sont réalisées• Avec les sources du code• Sur un poste de développement ou avec une manière de déployer très fréquemment• Avec les droits d’administration pour réaliser tout cela….
  22. 22. L’optimisation de performances se fait en intervenant sur plusieurs niveauxPrincipes d’optimisation22• Ex : optimisation algorithmique, gestion dumulti-threadingCode etarchitectureapplicative• Ex : tuning des paramètresFramework• Ex : taille des pools dethreads, taille de la mémoireallouée à la base…Couches basses : basede données, serveurd’application• Ex : nbmachines, configuration réseau…InfrastructureL’OPTIMISATION
  23. 23. La mesure est un point essentiel dans l’optimisation des performances.POINTS DE VIGILANCEL’infrastructure doit être proche de l’infrastructure cible pour que lestests soient pertinents.23Les temps de réponse des systèmes externes sollicités doivent aussiêtre consciencieusement mesurés.Les jeux de données utilisés doivent être représentatifs des donnéesde production pour que les résultats soient pertinents
  24. 24. Hands-on Lab24
  25. 25. • Une application « POC »– 5 actions possibles / 9 tables– API exposée sous forme d’URL GETpour faciliter la testabilité– Prépackagé avec H2• Une application Front Office– Encaissement d’article– Calcul d’un total avec TVA variable parpays et par catégorie d’article– Gestion d’un stock par magasin• Une architecture classique– Hibernate / Spring / Spring MVC– StatelessNewsql App25
  26. 26. • READMEcd frontrun.bat<MyBrowser> http://localhost:8080/cd injectorrun.bat• 1er tir avec Gatling– Environ 60 s. de tir– 31 req/s. sur mon portable• Objectifs– Quel débit maximum vouspouvez atteindre avec votremachine ?– Quel est le gouletd’étranglement?HANDS-ON LAB HOW-TO ?1 POM avec services, models etdata repositories1 POM SpringMVCInjecteur GatlingOuvrirInjector/target/gatling/newsqlsimulation-YYYYMMDDHHmmss/index.html26
  27. 27. Le scénario se trouve dansinjector/src/test/scala/NewSqlSimulation.scalaCONFIGURATION DE GATLING27
  28. 28. • 1 utilisateur effectuant 1 scénario en boucle• 1 tir de chauffe– Permet de charger les caches– Permet de stabiliser la JVM• 1 tir réel– Permet de mesurer les temps de réponseunitaire– Nécessite d’avoir une cible de temps deréponseÉtape 1: Test de performance
  29. 29. • users = 1/0/0• rampUp = 0• duration = 30• 1 scénario à la fois (séquentiellement?)• checkStatus + regexpÉtape 1: Configuration Gatling
  30. 30. • Suivi GC-XX:+PrintGCDetails -XX:+PrintTenuringDistribution -Xloggc:gc.log• Suivi compilation-XX:-PrintCompilationÉtape 1: Configuration JVM
  31. 31. • Nombre d’utilisateurs cible effectuant lesscénarii en boucle• 1 tir de chauffe– Permet de charger les caches– Permet de stabiliser la JVM• 1 tir réel– Permet de mesurer les temps de réponse encharge normale– Permet de les comparer aux temps de réponseunitaire pour établir la dégradationÉtape 2: Test de charge
  32. 32. • users = 80/10/10• rampUp = 10• duration = 40• Tous les scénarii simultanémentÉtape 2: Configuration Gatling
  33. 33. • Moyenne– Donne une idée des performances– Haute: Pas bon– Basse: Peut-être bonÉtape 2: Les métriques010002000300040005000600070000,5s 1s 1,5s 2sNombre de requêtesNombre derequêtes
  34. 34. • Écart-type– Donne une idée de la stabilité du système– Haut: Pas bon– Basse: Peut-être bon– Mais en pratique, doit être utilisé avec lecentileÉtape 2: Les métriques
  35. 35. • Centile 95 et 99 (ou autres)– Très utile pour connaître les ralentissementsqu’auront un certain pourcentage de vosutilisateurs– Avoir une cible pour savoir ce que l’on est prêtà accepter ou nonÉtape 2: Les métriques
  36. 36. • Ajout constant d’utilisateurs effectuant lesscénarii en boucle• On arrête dès que l’on reçoit des erreursou que les temps de réponse deviennentparticulièrement longÉtape 3: Test de rupture
  37. 37. • users = 640/80/80• rampUp = 160• duration = 860• Tous les scénarii simultanément• Ctrl+C et générer le rapport– ro.batÉtape 3: Configuration Gatling
  38. 38. • Nombre d’utilisateurs cible effectuant lesscénarii en boucle• Think times minimaux• On surveille– Une potentielle dégradation desperformances– Une augmentation de la mémoire (« memoryleak »)Étape 4: Test d’endurance
  39. 39. • users = 160/20/20• rampUp = 10• duration = 2000• think ratio = 0• Tous les scénarii simultanémentÉtape 4: Configuration Gatling
  40. 40. SommaireLes tests de performanceLes tests de chargeUn exemple de démarcheEt ensuite?
  41. 41. QUELQUES PISTES POUR LES PROCHAINES SÉANCES41L’ÉVOLUTION DES ARCHITECTURES PHYSIQUESOptimisation de la parallélisation pour bénéficier des architectures multi-coreMonitoring des environnements virtuels et assurer des quotas de ressourcesOptimisation du scheduling de tâches dans un environnement multi-tenant (processeur Unixou Jobs Hadoop)…L’ÉVOLUTION DES OS ET DES MIDDLEWARESNon-blocking I/O, Node.JS : concurrence au niveau des I/OGC et ses limites…L’ÉVOLUTION DES DES MÉTHODOLOGIESLes meilleures solutions de monitoring (AppDynamics, Dynatrace…)Les fonctionnalités des différents profiler (JVisualVM, Yourkit, DotTrace…)Les possibilités de tuning des bases de données (Insider de FourthElephant)L’inclusion au sein de l’usine de build (gatling-maven-plugin, …)…
  42. 42. Qu’est-ce qui vous donnerait envie de participer à ceUser Group ?ET VOUS ?42

×