Cours chapitre9 2012

1,921 views
1,729 views

Published on

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

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,921
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
190
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Les performances se mesurent classiquement selon deux axes : la capacité à traiter un volume important de transitions et le temps de réponse (la latence). Dans une utilisation sur un bus asynchrone, on se concentre plus sur le premier point, car la latence est liée au throughput (cf. Queueing formulas).
    En revanche, pour la synchronisation de services synchrones, la latence est vraiment un point important, en particulier si le protocole de gestion des erreurs implique une augmentation du nombre d’allers-retours entre le moteur de processus et les composants.
  • Faire un dessin avec une grosse queue et une petite pour le meme débit 7/1 vs 1/1
    Point clé: loi fondamentale – vrai dans toutes les situations – mais ne décrit pas l’état (qui est fortement lié à la distribution)
    Montrer que T (traitement) = W (attente) + 1/lambda (processing)
  • La dernière ligne est le point clé.
    Lambda = taux d’arrivée
    Mu = taux de traitement
    M = poisson
    K = nombre de jobs en attente
    CB = coefficient de variation = écart-type sur moyenne
    Fw = distribution des temps d’attente
    Pi_k = proba d’avoir k jobs dans le système
    Pi_k = pi0(m ro) ^k / k! si k < m et pi0 ro^k m^m / m! sinon
    Figure 6.4 shows that the mean number of jobs increases with the number of serverm (constant utilization) but mean Q decreases
    Q = queue length
    cd. QN and Mark. Chain, p219
  • Cf Chapitre 15 de « Performance by design » : Non-product form queueing models
    -> resource contention, blocking, forking & synchronization, priority scheduling 
    Idée clé du lean – 6 sigma : la variation de mu d’un système devient la variation lambda du second
  • Cf OAI experiments
    1er tableau = respect SLA
    2e = temps de traversée moyen
    Chaos = augmentation de la déviation
    Burst = 1h d’augmentation de traffic
    Quick = short burst
    SLA = fonction de la déviation ! Montre que plus de serveurs réduisent la stdev 
  • Slide clé
    IO est soucvent un bottleneck car pas toujours parallèle (locks)
    Liens avec archi de données !
  • Comme nous l’avons dit précédemment, l’utilisation combinée de communication synchrones et asynchrones est obligatoire dans la pratique, mais il faut alors insister sur deux objectifs :
    partager les services, et éviter de construire un double jeu d’interfaces, un pour les appels synchrones et un pour les appels asynchrones.
    construire un modèle commun de performance, puisque la plupart des composants vont rendre des services dans les deux modes synchrones et asynchrones à partir des mêmes cycles CPU.
    L’expérience de Bouygues Telecom est que ces deux objectifs, et en particulier le premier, sont difficiles. Nous allons y revenir dans le chapitre 7 en proposant un modèle unifié pour l’intégration d’applications.
  • Exemples tirés de mon expérience Bytel
  • Cf. p.48 de « Performance by Design » : # of thread du DBMS = compromis entre software contention (beaucoup de threads) et physical contention (peu de threads)
  • XML Pull Parsing is touted as a high performance alternative to DOM for XML parsing that is easier to use than SAX. SAX is push API and enjoys wide spread adoption virtually removing any other push API in Java. This is not the case for pull parsing where many APIs were created and only recently JSR 172 StAX (Streaming API for XML) promises to provide one standard. However even if StAX will become the API for pull parsing it is important to understand choices made in API, especially dual nature of StAX API. Additionally when choosing XML processing API between tree oriented (such as DOM), streaming push (SAX) and pull (StAX) it is crucial to understand limitations of each approach and in particular trade-off between easiness of use and memory utilization/performance.
    StAX: https://sjsxp.dev.java.net/
    The Streaming API for XML (StAX) is the new generation of XML APIs in Java. StAX is based on the so-called pull model in which an application queries the parser for the next parsing event, but never surrenders control to the parser during the process. Stated differently, StAX essentially turns the SAX processing model upside down. Instead of the parser controlling the application's flow, and the application reacting to parsing events, it is the application that controls the flow by pulling events from the parser.
    This parsing model has several advantages over SAX. First, it often makes the application logic easier to understand given that it is the application and not the parser that is in control of the process (stated differently, the application does not get "pushed around" :). Second, if implemented correctly, there are a number of new optimizations that are possible when the application does not need to process the entire infoset. In particular, it is possible to lazily wait until the application requests a certain infoset item before it is actually constructed (a good example of this is lazy creation of Java strings).
    Both StAX and SAX work in streaming fashion and allow only forward reading. However, the StAX model gives the application a lot more control: for example, applications have the option of pausing and resuming the parsing process, skipping over unneeded content, etc. For further information please refer to the Java Web Services Tutorial.
    The StAX cursor model (XMLStreamReader) is the most efficient way to parse XML since it provide a natural interface by which the parser can compute values lazily. SJSXP takes full advantage of this by delaying the creation of certain objects until they are needed. SJSXP's XML token scanner is based on Xerces 2 but has been modified to accomodate the new pull model. The result is an implementation that is fully complaint with the XML specifications while at the same time offering very good performance.
  • Amdhal’s law – cf. Guerilla warfare
    S(p) = p / (1 + s(p – 1)) s = serial fraction
    S(p) = coefficient de speed-up avec p processeur
    S = % du travail non parralélisable
    Ex: 10% => asymptote = 10
    Cf. Performance by Design p. 16 = trashing = la courbe decroit si le load est trop important
  • Wikipedia:
    Un serveur d'applications est un serveur qui centralise toutes les applications utilisées par les postes clients. Les applications sont chargées sur le serveur tandis que leurs IHM (Interfaces Hommes-Machines) sont distribuées sur les postes clients. Dans une infrastructure N-tiers régulière, on peut déployer plusieurs serveurs d'applications, que ce soit pour répartir la charge lorsque le nombre élevé de postes clients est une exigence critique, ou que ce soit simplement pour les redonder lorsque leur disponibilité est aussi une exigence critique (les dispositifs de redondance peuvent être plus ou moins sophistiqués suivant qu'ils garantissent des temps de reprise en secours plus ou moins brefs, i.e. une disponibilité de service plus ou moins continue).
    Le serveur d'applications agit comme tout serveur, il prend la requête du poste client, exécute les traitements à effectuer et retourne le résultat au poste client. Ce faisant, il assure la persistance des données au cours et entre plusieurs transactions d'un même poste client, ainsi que la persistance des données partagées et les arbitrages d'accès entre plusieurs postes clients concurrents.
    Les serveurs d'applications sont des logiciels occupant la couche centrale dans une architecture multicouche, qu'elle soit classique 3-tiers (postes clients, serveur de données, serveur d'applications) ou étendue (n-tiers) lorsqu'elle intègre des serveurs d'acquisition (données de terrain, données de process, de back-office, etc.) et/ou des serveurs d'interface (gateways, systèmes coopérants externes, etc.).
    www.labon-sun.com:
    Le serveur d'application est l'environnement d'exécution des applications côté serveur. Il prend en charge l'ensemble des fonctionnalités qui permettent à N clients d'utiliser une même application :Gestion de la session utilisateur : N clients utilisant une même instance d'application sur le serveur, il est nécessaire que le serveur d'application puisse conserver des contextes propres à chaque utilisateur (par exemple, un panier de commandes). La plupart des serveurs d'application génèrent un identifiant unique pour chaque nouveau client et transmettent cet identifiant lors de chaque échange HTTP par URL longs, variables cachées ou cookies.
    Gestion des montées en charge et reprise sur incident : Afin de gérer toujours plus d'utilisateurs, le serveur d'application doit pouvoir se déployer sur plusieurs machines et éventuellement offrir des possibilités de reprise sur incident (même si dans la grande majorité des cas, on se contente d'une gestion des montées en charge au niveau réseau - boîtier de répartition, DNS round-robin, reverse proxy ...).
    Ouverture sur de multiples sources de données : C'est le serveur d'application qui rend accessible les données des applications du système d'information. Il doit donc pouvoir accéder à de nombreuses sources de données. On s'attend également à ce qu'il fournisse des mécanismes performants comme le pooling de connexion base de données.
    ... 
    Le serveur d'application est donc indispensable si l'on souhaite éviter de re-développer l'ensemble de ces fonctionnalités (cas des GGI). Les moteurs JSP/Servlets, Microsoft ASP, Cold Fusion, PHP ... sont à ce titre des serveurs d'application (même si il sont intégrés au ServeurWeb PHP/ASP).
  • Mon expérience
    Nous avons trop tiré vers l’optimisation 80%
    Nous nous sommes toujours trompé sur la capacité à optimiser
    Savoir ce qui tourne sur les machines : lien avec le monitoring !
  • La qualité de service (QoS) est l’objectif fondamental du DSI d’un opérateur de télécommunication
    La Qualité de service est définie et mesurée à partir des processus métiers, ce qui motive l’orientation-processus du système d’information
    La QoS est formalisée au moyen de SLA (Service Level Agreement)
    Débit: un flux de 3000 nouvelles activations par jour
    Délai: le temps qu’il faut pour traiter une nouvelle activation de bout-en-bout
    Exemple: moins de 4h dans 80% des cas, moins de 12h dans 99%.
    Disponibilité: % du temps 7/24 pendant lequel le service est disponible
  • Anecdote: White Pajama, Call centers en ASP
    Centre d’appel, 3 catégories : gold, silver and bronze
    QoS garantie: appel pris en moins de 10s, 30s, 120s.
    Problème ouvert, sous-ensemble de l’OAI
  • 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

    ×