Diagnostic performances
-
Upload
claude-falguiere -
Category
Technology
-
view
1.979 -
download
1
description
Transcript of Diagnostic performances
Diagnostic performance
Claude Falguière
Geneva JUG le 12 Octobre 2011
JUGL Lausanne le 13 Octobre 2011
1
vendredi 14 octobre 2011
Copyright notice
2
Vous êtes libre de :Reproduire, distribuer et communiquer cette création au publicModifier cette création
Selon les conditions suivantes :Paternité. Vous devez citer le nom de l'auteur original de la manière indiquée par l'auteur de l'oeuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d'une manière qui suggérerait qu'ils vous soutiennent ou approuvent votre utilisation de l'oeuvre).
Rien dans ce contrat ne diminue ou ne restreint le droit moral de l'auteur ou des auteurs.
http://creativecommons.org/licenses/by/3.0/
vendredi 14 octobre 2011
5
Faux ami 1La dream Team
X est performantY est performant Z est performant
=> Mon système est performant
vendredi 14 octobre 2011
Contre-intuitif
Nombreux composantsInteractions complexes
Caches
Mécanismes correctifs
11
Logique mais souvent
vendredi 14 octobre 2011
Essentiellement du scale out
Dʼautres problèmes liés à la mutualisation (latence I/O)
Coût de la montée en charge
13
vendredi 14 octobre 2011
25
GALERIEopWEG
GALERIEopWEG
Pourquoi ?
Temps de réponse
etDisponibilité, StabilitéRobustesse VieillissementRésistance à l'effet TwitterConsommation de ressources
vendredi 14 octobre 2011
26
Que veut on évaluer ?Quels sont les enjeux ?
Environnement requis ?Jeux de données?
POURQUOI ?
Combien d 'utilisateurs ?Combien de temps ?Quel pro"l de charge ?
QUOI ? COMBIEN ?
COMMENT ?
STRATEGIE DE TEST
vendredi 14 octobre 2011
28
Le résultat du test dépend totalement
des scénarios définis et de leur implémentation
représentativité
19
vendredi 14 octobre 2011
28
Garbage In → Garbage Out
Le résultat du test dépend totalement
des scénarios définis et de leur implémentation
représentativité
19
vendredi 14 octobre 2011
33
Trouvez des biais qui rendront le résultat meilleur
Trouvez des biais qui rendront le résultat plus mauvais
Le Jeu
vendredi 14 octobre 2011
70
Mesurer
Ce que vous mesurez doit servir
- à bâtir des hypothèses
- à confirmer des hypothèses
Est ce que je passe du temps côté client ou serveur ?
Est ce que le réseau est surutilisé ?
vendredi 14 octobre 2011
85
Toujours vérifier
et prouver vos dires
?test JMeter sur place
débit < 2Mb
MAN 150 Mb
vendredi 14 octobre 2011
- Se produit sous charge- Affecte tous les use cases
Accroissement de l’usage sur une longue période
Trouver les limites atteintes- time outs - ressources saturées
91
Confirmation
vendredi 14 octobre 2011
Memory bound : ressource non partageable→ erreur quand plus de ressources CPU bound : ressource en time sharing→ partage excessif, lenteur
Network bound : ressource en time sharing→ idem + retry et écroulement
Les limites physiques
92
vendredi 14 octobre 2011
ulimit, hyperviseurs, shaping réseau, les licences ...
Les Quotas
93
Mutualisation de ressources, Réserver des ressources au système, Priorisation de service,Facturation
vendredi 14 octobre 2011
Les Limites configurables
Configuration mémoire de la JVM (-Xmx)Tailles limites de poolTailles limites de cachesNombre dʼinstances, de connexions ...
94
vendredi 14 octobre 2011
- Se produit sous charge- Affecte tous les use cases- Souvent écroulement après un pic de charge
Trouver la bonne configuration- utilisation optimale du CPU et pas plus- vmstat (runnable)
97
Résolution
vendredi 14 octobre 2011
- Se produit sous charge- Affecte tous les use cases
Saturation de limites configurées mais pas des limites matérielles
99
Confirmation
Résolution Lever ces limites
vendredi 14 octobre 2011
101
Dimensionnement par tests de charge- respecter le modèle de charge de l’utilisateur
Influence de la vitesse des utilisateurs- attentes sur le serveur Web ou le container Web
Influence des jeux de données- attentes de la base de données
Comment dimensionner ?
vendredi 14 octobre 2011
Tout ce qui rentre doit ressortir … en moyenne
Le nombre d’actifs est défini par la taille du pool Les files d’attente régulent les variations de débit
108
dimensionnement
vendredi 14 octobre 2011
- Se produit avec le temps même à faible charge- Affecte tous les use cases- Les indicateurs se dégradent progressivement
Trouver la fuite ...
- Tester les use case isolément, la fuite est souvent liée à un scénario particulier- Certains outils d’introspection détectent les fuites de connexion sur les pools
113
Résolution
vendredi 14 octobre 2011
Les pseudo fuites ... aka les caches
Evaluer l'utilité : thrashing, jamais relus
Weak reference, soft reference
Utiliser un vrai cache : durée de rétention, recyclage
115
vendredi 14 octobre 2011
- Très faible consommation de ressources- Temps très longs (time-outs)- Affecte particulièrement certains use cases et à faible charge
Trouver le lockProvoquer le lock- test à 2 utilisateurs synchronisés → 1 des 2 est deux fois plus long
119
Confirmation
vendredi 14 octobre 2011
Java→ Thread Dump + outil d'analyse
(MAT, JCA, HealthCenter, Samourai)
Evaluer les portées des synchronizedAttention aux variables communes
(données et compteurs applicatifs)
BD→ voir les outils de DBA
120
vendredi 14 octobre 2011
Utilisation par plusieurs threads de variables de classe non multi-thread safe(formatters)
123
vendredi 14 octobre 2011
- Erreurs d'incohérence- Affecte plus certains use cases- A faible charge- Instabilité
Provoquer le problème - test synchronisés → 1 des 2 est en erreur ... si vous avez de la chance
124
Confirmation
vendredi 14 octobre 2011
Causes courantes :- Optimisations sauvage des synchronized pour
régler des problèmes de performance- Caches et compteurs applicatifs mal gérés- Formatters
Solutions possibles :→ Thread Local, synchronized, volatile
Très difficile à identifier
125
vendredi 14 octobre 2011
- localisé sur un use case- variations dans un use case
Préciser le scénario - donnée en cause- volumes / répétition- scénario alternatif
128
vendredi 14 octobre 2011
Comportement différent selon les instances
Plusieurs cas sous le même use case mesuré
Lock
Cache
Que dis cette bimodale ?
130
vendredi 14 octobre 2011
Dresser le bilan → Comprendre où ça se passe à peu près
Mesurer ce qui permet - de choisir un pattern- de comprendre la cause
Eliminer des hypothèsesNe pas choisir une vérité trop rapidement
Boucler
Le processus
133
vendredi 14 octobre 2011
137
Surveiller
Monitorerautodiagnosticjournaux,alertes
Anticiper≠ planifier
vendredi 14 octobre 2011