utc apm human talks compiegne
TRANSCRIPT
Application Performance Management :Kézako ?
Human Talk Compiègne – 14 avril 2015 @UTC
Plan
Introduction
1. Le problème
2. La solution
3. Instrumentation et monitoring
4. Qualification de performance
5. Incidents de production et gestion de crise
Conclusion
Introduction
Présentateur : Arthur Van Ceulen
Ingénieur UTC par l’apprentissage (2015)
Consultant Performance et Architecture du SI
Entreprise : leanovia Consulting
Cabinet de conseil spécialiste de la performance
Quinzaine de consultants
Bureaux à Paris et filiale à Casablanca
1,1 - 1,3M d’euros de CA annuel
Clients
1. Le problème
La performance d’une application répond au besoin de :
Disponibilité : peu d’erreurs
Rapidité : temps de réponse utilisateur
Scalabilité : soutenir un service constant soustoutes conditions de charge
Un SLA est la formalisation de ce besoin.
2. La solution
Des infrastructures maîtrisées (middlewares)
Des architectures applicatives adaptées (BDD, UML orienté objet, jobs…)
Des optimisations spécifiques
Application Performance Management Tester et mesurer le système end-to-end
Analyser, trouver les solutions
Intégration continue
Monitorer, alerter et réagir en production
3.1 Monitoring et instrumentation
Router Firewall Switch Load Balancer
FRONT END
Web Servers
Portal
USER
WAN/WWW
End User
BACKEND
DatabasesOracle, SQL
3rd Party Applicati
onsDatabase
SAP
Web Services
Payment Processor
External Systems
AppServer
MIDDLEWARE
Mainframe
3.2 Exemple de dashboard
Caractériser le problème
Isoler la couche ou le composant
Analyser le problème et proposer une solution
Corriger, tester et mettre en production
Problème périodique
Mauvaise utilisation d’un
backend
Code
Application
- Tous les jours entre 10h et 12h
- Une dizaine de crash mémoire
- Saturation mémoire des JVM
- Très forte consommation CPU
- L’augmentation de la mémoire n’a pas permis de résoudre l’anomalie
- L’augmentation du nombre d’instance non plus
- L’augmentation CPU non plus
- La très forte consommation CPU est due à une forte activité du GC qui n’arrivait pas à libérer la mémoire
- L’insuffisance de la capacité est à exclure car même avec 8Go / jvm, le système finit par s’écrouler
- La fuite mémoire est à exclure également car l’augmentation de la consommation mémoire n’est pas progressive
- En analysant les graphes Introscope des métriques Concurrence et ResultSetProcessingTime, on note que :
- Les données saturant la mémoire correspondent à des entités chargées par la même requêtes SQL
- Cette requêtes SQL est générée par le mappingHibernate
- Reproduction de l’anomalie en environnement de test
- Revue du mapping many2 many entre 2 entités
- Utilisation du fetchgroup
- Correction et validation- Mise en production et
surveillance durant une semaine
- 0 crash pendant toute la durée de l’observation sans redémarrage des instances
3.3 Exemple de diagnostic
Lancement
Réunion de lancement et
workshops
Analyse des exigences et plan projet
Élaboration du plan de test
Analyse de l’environnement
de test
Bilan
Élaboration des préconisations
Synthèse de la métrologie
Présentation du bilan
Rapport et prise en compte des
remarques
Réalisation
Préparation• Scripting• Instrumentation• Validation du JDD• Tirs de recette• Modélisation de charge
Analyse• Vérification des SLA• Diagnostic• Tuning• Commination des
anomalies bloquantes
Exécution• Monitoring• Collecte des
métriques et des logs• Analyse à chaud• CR journalier
4. Qualification de performance
5. Incidents en production
Conclusion
La performance est un problème complexe en lien avec toutes les expertises de l’IT.
Être sensibilisé à la performance est un atout essentiel à tout décideur IT.
Un écosystème d’outils et de solutions industrielles en expansion.
leanovia recrute des ingénieurs !
Des consultants juniors…
en contrat d’apprentissage d’un an à 3 ans, ou
en stage de fin d’études.
Et des consultants confirmés ou seniors.
Fiche d’information pour les apprentis ou stagiaires.