cours chapitre9 2012

Copyright © Yves Caseau – 2012 - Cours Polytechnique (IX) 1/28

Théorie et Pratique du Système Théorie et Pratique du Système d’Informationd’InformationNeuvième Chapitre: Performance du SINeuvième Chapitre: Performance du SI

Janvier-Mars 2012Ecole Polytechnique

Yves Caseau


Plan du Cours – Architecture du Système Plan du Cours – Architecture du Système d’Informationd’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


Introduction à la mesure de performanceIntroduction à la mesure de performance

Un problème multidimensionnel 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

Pas de mesure sans modèle: 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

Pre

miè

re P

art

ie:

Mod

élisati

on


Théorie des Files d’AttenteThéorie des Files d’Attente « single station »

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

Pre

miè

re P

art

ie:

Mod

élisati

on

1

m

Loi arrivéeFile

« discipline »

m serveurs

Traitement : débit

Débit =


Quelques RésultatsQuelques Résultats

M/M/1= / (taux d’occupation)

M/M/m

M/G/1

Pre

miè

re P

art

ie:

Mod

élisati

on

1

K)1(

W

1

/1T

xW exF )1(1)(

11

00 )1(!

)(

!

)(

m

m

k

m mm

k

k

mPmK

1

0)1(!

)(

m

mP

m

m

mPW

)1(

/1

2

)1(

)1(

22BcQ

)1(

2

1//

MMQ )1(2

2

1//

DMQ


Réseaux de Files d’AttentesRéseaux de Files d’Attentes

Réseau de Jackson Matrice de connexion

Théorème de Jackson Sous les bonnes conditions (i<i.mi) Le réseau peut être vu comme un « produit » (k1,..,kn) = (k1) x … x (kn)

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)

Pre

miè

re P

art

ie:

Mod

élisati

on

1

m

1

m

1

m

1

m


Exemples - SimulésExemples - Simulés

Comparons (débits/durées ajustées):

Temps SLA (< 40s)

Pre

miè

re P

art

ie:

Mod

élisati

on

r=40% r=60% r=75% r =80% r=90% chaos burst quickP1 86% 75% 55% 42% 26% 47% 22% 11%P2 99% 99% 95% 86% 68% 58% 27% 25%P3 99% 99% 99% 99% 98% 91% 52% 34%P4 99% 99% 99% 94% 76% 65% 40% 25%P5 99% 95% 86% 71% 47% 48% 42% 82%

r=40 r=60 r=75% r=80% r=90% chaos burst quickP1 40,6 49 72 93 158 112 401 2040P2 30,6 32,2 36 41 53 38 373 840P3 30,8 30,4 30,5 31,7 35 209 216 660P4 30,5 31,4 34,1 38,5 50 100 327 900P5 35,6 38,3 44,8 55,2 74 204 201 44


Modèle de Performance - ServeurModèle de Performance - Serveur

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

Pre

miè

re P

art

ie:

Mod

élisati

on

I/O

AccueilLoad balancerm= 1 ou 2

1

m

Threads / processeurs

1 BD m=1,2 …

Selon architecture

Retourrésultats


Performance du SIPerformance du SI

3 modes opératoire, 3 problématiques : Batch

Avant tout un problème d’ordonnancement Peut être complexe (partage de ressource) mais seulement compliqué en

pratique Synchrone

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

Pre

miè

re P

art

ie:

Mod

élisati

on


8 idées fausses sur l’informatique distribuée (I)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 Incidents matériel, logiciels, humains Impose un surcoût de communication + infra (ex: secure messaging)

2. La latence est nulle 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)

3. 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

Pre

miè

re P

art

ie:

Mod

élisati

on


8 idées fausses sur l’informatique distribuée (II)8 idées fausses sur l’informatique distribuée (II)

4. Le réseau est sûr Authentifier, Cloisonner ( isoler), tracer, surveiller, outiller (pare-feux, anti-

virus, …)

5. La topologie du réseau ne change pas Utiliser des infrastructures d’intégration pour découpler logique/physique Ex: Pas d’adresses IP en dur … utiliser des DNS

6. Il existe un administrateur unique Administrateurs multiple => faciliter le déploiement, s’adapter facilement

aux contraintes

7. Le coût du transport est nul Transport => « marshalling/ unmarshalling » + latence Le coût du réseau est une part significative du TCO

