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 sous
toutes 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
Databases
Oracle, SQL
3rd Party
Applicati
ons
Database
SAP
Web
Services
Payment
Processor
External
Systems
App
Server
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 ResultSetProcessing
Time, 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 mapping
Hibernate
- Reproduction de
l’anomalie en
environnement de test
- Revue du mapping many
2 many entre 2 entités
- Utilisation du fetch
group
- 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.

Utc apm human talks compiegne

  • 1.
    Application Performance Management: Kézako ? Human Talk Compiègne – 14 avril 2015 @UTC
  • 2.
    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
  • 3.
    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
  • 4.
  • 5.
    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 sous toutes conditions de charge  Un SLA est la formalisation de ce besoin.
  • 6.
    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
  • 7.
    3.1 Monitoring etinstrumentation Router Firewall Switch Load Balancer FRONT END Web Servers Portal USER WAN/ WWW End User BACKEND Databases Oracle, SQL 3rd Party Applicati ons Database SAP Web Services Payment Processor External Systems App Server MIDDLEWARE Mainframe
  • 8.
    3.2 Exemple dedashboard
  • 9.
    Caractériser le problème Isoler lacouche 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 ResultSetProcessing Time, 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 mapping Hibernate - Reproduction de l’anomalie en environnement de test - Revue du mapping many 2 many entre 2 entités - Utilisation du fetch group - 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
  • 10.
    Lancement Réunion de lancement et workshops Analysedes 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
  • 11.
    5. Incidents enproduction
  • 12.
    Conclusion  La performanceest 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.
  • 13.
    leanovia recrute desingé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.