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.