![5
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. »
Bienvenue au Performance User Group Maroc
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.](https://image.slidesharecdn.com/nchenbiitjm7jtjyxo9q-signature-513cf6aec3bffe005dc9eaedf88a1e1a0c770523ad2605f984fa4c6183b0b3b1-poli-150508110646-lva1-app6892/75/Session-2-du-workshop-sur-la-performance-en-environnement-de-production-5-2048.jpg)
Téléchargé parDEFO KUATE Landry
Session #2 du workshop sur la performance en environnement de production
La présentation aborde la performance des applications en production, en mettant l'accent sur la méthodologie de la performance et les solutions de supervision. Elle explique les différents types de tests de performance, leur objectif, et l'importance de mesurer la performance tout au long du processus de développement. Le Performance User Group Morocco est également introduit comme un lieu d'échanges pour optimiser les performances informatiques.
Contenu connexe
![[FR] Récit utilisateur inudstrie pharmaceutique](https://cdn.slidesharecdn.com/ss_thumbnails/press-151217132550-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)
Session #2 du workshop sur la performance en environnement de production
- 1. 1 Tél : +212537 778 843 www.octo.com © OCTO 2015 49 rue Jabal Tazzeka 10000 Agdal, Rabat - MAROC 07/05/2015 La performance des applications en production
- 2. 2 18:30 : Méthodologiede la performance (30min) Landry DEFO KUATE (OCTO Technologies) 19:00 : Présentation technique des solutions de supervision (60min) Mohamed RAHOU (adhoc-international) 20:00 : CA Technologies : outillage et produits M’Hamed ARAHOU (CA Technology) Contenu de la soirée
- 3. 3 Qui sommes nous? Landry DEFO KUATE Architecte @OCTO Co-organisateur « Perf-UG Maroc » @defolandry
- 4. 4 Introduction au PerformanceUser Groupe Morocco
- 5. 5 Wikipedia « [Les testsde 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. » Bienvenue au Performance User Group Maroc 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.
- 6. 6 Notre vision ? Source: www.arthursclipart.org Les performances d’un système sont une spécification fonctionnelle implicite du système
- 7. 7 Notre vision ? Source: Les géants du Web La mesure de performance doit être au cœur du processus de développement informatique
- 8. 8 Notre vision ? Source: Les géants du Web Nous voulons des systèmes performants
- 9. 9 Notre devise ! 9 LESTEMPS DE RÉPONSE NOUS DIMINUERONS LES DÉBITS NOUS AUGMENTERONS LES RESSOURCES NOUS ÉPARGNERONS LA HAUTE DISPONIBILITÉ NOUS PRÉCONISERONS
- 10. 10 Notre mission Source :perfUgMa #2 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
- 11. 11 Notre mission 11 Faciliter ladiffusion des derniers outils et des meilleures techniques pour maîtriser au plus tôt la performance d’un système informatique
- 12. 12 Méthodologie de laperformance
- 13. 13 Activités de l’ingénieuren performance applicative L’audit (statique et dynamique) du code source de l’application : Java, .NET, NodeJS, PHP, SQL, … Les tests de l’application La supervision applicative (Application Performance Management)
- 14. 14 Supervision applicative APM :Application Performance Management
- 15. 15 APM (Application PerformanceManagement) Permet de contrôler la performance des applications métiers et de mettre en avant rapidement d'éventuels problèmes, directement liés aux logiciels, voire même à leur environnement (réseau, système, base de données...) EUM (End User Monitoring) Permet de mesurer la performance d’une application à partir de l’environnement de travail de l’utilisateur final (navigateur, poste de travail, mobile) et non pas à l’entrée du Datacenter seulement Définitions APM & EUM
- 16. 16 Monitoring interne vsMonitoring externe Portée du monitoring classique limité dans le data center Dans le data Center : • Réseau interne • Applications .NET, Java, PHP • Bases de données • Autres serveurs internes Utilisateurs éloignés : • Depuis un navigateur • Depuis le mobile • Application desktop Data centerEnvironnement utilisateur final • Problème de téléchargement des ressources applicatives (Exemple QoS du FAI) • Problèmes d’éxécution de la partie client des applications riches reposant sur HTML5 et Javascript (Exemple : stack AngularJs, GWT) • Erreurs d’éxécution de l’application sur le poste utilisateur (Erreurs Javascript) • Indisponibilité de l’application à cause d’un problème d’accès au réseau interne (Erreurs HTTP 404) • Visibilité complète dans tout le datacenter
- 17. 17 Les types detests en performance
- 18. 18 Les activités del’ingégieur performance 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
- 19. 19 Les différents typesde tests • 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
- 20. 20 Méthodologie pour untest 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 20
- 21. 21 Les tests deperformance 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 Principes d’optimisation logsdes tests de performance L’optimisation de performances se fait en intervenant sur plusieurs niveaux • 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, configuration réseau… Infrastructure
- 23. 23 La mesure estun 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. 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 [email protected] Vous croyez queles technologies changent le monde ? Nous aussi ! Rejoignez-nous !
- 25.
Notes de l'éditeur
- #7 Tout utilisateur de système informatique s’attend à recevoir un système Qui répond de façon stable quelque soit sa charge Qui répondre en un temps cohérent par rapport à l’action qu’il réalise Bref un système performant Les performances d’un système sont une spécification fonctionnelle implicite du système
- #8 Tout développeur ayant mis en production sait apprécier l’effort que cela requiert Les plus expérimentés savent que le problème est rarement là où on le pensait même avec un flair aiguisé
- #10 Dire que c'est un user group dédié à la performance (bien posé le contenu) L’objectif du User Group est d’être dédié à la performance, d’où la devise. Source 1 : http://fr.wikipedia.org/wiki/SIEL_(m%C3%A9tro_de_Paris) Source 2 : http://www.tout-paris.org/transports-commun-paris-nouvel-an-655 Source 3 : http://www.motorevue.com/site/les-freins-carbone-ceramique-et-dmc-44261.html Source 4 : http://www.lexpress.fr/actualites/1/economie/la-sncf-lance-les-festivites-pour-les-30-ans-de-son-joyau-le-tgv_980524.html
- #17 Parler du fait que les problèmes ne sont pas toujours dans le datacenter
- #19 Slide 14 : C'est juste un rappel, passer assez vite
- #20 Slide 13 : Dire que c'est la nomenclature qu'OCTO utilise.
- #24 Slide 17 : Insister, mesurer où est le problème et pas à l'instinct j'essaie d'optimiser. Plus les marteler. La mesure est un point essentiel dans l’optimisation des performances Compteurs de performance, instrumentation du code en seront les principales mises en oeuvre… Il faut utiliser des centiles et non pas des moyennes sinon ça n’est pas pertinents (faire un dessin au tableau) Si les tests de performance sont réalisés sur une infrastructure qui n’est pas l’infrastructure cible, les résultats des tests risquent de ne pas être représentatifs Les jeux de données fournis doivent être représentatifs des données de production pour avoir des résultants pertinents Pour cette proposition nous supposons que l’application est alimentée de façon optimale en dehors du périmètre testé