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.