Téléchargé 20 fois
Diagnostic performances
- 1. Diagnostic performance Claude Falguière Geneva JUG le 12 Octobre 2011 1 jeudi 13 octobre 2011
- 2. Copyright notice http://creativecommons.org/licenses/by/3.0/ Vous êtes libre de : Reproduire, distribuer et communiquer cette création au public Modifier 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. 2 jeudi 13 octobre 2011
- 3. Claude Falguière @cfalguiere Technique 3 jeudi 13 octobre 2011
- 4.
- 5. Faux ami 1 La dream Team X est performant Y est performant Z est performant => Mon système est performant 5 jeudi 13 octobre 2011
- 6. Sprint ou marathon ? 6 jeudi 13 octobre 2011
- 7. Bus RATP Vitesse ou charge ? Modèle Fiat 500 Modèle Simlocker 7 jeudi 13 octobre 2011
- 8. Faux ami 2 C’est du bon sens ! 8 jeudi 13 octobre 2011
- 9. User expe!ence 9 jeudi 13 octobre 2011
- 10. Subjectif Complexité supposée Ordre d'affichage Stabilité 10 jeudi 13 octobre 2011
- 11. Logique mais souvent Nombreux composants Interactions complexes Caches Contre-intuitif Mécanismes correctifs 11 jeudi 13 octobre 2011
- 12. Faux ami 3 Avec le cloud fini les problèmes 12 jeudi 13 octobre 2011
- 13. Essentiellement du scaleout Dʼautres problèmes liés à la mutualisation (latence I/O) Coût de la montée en charge 13 jeudi 13 octobre 2011
- 14. S(t)imuler 14 jeudi 13 octobre 2011
- 15.
- 16. Quels vont faire les utilisateurs en production ? 16 jeudi 13 octobre 2011
- 17. Les volumétries ? Les dimensionnements ? 17 jeudi 13 octobre 2011
- 18. Les risques àvérifier ? Les critères à mesurer ? 18 jeudi 13 octobre 2011
- 19. Qui ? Quoi? Où ? Quand ? Combien ? Comment ? Pourquoi ? 19 jeudi 13 octobre 2011
- 20. Qui ? 20 jeudi 13 octobre 2011
- 21. Qui ? Quoi? Consultations Paie Recherche complexe 21 jeudi 13 octobre 2011
- 22. Qui ? Quoi? 22 jeudi 13 octobre 2011
- 23. Combien ? Quand? Quelle heure ? Quel jour ? Pics 23 jeudi 13 octobre 2011
- 24. Pourquoi ? Les enjeux Les coûts 24 jeudi 13 octobre 2011
- 25. STRATEGIE DE TEST POURQUOI ? Que veut on évaluer ? Quels sont les enjeux ? QUOI ? COMBIEN ? Combien d 'utilisateurs ? Combien de temps ? Quel pro l de charge ? COMMENT ? Environnement requis ? Jeux de données? 25 jeudi 13 octobre 2011
- 26. Pourquoi ? Temps de réponse et Disponibilité, Stabilité GALERIEopWEG Robustesse Vieillissement Résistance à l'effet Twitter Consommation de ressources 26 jeudi 13 octobre 2011 G
- 27. Garbage in Garbage out 27 jeudi 13 octobre 2011
- 28. Garbage In →Garbage Out Biais Martineric Le résultat du test dépend totalement des scénarios définis et de leur implémentation 28 jeudi 13 octobre 2011
- 29. Trouvez des biais Trouvez des biais qui qui rendront le rendront le résultat résultat meilleur plus mauvais 29 jeudi 13 octobre 2011
- 30. Volumétries 30 jeudi 13 octobre 2011
- 31. Structure des données 31 jeudi 13 octobre 2011
- 32. Gestion des erreurs Bref ... pas facile 32 jeudi 13 octobre 2011
- 33. Cumulus 33 jeudi 13 octobre 2011
- 34. DEV OPS 34 jeudi 13 octobre 2011
- 35.
- 36. Si vous avezun marteau tout ressemble à un clou 36 jeudi 13 octobre 2011
- 37. Donʼt shoot inthe dark 37 jeudi 13 octobre 2011
- 38. travailler ensemble ? 38 jeudi 13 octobre 2011
- 39.
- 40.
- 41. Et chez vous? 41 jeudi 13 octobre 2011
- 42. Partager 42 jeudi 13 octobre 2011
- 43.
- 44. Explicitez vos hypothèses et votre démarche 44 jeudi 13 octobre 2011
- 45.
- 46.
- 47.
- 48. LaScène de Crime 48 jeudi 13 octobre 2011
- 49.
- 50.
- 51.
- 52.
- 53.
- 54. Investigations 54 jeudi 13 octobre 2011
- 55. Que fait cesystème ? 55 jeudi 13 octobre 2011
- 56.
- 57. Comment ça marche? 57 jeudi 13 octobre 2011
- 58.
- 59.
- 60.
- 61.
- 62.
- 63. Jusque là tout va bien 63 jeudi 13 octobre 2011
- 64.
- 65.
- 66. Dresser le bilan 66 jeudi 13 octobre 2011
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74. Gagnez du temps 74 jeudi 13 octobre 2011
- 75. Série Chronologique Et sa distribution 75 jeudi 13 octobre 2011
- 76. Quelques mauvais temps isolés Temps très variables Bimodale !? ... 76 jeudi 13 octobre 2011
- 77. Douter 77 jeudi 13 octobre 2011
- 78. Latences 78 jeudi 13 octobre 2011
- 79. Patterns 79 jeudi 13 octobre 2011
- 80.
- 81. La rançon du succès 81 jeudi 13 octobre 2011
- 82.
- 83. - Se produitsous charge - Affecte tous les use cases Confirmation Accroissement de l’usage sur une longue période Trouver les limites atteintes - time outs - ressources saturées 83 jeudi 13 octobre 2011
- 84. Les limites physiques 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 84 jeudi 13 octobre 2011
- 85. Les Quotas ulimit, hyperviseurs, shaping réseau, les licences ... Mutualisation de ressources, Réserver des ressources au système, Priorisation de service, Facturation 85 jeudi 13 octobre 2011
- 86. Les Limites configurables Configuration mémoire de la JVM (-Xmx) Tailles limites de pool Tailles limites de caches Nombre dʼinstances, de connexions ... 86 jeudi 13 octobre 2011
- 87.
- 88.
- 89. - Se produitsous charge - Affecte tous les use cases - Souvent écroulement après un pic de charge Résolution Trouver la bonne configuration - utilisation optimale du CPU et pas plus - vmstat (runnable) 89 jeudi 13 octobre 2011
- 90. Le régime restrictif 90 jeudi 13 octobre 2011
- 91. - Se produitsous charge - Affecte tous les use cases Confirmation Saturation de limites configurées mais pas des limites matérielles Résolution Lever ces limites 91 jeudi 13 octobre 2011
- 92. dimensionnement La limite logicielle est préférable à l’écroulement 92 jeudi 13 octobre 2011
- 93. Comment dimensionner ? 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 93 jeudi 13 octobre 2011
- 94.
- 95.
- 96.
- 97.
- 98.
- 99.
- 100. dimensionnement Tout ce qui rentre doit ressortir … en moyenne Les actifs sont définis par la taille du pool Les files d’attente régulent les variations de débit 100 jeudi 13 octobre 2011
- 101. Cohérence plutôt que Rock StarS 101 jeudi 13 octobre 2011
- 102.
- 103. L' emprunt à durée indéterminée 103 jeudi 13 octobre 2011
- 104.
- 105. - Se produitavec le temps même à faible charge - Affecte tous les use cases - Les indicateurs se dégradent progressivement Résolution 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 105 jeudi 13 octobre 2011
- 106. Mémoire Connexion non rendue au pool Thread bloqué 106 jeudi 13 octobre 2011
- 107. Les pseudo fuites ... aka les caches Evaluer l'utilité : thrashing, jamais relus Utiliser un vrai cache : durée de rétention, recyclage Weak reference, soft reference 107 jeudi 13 octobre 2011
- 108. La voie unique 108 jeudi 13 octobre 2011
- 109.
- 110.
- 111. - Très faibleconsommation de ressources - Temps très longs (time-outs) - Affecte particulièrement certains use cases et à faible charge Confirmation Trouver le lock Provoquer le lock - test à 2 utilisateurs synchronisés → 1 des 2 est deux fois plus long 111 jeudi 13 octobre 2011
- 112. Java → Thread Dump + outil d'analyse (MAT, JCA, HealthCenter, Samourai) Evaluer les portées des synchronized Attention aux variables communes (données et compteurs applicatifs) BD → voir les outils de DBA 112 jeudi 13 octobre 2011
- 113. La chaise musicale 113 jeudi 13 octobre 2011
- 114.
- 115. Utilisation par plusieurs threads de variables de classe non multi-thread safe (formatters) 115 jeudi 13 octobre 2011
- 116. - Erreurs d'incohérence - Affecte plus certains use cases - A faible charge - Instabilité Confirmation Provoquer le problème - test synchronisés → 1 des 2 est en erreur ... si vous avez de la chance 116 jeudi 13 octobre 2011
- 117. Très difficile àidentifier 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 117 jeudi 13 octobre 2011
- 118.
- 119.
- 120. - localisé surun use case - variations dans un use case Préciser le scénario - donnée en cause - volumes / répétition - scénario alternatif 120 jeudi 13 octobre 2011
- 121. Que dis cettebimodale ? 121 jeudi 13 octobre 2011
- 122. Que dis cettebimodale ? Comportement différent selon les Plusieurs cas sous instances le même use case mesuré Lock Cache 122 jeudi 13 octobre 2011
- 123. Patience et longueur de temps ... 123 jeudi 13 octobre 2011
- 124.
- 125. Le processus 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èses Ne pas choisir une vérité trop rapidement Boucler 125 jeudi 13 octobre 2011
- 126. Lorsque vous avezéliminé l'impossible, ce qui reste, si improbable soit-il, est nécessairement la vérité. Arthur Conan Doyle (Le signe des quatre) 126 jeudi 13 octobre 2011
- 127.
- 128. Non contributifs Les erreurs dans les logs (en permanence) Uniquement sur la nouvelle plate-forme Non applicatif Peu d'utilisateurs et de requêtes Exclus la charge Aucun signe de saturation avant le crash Perte du monitoring Réseau ? L'OS est inaccessible Tout marche après redémarrage de l'OS Donc pas coupure réseau Perte du service systématique après 2j ouvrés Vieillissement ? mais pas de symptômes ... Et qui peut bloquer l’accès à l’OS 128 jeudi 13 octobre 2011
- 129. Fuite de connexions LDAP Limite du nombre de connexions réseau autorisées sous Windows Plus d’accès réseau Perte du monitoring L'OS est inaccessible Uniquement sur la nouvelle plate-forme Applicatif L'ancienne plate-forme avait été modifiée 129 jeudi 13 octobre 2011
- 130. Conclusion . 130 jeudi 13 octobre 2011
- 131. Priorités Fonctions Robustesse Stabilité Rapidité 131 jeudi 13 octobre 2011
- 132.
- 133.
- 134.
- 135.