8. Le réseau est homogène (J. Goesling) s’appuyer sur des protocoles interopérables et transportables

Pre

miè

re P

art

ie:

Mod

élisati

on


Deuxième partieDeuxième partie

Modélisation des Performances Résoudre les Problèmes de Performance Performances, SLA et Défaillances


Synthèse des attentesSynthèse des attentes

Mesurer, Comprendre Dimensionner, Tester, Valider « Réparer » les problèmes de perfs

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es

Administration

Utilisateurs futurs

Utilisateurs exceptionnels

Utilisateurs réguliers

Référentiels

Processflows

Serveurs Applications

Serveurs Présentation

Système d’information

Suivi Métiers

Attente: capacité à monter en

charge

Attente: robustesse, disponibilité,

Temps de réponse

Attente: capacity planning

Attente: monitoring &supervision

Attente: BAM


AntipatternsAntipatterns

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

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Exemples (vécus Exemples (vécus ) )

Traitement des cas d’exception 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

Bottleneck sur la gestion mémoire 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)

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Optimisation des Bases de DonnéesOptimisation des Bases de Données

C’est un métier ! Trouvez un DBA expert Ex: optimisation des requêtes SQL

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

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

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Optimisation des Flux XMLOptimisation 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

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Performances des Moteurs d’OrchestrationPerformances 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:Queue / listener / moteur /

invocation/ sauvegarde

Cf. Amdhal’s law 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

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es

# de processus

Performance

Throughput


Performances des Performances des Serveurs d’ApplicationServeurs 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émoireMê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é

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Tests de PerformanceTests de Performance

Deux objectifs liés Valider les exigences du contrat de services Régler (tuning) les paramètres (ex: nombre de processus, mémoire

allouée, etc.) 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 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

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Capacity PlanningCapacity Planning

Suivre, modéliser et prévoir les performances/capacités 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

Rôle d’une équipe indépendante 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

Deu

xiè

me P

art

ie:

Résou

dre

les P

rob

lèm

es


Troisième PartieTroisième Partie

Modélisation des Performances Résoudre les Problèmes de Performance Performances, SLA et Défaillances


Performance, Symptôme et DiagnosticPerformance, Symptôme et Diagnostic

Deux possibilités de diagnostic en cas de mauvaises performances: mauvaise architecture ou d’un sous-dimensionnement Symptôme d’une défaillance qui commence à s’exprimer

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: 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)

Tro

isiè

me P

art

ie:

Perf

orm

an

ce,

SLA

et

défa

illa

nce


OAI : l’Optimisation de la QoS des processusOAI : l’Optimisation de la QoS des processus

(2) Un contrat de service (3) des aléas ….

Bus

Processflow Engine

adapter

CRMPFS CustomerBase

ProvisioningHelp

Soit: (1) un ensemble de composants qui exécutent des processus

Question: peut-on automatiser le pilotage des processus pour assurer que les processus prioritaires sont traités en priorité ?

20 clients par Heure en moinsDe 2 minutes

•Pics d’activité•Pannes•Autres processus

IV : Pilotage par les Processus

Tro

isiè

me P

art

ie:

Perf

orm

an

ce,

SLA

et

défa

illa

nce


OAI: DifficultésOAI: Difficultés

Diagnostic 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

Dimensionnement Gestion de flux sous priorités : un problème combinatoire Gestion des aléas: un problème stochastique encore plus complexe

Planification 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)

IV : Pilotage par les Processus

Tro

isiè

me P

art

ie:

Perf

orm

an

ce,

SLA

et

défa

illa

nce


OAI: ModèleOAI: Modèle1. Modèle classique

d’un ST – cf 1e partie

2. Infrastructure detransport de message

3. Processflow « fault-tolerant »(avec rejeu)

4. Synchronisation objets métiers entrelacée (cf. Chapitre 6)

Tro

isiè

me P

art

ie:

Perf

orm

an

ce,

SLA

et

défa

illa

nce

File d’attente

PolitiqueSélection

…

n « threads » avec loi de service identique

adaptateur

BUS

ST1 STn

monitor

File d’attenteDéfinitio

nprocessu

s

MesuresStatsRejeu

Option:Adaptateurpiloté


OAI: Quelle “infrastructure adaptative” ?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

II: Self-Adaptive Middleware


Résultats de la simulationRé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.

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)

Les approches de contrôle de flux sont difficile à régler et peu efficace

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)”

cours chapitre9 2012

Education