Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Performance ug#1

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 42 Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (19)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à Performance ug#1 (20)

Publicité

Plus récents (20)

Performance ug#1

  1. 1. Performance User Group #1 Marc BOJOLY, OCTO Technology Henri TREMBLAY, OCTO Technology
  2. 2. • Wifi • Récupérer le lab git 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) 2 Avant 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.) 3 CONTENU DE LA SOIREE
  4. 4. Wikipedia « [Les tests de performance] vont avoir pour objectif de mesurer les temps de réponse d'un système applicatif en fonction de sa sollicitation. Cette définition est donc très proche de celle de test de charge où l'on mesure le comportement d'un système en fonction de la charge d'utilisateurs simultanés. Seuls les tests de charge permettent de valider correctement une application ou un système avant déploiement, tant en Qualité de Service qu'en consommation de ressources. » 4 BIENVENUE AU PERFORMANCE USER GROUP Larousse Résultat chiffré (en temps ou en distance) d'un athlète ou d'un cheval à l'issue d'une épreuve. La performance d’un système informatique est caractérisée par les temps de traitement dans un contexte et sous une sollicitation donnés.
  5. 5. 5 NOTRE VISION ? Source : www.arthursclipart.org Les performances d’un système sont une spécification fonctionnelle implicite du système
  6. 6. 6 NOTRE VISION ? Source : Les géants du Web La mesure de performance doit être au cœur du processus de développement informatique
  7. 7. 7 Notre vision ? Source : Les géants du Web Nous voulons des systèmes performants
  8. 8. 8 NOTRE DEVISE ? LES TEMPS DE RÉPONSE NOUS DIMINUERONS LES DÉBITS NOUS AUGMENTERONS LES RESSOURCES NOUS ÉPARGNERONS LA HAUTE DISPONIBILITÉ NOUS PRÉCONISERONS
  9. 9. 9 NOTRE MISSION? Source : Paris JUG Offrir un lieu d’échanges informels où toutes les personnes intéressées par l’optimisation et la performance sont les bienvenues quel que soit leur niveau
  10. 10. 10 NOTRE MISSION ? Faciliter la diffusion des derniers outils et des meilleures techniques pour maîtriser au plus tôt la performance d’un système informatique
  11. 11. PerfUG - Performance for the dummies Introduction aux tests de charge 11
  12. 12. Un exemple de démarche 12 Et ensuite? Les tests de performance Les tests de charge SOMMAIRE
  13. 13. 13 Et ensuite? Les tests de performance Les tests de charge Un exemple de démarche SOMMAIRE
  14. 14. 14 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 • 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
  15. 15. Démarche de test que nous utilisons Mise en place des mesures et scénarios Exécution des scénarios Optimisation Estimation des gains potentiels • Vérifier les environnements • Définition des scénarios représentatifs pour l’étape de tests de charge • Génération des jeux de données • Définition d’une cible à atteindre • Tests de charge avec une volumétrie représentative de la production • Exécution de tests de performance locaux sur les « hot spot » et tuning en fonction du résultat • Validation des hypothèses Tests de charge Tests de performance 15
  16. 16. 16 Et ensuite? Les tests de performance Les tests de charge Un exemple de démarche SOMMAIRE
  17. 17. Méthodologie d’un test de charge Définition du plan et des cas de test Plan de test Cas de test 2 Création des scénarii et des scripts de tests 3 Enregistrement des métriques 4 Consolidation des métriques et édition d’un rapport de test 5 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 1 Création des paliers de données Exécution : simulation d’utilisateurs 1 3 3 17
  18. 18. GÉNÉRER LES DONNÉES 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 MONITORER LA CONSOMMATION DE RESSOURCES 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 TESTER EN CHARGE 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é 18 Windows LES OUTILS À UTILISER NMon Un outil fantastique dont vous souhaiteriez partager?
  19. 19. LES GRANDS TYPES DE GOULETS D’ÉTRANGLEMENT INSTABILITÉ DU SYSTÈME = ECHEC DU TEST ! Toute exception doit être analysée Les causes peuvent être multiples et liées à la charge (fuite mémoire, fuite de connection, fuite de threads…) Ou pas  INFO: Server startup in 7722 ms Apr 7, 2013 7:57:38 PM org.apache.tomcat.util.net.NioEndpoint processSocket SEVERE: Error allocating socket processor java.util.concurrent.RejectedExecut ionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.jav a: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 RESSOURCES La saturation d’une ressource est un début ou un aboutissement Goulet d’étrangement à adresser pour passer à l’échelle Ou point de départ de l’optimisation CPU 19 I/O LOCKS ET DEAD LOCKS L’absence de toute autre cause est souvent ce qui met sur la voie d’un problème de lock. L’analyse des deadlocks peut en soit nous occuper toute une séance…. CPU I/O
  20. 20. 20 Les nouveautés Les tests de performance Les tests de charge Un exemple de démarche SOMMAIRE
  21. 21. LES TESTS DE PERFORMANCE 21 OBJECTIFS Affiner l’analyse et la compréhension des problèmes de performance. Tester différentes alternatives d’optimisation possible et mesurer les améliorations qu’elles apportent. Itérer facilement entre différentes optimisations possibles. MÉTHODOLOGIE L’objectif ici n’étant pas d’obtenir des mesures exactes, des instrumentations plus intrusives sont envisageables Les 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 niveaux Principes d’optimisation 22 • Ex : optimisation algorithmique, gestion du multi-threading Code et architecture applicative • Ex : tuning des paramètresFramework • Ex : taille des pools de threads, taille de la mémoire allouée à la base… Couches basses : base de données, serveur d’application • Ex : nb machines, configurat ion réseau… Infrastructure L’OPTIMISATION
  23. 23. La mesure est un point essentiel dans l’optimisation des performances. POINTS DE VIGILANCE L’infrastructure doit être proche de l’infrastructure cible pour que les tests soient pertinents. 23 Les 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ées de production pour que les résultats soient pertinents
  24. 24. Hands-on Lab 24
  25. 25. • Une application « POC » – 5 actions possibles / 9 tables – API exposée sous forme d’URL GET pour faciliter la testabilité – Prépackagé avec H2 • Une application Front Office – Encaissement d’article – Calcul d’un total avec TVA variable par pays et par catégorie d’article – Gestion d’un stock par magasin • Une architecture classique – Hibernate / Spring / Spring MVC – Stateless Newsql App 25
  26. 26. • README cd front run.bat <MyBrowser> http://localhost:8080/ cd injector run.bat • 1er tir avec Gatling – Environ 60 s. de tir – 31 req/s. sur mon portable • Objectifs – Quel débit maximum vous pouvez atteindre avec votre machine ? – Quel est le goulet d’étranglement? HANDS-ON LAB HOW-TO ? 1 POM avec services, models et data repositories 1 POM Spring MVC Injecteur Gatling Ouvrir Injector/target/gatling/ newsqlsimulation-YYYYMMDDHHmmss/index.html 26
  27. 27. Le scénario se trouve dans injector/src/test/scala/NewSqlSimulation.scala CONFIGURATION DE GATLING 27
  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éponse unitaire – Nécessite d’avoir une cible de temps de ré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 les scé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 en charge normale – Permet de les comparer aux temps de réponse unitaire 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étriques 0 1000 2000 3000 4000 5000 6000 7000 0,5s 1s 1,5s 2s Nombre de requêtes Nombre de requê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 le centile Étape 2: Les métriques
  35. 35. • Centile 95 et 99 (ou autres) – Très utile pour connaître les ralentissements qu’auront un certain pourcentage de vos utilisateurs – 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 les scénarii en boucle • On arrête dès que l’on reçoit des erreurs ou que les temps de réponse deviennent particuliè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 les scénarii en boucle • Think times minimaux • On surveille – Une potentielle dégradation des performances – Une augmentation de la mémoire (« memory leak ») É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. Sommaire Les tests de performance Les tests de charge Un exemple de démarche Et ensuite?
  41. 41. QUELQUES PISTES POUR LES PROCHAINES SÉANCES 41 L’ÉVOLUTION DES ARCHITECTURES PHYSIQUES Optimisation de la parallélisation pour bénéficier des architectures multi-core Monitoring des environnements virtuels et assurer des quotas de ressources Optimisation du scheduling de tâches dans un environnement multi-tenant (processeur Unix ou Jobs Hadoop) … L’ÉVOLUTION DES OS ET DES MIDDLEWARES Non-blocking I/O, Node.JS : concurrence au niveau des I/O GC et ses limites … L’ÉVOLUTION DES DES MÉTHODOLOGIES Les 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 à ce User Group ? ET VOUS ? 42

×