Cours chapitre9 2012

2 323 vues

Publié le

Cours sur le système d'information en 9 chapitres

Publié dans : Formation
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Cours chapitre9 2012

  1. 1. Théorie et Pratique du Système d’Information Neuvième Chapitre: Performance du SI Janvier-Mars 2012 Ecole Polytechnique Yves Caseau Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 1/28
  2. 2. Plan du Cours – Architecture du Système d’Information Première partie: Modélisation des Performances  Deuxième partie: Résoudre les problèmes de performance  Troisième partie: Performance, SLA et Défaillances  Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 2/28
  3. 3. Première Partie: Modélisation Introduction à la mesure de performance  Un problème multidimensionnel      Pas de mesure sans modèle:     Temps de réponse & Débit CPU & I/O (accès aux data) Services & overhead (protocoles & infrastructure) Débit stationnaire et résistance aux aléas Beaucoup de comportements contre-intuitifs Savoir précisément ce que l’on mesure Réconcilier des mesures « distribuées » Outils    Queing Networks (cf. 1e partie) Tests de performance (cf. 2e partie) Simulation (cf. 3e Partie) II.1 : Processus - Principes Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 3/28
  4. 4. Première Partie: Modélisation Théorie des Files d’Attente  Traitement : débit µ « single station » Loi arrivée Débit = λ 1 File « discipline » m m serveurs  Classification de Kendall: A/B/m – discipline A (loi d’arrivée): M (emoryless) = distribution exponentielle des temps entre deux arrivées (processus de Poisson), D (éterliniste), G(énéral),…  B : loi de services des m serveurs identiques  Discipline: FCFS (le plus commun en IT), LFCS, Priorities, …   Loi de Little  K = λT ou Q = λW (vision système ou file)  Indépendant des lois Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 4/28
  5. 5. Première Partie: Modélisation Quelques Résultats  M/M/1 ρ = λ / µ (taux d’occupation) K=  ρ 1− ρ W= T= M/M/m ρ K = mρ + × Pm 1− ρ  ρ µ × (1 − ρ ) 1/ µ 1− ρ  m −1 (mρ ) (mρ )  π 0 = ∑ k = 0 +  k! m!×(1 − ρ )   k W= 1/ µ × Pm (1 − ρ ) m (mρ ) m Pm = ×π 0 m!×(1 − ρ ) M/G/1 2 ρ2 (1 + cB ) Q= × (1 − ρ ) 2 FW ( x) = 1 − ρ × e − µ (1− ρ ) x ρ2 Q M / M /1 = (1 − ρ ) Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) ρ2 Q M / D /1 = 2(1 − ρ ) 5/28 −1
  6. 6. Première Partie: Modélisation Réseaux de Files d’Attentes  Réseau de Jackson  Matrice de connexion 1 1 m m 1 m 1 m  Théorème de Jackson  Sous les bonnes conditions (λ <µ .m ) i i i Le réseau peut être vu comme un « produit »  π(k ,..,k ) = π (k ) x … x π (k ) 1 n 1 n   Analyse ou Simulation ? De nombreux cas sont réductibles à l’analyse (utile pour valider)  Mais les « subtilités » nécessitent la simulation (cf. 3e partie)  Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 6/28
  7. 7. Première Partie: Modélisation Exemples - Simulés  Comparons (débits/durées ajustées):  Temps SLA (< 40s)   P1 P2 P3 P4 P5   P1 P2 P3 P4 P5 r=40 40,6 30,6 30,8 30,5 35,6 r=60 49 32,2 30,4 31,4 38,3 r=75% 72 36 30,5 34,1 44,8 r=80% 93 41 31,7 38,5 55,2 Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) r=40% r=60% r=75% r =80% r=90% chaos burst quick 86% 75% 55% 42% 26% 47% 22% 11% 99% 99% 95% 86% 68% 58% 27% 25% 99% 99% 99% 99% 98% 91% 52% 34% 99% 99% 99% 94% 76% 65% 40% 25% 99% 95% 86% 71% 47% 48% 42% 82% r=90% 158 53 35 50 74 chaos 112 38 209 100 204 burst 401 373 216 327 201 quick 2040 840 660 900 44 7/28
  8. 8. Première Partie: Modélisation Modèle de Performance - Serveur Threads / processeurs 1 m Accueil Load balancer m= 1 ou 2 1  I/O Selon architecture Retour résultats BD m=1,2 … Il faut identifier le sous-système « goulot d’étranglement » (selon la problématique)      Capacité à traiter le flux d’entrée Capacité de l’ensemble des processeurs Capacité I/O (par processeur) Capacité I/O des BD Capacité de l’infra de transport Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 8/28
  9. 9. Première Partie: Modélisation Performance du SI 3 modes opératoire, 3 problématiques :  Batch    Synchrone     Avant tout un problème d’ordonnancement Peut être complexe (partage de ressource) mais seulement compliqué en pratique  Le couplage fort permet de se concentrer sur «le maillon faible », sur lequel s’aligne les autres Chaque ST est caractérisé par sa dimension critique (cf. slide précédent)  SLA produit : nombre de sessions simultanées x temps latence garanti Exige un réglage soigneux pour les ST, mais plus simple au niveau global Asynchrone   Le plus complexe car global: il ne suffit pas de régler la performance des composants, il faut s’assurer que le réseau de files d’attentes associé fonctionne avec le SLA souhaité 3 passes:  Vérifier les capacités en « bande passante » (débit)  Vérifier les temps de parcours  Penser aux cas d’erreur (surtout si rejeu) – cf. 3e partie Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 9/28
  10. 10. Première Partie: Modélisation 8 idées fausses sur l’informatique distribuée (I) P. Deutch + Cf. http://blogs.sun.com/jag/resource/Fallacies.html 1. Le réseau est fiable   1. La latence est nulle    1. Incidents matériel, logiciels, humains Impose un surcoût de communication + infra (ex: secure messaging) Une des principales causes des problèmes de performance des applications distribuées  Exemple : Rich client (AJAX) Fonction de la distance, du nombre de routeurs, du protocole … Valeurs typiques: 1ms sur un LAN, 40ms sur un WAN (10kms) La bande passante est infinie    La capacité augmente rapidement (contrairement à la latence)… mais les usages également ! Attention au rejeu dans un contexte élargi (Wan, …) Faire un « capacity planning » des flux Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 10/28
  11. 11. Première Partie: Modélisation 8 idées fausses sur l’informatique distribuée (II) 4. Le réseau est sûr  4. La topologie du réseau ne change pas   4. Administrateurs multiple => faciliter le déploiement, s’adapter facilement aux contraintes Le coût du transport est nul   4. Utiliser des infrastructures d’intégration pour découpler logique/physique Ex: Pas d’adresses IP en dur … utiliser des DNS Il existe un administrateur unique  4. Authentifier, Cloisonner ( isoler), tracer, surveiller, outiller (pare-feux, antivirus, …) Transport => « marshalling/ unmarshalling » + latence Le coût du réseau est une part significative du TCO Le réseau est homogène (J. Goesling)  s’appuyer sur des protocoles interopérables et transportables Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 11/28
  12. 12. Deuxième partie Modélisation des Performances  Résoudre les Problèmes de Performance  Performances, SLA et Défaillances  Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 12/28
  13. 13. Deuxième Partie: Résoudre les Problèmes Synthèse des attentes Administration Suivi Métiers Utilisateurs futurs Attente: capacity planning Attente: monitoring & supervision Attente: BAM Système d’information Utilisateurs exceptionnels Serveurs Présentation Attente: capacité à monter en charge Processflows Serveurs Applications Utilisateurs réguliers Attente: robustesse, disponibilité, Temps de réponse Référentiels Mesurer, Comprendre  Dimensionner, Tester, Valider  « Réparer » les problèmes de perfs  Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 13/28
  14. 14. Deuxième Partie: Résoudre les Problèmes Antipatterns Traits architecturaux souvent corrélés avec des performances décevantes  « Le syndrome de la cascade »  Chaine d’appel trop longue, abus d’encapsulation, trop d’appels distants … -> Attention à ne pas « tout » distribuer  « Le syndrome de la mitrailleuse à requêtes »  Multiplication des requêtes (avec overhead) – granularité trop fine -> gérer des groupes d’objets, procédure stockées, …  « Le syndrome de la requête mammouth »  Volume d’information trop important (souvent un contexte) -> au choix : fragmentation (contexte) ou approche paresseuse (réferentiel distribué – cf. chapitre 7)  « Le syndrome du goulot d’étranglement »  Bonne performances unitaires mais mauvaises performances après l’intégration -> c’est ici que l’approche « file d’attente » est essentielle Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 14/28
  15. 15. Deuxième Partie: Résoudre les Problèmes Exemples (vécus  )  Traitement des cas d’exception    Bottleneck sur la gestion mémoire    Le traitement des cas d’exception est souvent plus long  Pour des raisons fonctionnelles  Pour des raisons technique (écrire dans un log) L’augmentation brutale des cas d’exception peut créer un ralentissement  Ex: jeu de données corrompues Exemple d’un système non scalable = ajouter des CPU n’améliore pas les performances La gestion des données fait de l’I/O un bottleneck « Load balancer » non scalable     Souvent un composant central et unique De temps en temps, représente une partie significative du temps de traitement Facilement paralélisable d’un point de vue fonctionnel (!) Bonne pratique du point de vue de la fiabilité (cf. chapitre 8) Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 15/28
  16. 16. Deuxième Partie: Résoudre les Problèmes Optimisation des Bases de Données  C’est un métier ! Trouvez un DBA expert    Les performances commencent avec la bonne architecture de données (cf. chapitre 7)     Certains problèmes se résolvent par la distribution physique (gestion de caches) La répartition doit être laissée au SGBD Ne pas mélanger lecture synchrone « haute performance » (contraintes de latences) avec des écritures asynchones. Les requêtes BD se prêtent bien aux tests de performances    Ex: optimisation des requêtes SQL Les temps de traitements sont assez stables Attention aux problèmes de montée en charge (débit) Utilisation des procédures stockées  Eviter des transferts inutiles, le serveur BD est optimisé pour les sélections et manipulations Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 16/28
  17. 17. Deuxième Partie: Résoudre les Problèmes Optimisation des Flux XML  DOM vs. SAX    Ne pas construire un message entier en mémoire pour extraire deux nombres  ! DOM: construit (et alloue) un qui représente l’arbre SAX: génère des événements pendant le « parsing » qui peuvent être filtrés.  Variantes: XML Pull parsing -> StAX (streaming API) Bien utilisé, le surcoût XML est acceptable dans 99% des cas.  Ne pas écrire son propre parseur      Utiliser des outils Maitriser XSLT, Xquery XML store : une technologie à utiliser  Parseur validant : au moment des tests  Mais pas de XML sans schémas Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 17/28
  18. 18. Deuxième Partie: Résoudre les Problèmes Performances des Moteurs d’Orchestration Souvent un « bottleneck » - les implémentation distribuées sont rares (mais existent )  Mode d’exécution: « secure » (avec points de reprise) => ralenti par l’I/O (besoin d’écrire sur disque)    Scalabilité « mesurée » cf.courbe ORACLE … pas de surprise  Modèle simple 5 étages: Performance Queue / listener / moteur / invocation/ sauvegarde  Cf. Amdhal’s law Throughput # de processus Attention à la granularité (mitrailleuse)  Le temps de sauvegarde est lié aux volumes de données manipulées dans les appels de services  Cf. Chapitre 7: un processus est une transaction longue   Ne pas oublier les cas d’erreur/compensation Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 18/28
  19. 19. Deuxième Partie: Résoudre les Problèmes Performances des Serveurs d’Application  Un composant qui se généralise pour construire des ST     Conteneur Web (interface http) Conteneur de composants Services intégration Leviers de performance:    Durée des traitements Ne pas utiliser le serveur d’application pour des traitements complexes (c’est un middleware) Gestion de la mémoire Même remarque pour la taille des données manipulées (cf. processflow) Paramétrage des applications  Les serveurs d’applications ont besoin de « tuning » (paramètres) Intégration fréquente (et logique) avec moteur d’orchestration  Ici aussi, l’expérience est clé   Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 19/28
  20. 20. Deuxième Partie: Résoudre les Problèmes Tests de Performance  Deux objectifs liés    Scénarios de test    Prend du temps à réaliser (injecteurs, simulation du comportement des utilisateurs) Si possible, injecter des données réelles (pour augmenter la couverture) Exécution   Valider les exigences du contrat de services Régler (tuning) les paramètres (ex: nombre de processus, mémoire allouée, etc.) Utiliser des outils … car une partie importante de la valeur est dans l’analyse (au-delà du test binaire « ça marche ») Souvent sacrifié faute de temps lors du lancement …   … à faire en post-production !! Car dans 90% des cas, les problèmes arrivent ensuite  Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 20/28
  21. 21. Deuxième Partie: Résoudre les Problèmes Capacity Planning  Suivre, modéliser et prévoir les performances/capacités     Rôle d’une équipe indépendante    Suppose un dialogue métier pour connaitre les prévisions d’usage Suppose un modèle (simple) de l’architecture et ses performance, obtenue le plus souvent de façon statistique  Le point clé est de trouver les facteurs dimensionnant Suppose un monitoring des performance qui est capable de fournir les données Demande du recul (analyse) et une neutralité (pour envisager les problèmes) Capable de modéliser (file d’attentes ) voire de simuler … Différents objectifs    Prévenir les problèmes Optimiser les ressources … ou les performance (cf. 3e partie) Ne pas sous-estimer les capacités à optimiser  Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 21/28
  22. 22. Troisième Partie    Modélisation des Performances Résoudre les Problèmes de Performance Performances, SLA et Défaillances Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 22/28
  23. 23. Troisième Partie: Performance, SLA et défaillance Performance, Symptôme et Diagnostic  Deux possibilités de diagnostic en cas de mauvaises performances:    Plus un système est robuste, moins il est facile de détecter les défaillances (par définition ) …   Redondance, découplage asynchrone, processus de rattrapage, routage alternatif, … Mais les défaillance se traduisent par des problèmes de perf:   mauvaise architecture ou d’un sous-dimensionnement Symptôme d’une défaillance qui commence à s’exprimer Surcharge d’un membre, file qui s’engorge, dégradation des temps unitaires … Le monitoring des performance est une part doublement cruciale du maintien de la qualité (SLA & prévention)  Attention: lorsqu’un tel système (robuste) s’arrête, il est plus difficile de le redémarrer (back-log) Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 23/28
  24. 24. Troisième Partie: Performance, SLA et défaillance OAI : l’Optimisation de la QoS des processus  Soit: (1) un ensemble de composants qui exécutent des processus Help Customer Base PFS Provisioning CRM adapter Bus Processflow Engine  (2) Un contrat de service 20 clients par Heure en moins De 2 minutes  (3) des aléas …. •Pics d’activité •Pannes •Autres processus Question: peut-on automatiser le pilotage des processus pour assurer que les processus prioritaires sont traités en priorité ? Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) IV : Pilotage par les Processus 24/28
  25. 25. Troisième Partie: Performance, SLA et défaillance OAI: Difficultés  Diagnostic     Dimensionnement    Gestion de flux sous priorités : un problème combinatoire Gestion des aléas: un problème stochastique encore plus complexe Planification    Temps réel (fil de l’eau) vs. Analyse de logs Absorption de pics => détecte les problèmes trop tard Capacité d’introspection à chaud Mélange planifié / fil de l’eau ! : asynchrone => accepte les pics de charge mais la QoS se dégrade => besoin de SLA explicites Reprise sur incident   À chaud -> contrainte performance Ingénierie de ré-injection de messages (outils) Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) IV : Pilotage par les Processus 25/28
  26. 26. Troisième Partie: Performance, SLA et défaillance OAI: Modèle 1. n « threads » avec loi de service identique Modèle classique d’un ST – cf 1e partie adaptateur File d’attente … Politique Sélection ST1 2. 3. Infrastructure de transport de message monitor STn BUS Processflow « fault-tolerant » (avec rejeu) File d’attente Rejeu 4. Option: Adaptateur piloté Définition processus Mesures Stats Synchronisation objets métiers entrelacée (cf. Chapitre 6) Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 26/28
  27. 27. OAI: Quelle “infrastructure adaptative” ?  Deux approches étudiée pour piloter la qualité de service:    Régles de priorité pour la pile de messages: modifier l’ordre de sélection associés aux queues des ST Régles de contrôle de flot : réduire les flux des process de faible priorité Message Queue Policies:     FCFS (first come first served)  Méthode par défaut des middleware – respecte les contraintes temporelles  Attention: s’appuyer sur l’ordre de distribution rend la répartition difficile LCFS (last come first serve)  Bonne stratégie pour gérer les “backlogs” (situation de crise) “SLA routing”  Prévision des temps de service à partir du SLA (génère des temps de passage) Combination with priorities  Les messages associés à des processus de priorité supérieure sont traités en premier Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 27/28 II: Self-Adaptive Middleware
  28. 28. Résultats de la simulation  La gestion des priorités est une bonne approche. Une infrastructure qui gère les priorités permet de tenir les SLAs prioritaires plus longtemps.    Les approches de contrôle de flux sont difficile à régler et peu efficace   FCFS n’est pas une bonne stratégie par défaut. LCFS est plus robuste. La meilleure solution est de combiner les priorités et l’ordonnancement à partir des temps de passages attendus (SLA routing)  dommage, c’était l’approche la plus simple pour une DSI Impact de la complexité des processus   Il est plus facile de gérer des charges irrégulières avec des processus courts A l’inverse, des processus longs amortissent les “salves (bursts)” Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 28/28

×