SlideShare una empresa de Scribd logo
1 de 28
Descargar para leer sin conexión
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

Más contenido relacionado

Similar a Cours chapitre9 2012

10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciel10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciellauraty3204
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxssuserec8501
 
Black Hat Europe 2008
Black Hat Europe 2008Black Hat Europe 2008
Black Hat Europe 2008fropert
 
2008-10-02 Paris - Administration des applications critiques avec SQL Server ...
2008-10-02 Paris - Administration des applications critiques avec SQL Server ...2008-10-02 Paris - Administration des applications critiques avec SQL Server ...
2008-10-02 Paris - Administration des applications critiques avec SQL Server ...Patrick Guimonet
 
Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"
Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"
Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"AnDaolVras
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010JUG Lausanne
 
20160216 - From BigData to BigProcessing
20160216 - From BigData to BigProcessing20160216 - From BigData to BigProcessing
20160216 - From BigData to BigProcessingPierre-Marie Brunet
 
IT Customer Solution Architect
IT Customer Solution ArchitectIT Customer Solution Architect
IT Customer Solution ArchitecticVatant
 
Exposé de SE Systemes distribués
Exposé de SE Systemes distribuésExposé de SE Systemes distribués
Exposé de SE Systemes distribuésYoussouf Saleh Gao
 
Projet security et datawarehouse
Projet security et datawarehouseProjet security et datawarehouse
Projet security et datawarehouseomri med
 
Webinar - Enterprise Cloud Databases
Webinar - Enterprise Cloud DatabasesWebinar - Enterprise Cloud Databases
Webinar - Enterprise Cloud DatabasesOVHcloud
 
Uml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementUml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementCERTyou Formation
 
Cours systèmes d'exploitation 2
Cours systèmes d'exploitation 2Cours systèmes d'exploitation 2
Cours systèmes d'exploitation 2Salah Triki
 
[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI - ...
[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI  - ...[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI  - ...
[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI - ...Groupe D.FI
 
Cours d'algorithmique distribuée (2010-2011)
Cours d'algorithmique distribuée (2010-2011)Cours d'algorithmique distribuée (2010-2011)
Cours d'algorithmique distribuée (2010-2011)Élodie Descharmes
 
2009-02-12 GRE302 - Développement d'applications vertes
2009-02-12 GRE302 - Développement d'applications vertes2009-02-12 GRE302 - Développement d'applications vertes
2009-02-12 GRE302 - Développement d'applications vertesPatrick Guimonet
 

Similar a Cours chapitre9 2012 (20)

10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciel10-Cours de Géniel Logiciel
10-Cours de Géniel Logiciel
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Black Hat Europe 2008
Black Hat Europe 2008Black Hat Europe 2008
Black Hat Europe 2008
 
Rapport_PRES__Copy_
Rapport_PRES__Copy_Rapport_PRES__Copy_
Rapport_PRES__Copy_
 
2008-10-02 Paris - Administration des applications critiques avec SQL Server ...
2008-10-02 Paris - Administration des applications critiques avec SQL Server ...2008-10-02 Paris - Administration des applications critiques avec SQL Server ...
2008-10-02 Paris - Administration des applications critiques avec SQL Server ...
 
Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"
Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"
Présentation A2com, Vitamin'C "Outils de gestion sur le cloud"
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
 
20160216 - From BigData to BigProcessing
20160216 - From BigData to BigProcessing20160216 - From BigData to BigProcessing
20160216 - From BigData to BigProcessing
 
IT Customer Solution Architect
IT Customer Solution ArchitectIT Customer Solution Architect
IT Customer Solution Architect
 
Tp1 6-141218060317-conversion-gate02
Tp1 6-141218060317-conversion-gate02Tp1 6-141218060317-conversion-gate02
Tp1 6-141218060317-conversion-gate02
 
Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6
 
Exposé de SE Systemes distribués
Exposé de SE Systemes distribuésExposé de SE Systemes distribués
Exposé de SE Systemes distribués
 
Gl intro
Gl introGl intro
Gl intro
 
Projet security et datawarehouse
Projet security et datawarehouseProjet security et datawarehouse
Projet security et datawarehouse
 
Webinar - Enterprise Cloud Databases
Webinar - Enterprise Cloud DatabasesWebinar - Enterprise Cloud Databases
Webinar - Enterprise Cloud Databases
 
Uml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementUml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnement
 
Cours systèmes d'exploitation 2
Cours systèmes d'exploitation 2Cours systèmes d'exploitation 2
Cours systèmes d'exploitation 2
 
[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI - ...
[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI  - ...[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI  - ...
[Café techno] Nouveautés Spectrum Protect 7.1.7 & les offres BaaS de D.FI - ...
 
Cours d'algorithmique distribuée (2010-2011)
Cours d'algorithmique distribuée (2010-2011)Cours d'algorithmique distribuée (2010-2011)
Cours d'algorithmique distribuée (2010-2011)
 
2009-02-12 GRE302 - Développement d'applications vertes
2009-02-12 GRE302 - Développement d'applications vertes2009-02-12 GRE302 - Développement d'applications vertes
2009-02-12 GRE302 - Développement d'applications vertes
 

Más de Yves Caseau

DataAquitaine February 2022
DataAquitaine February 2022DataAquitaine February 2022
DataAquitaine February 2022Yves Caseau
 
Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Yves Caseau
 
Machine Learning for Self-Tracking
Machine Learning for Self-TrackingMachine Learning for Self-Tracking
Machine Learning for Self-TrackingYves Caseau
 
Information Systems for Digital Transformation
Information Systems for Digital TransformationInformation Systems for Digital Transformation
Information Systems for Digital TransformationYves Caseau
 
Lean from the guts
Lean from the gutsLean from the guts
Lean from the gutsYves Caseau
 
Taking advantageofai july2018
Taking advantageofai july2018Taking advantageofai july2018
Taking advantageofai july2018Yves Caseau
 
Software Pitch 2018
Software Pitch 2018Software Pitch 2018
Software Pitch 2018Yves Caseau
 
Intelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAIntelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAYves Caseau
 
Big data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureBig data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureYves Caseau
 
XEBICON Public November 2015
XEBICON Public November 2015XEBICON Public November 2015
XEBICON Public November 2015Yves Caseau
 
Smart selfnovember2013
Smart selfnovember2013Smart selfnovember2013
Smart selfnovember2013Yves Caseau
 
Management socialnetworksfeb2012
Management socialnetworksfeb2012Management socialnetworksfeb2012
Management socialnetworksfeb2012Yves Caseau
 
Google socialnetworksmarch08
Google socialnetworksmarch08Google socialnetworksmarch08
Google socialnetworksmarch08Yves Caseau
 
Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Yves Caseau
 
Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Yves Caseau
 
Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Yves Caseau
 
The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014Yves Caseau
 

Más de Yves Caseau (20)

CCEM2023.pptx
CCEM2023.pptxCCEM2023.pptx
CCEM2023.pptx
 
DataAquitaine February 2022
DataAquitaine February 2022DataAquitaine February 2022
DataAquitaine February 2022
 
Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3
 
Machine Learning for Self-Tracking
Machine Learning for Self-TrackingMachine Learning for Self-Tracking
Machine Learning for Self-Tracking
 
Information Systems for Digital Transformation
Information Systems for Digital TransformationInformation Systems for Digital Transformation
Information Systems for Digital Transformation
 
Lean from the guts
Lean from the gutsLean from the guts
Lean from the guts
 
Taking advantageofai july2018
Taking advantageofai july2018Taking advantageofai july2018
Taking advantageofai july2018
 
Software Pitch 2018
Software Pitch 2018Software Pitch 2018
Software Pitch 2018
 
Intelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAIntelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIA
 
Big data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureBig data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT Architecture
 
XEBICON Public November 2015
XEBICON Public November 2015XEBICON Public November 2015
XEBICON Public November 2015
 
Smart selfnovember2013
Smart selfnovember2013Smart selfnovember2013
Smart selfnovember2013
 
Management socialnetworksfeb2012
Management socialnetworksfeb2012Management socialnetworksfeb2012
Management socialnetworksfeb2012
 
Google socialnetworksmarch08
Google socialnetworksmarch08Google socialnetworksmarch08
Google socialnetworksmarch08
 
Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance
 
Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013
 
Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015
 
GTES UTC 2014
GTES  UTC 2014GTES  UTC 2014
GTES UTC 2014
 
The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014
 
Disic mars2014
Disic mars2014Disic mars2014
Disic mars2014
 

Último

Semaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptxSemaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptxMartin M Flynn
 
Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2JeanLucHusson
 
Formation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changementFormation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changementM2i Formation
 
Exercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositionsExercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositionslaetitiachassagne
 
Rapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFERapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFEAhmam Abderrahmane
 
Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024frizzole
 
La Projection orthogonale en dessin technique
La Projection orthogonale en dessin techniqueLa Projection orthogonale en dessin technique
La Projection orthogonale en dessin techniquessuser4dbdf2
 

Último (7)

Semaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptxSemaine de la Passion de Jésus-Christ.pptx
Semaine de la Passion de Jésus-Christ.pptx
 
Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2Présentation de lancement de la SAE203 - MMI S2
Présentation de lancement de la SAE203 - MMI S2
 
Formation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changementFormation M2i - Femmes entrepreneures : soyez actrices du changement
Formation M2i - Femmes entrepreneures : soyez actrices du changement
 
Exercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositionsExercice de FLE pour enfants sur les transports et les prépositions
Exercice de FLE pour enfants sur les transports et les prépositions
 
Rapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFERapport projet de fin d'études licence PFE
Rapport projet de fin d'études licence PFE
 
Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024Planning de la semaine du 25 mars au 2 avril 2024
Planning de la semaine du 25 mars au 2 avril 2024
 
La Projection orthogonale en dessin technique
La Projection orthogonale en dessin techniqueLa Projection orthogonale en dessin technique
La Projection orthogonale en dessin technique
 

Cours chapitre9 2012

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

Notas del editor

  1. 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.
  2. 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)
  3. 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 &lt; 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
  4. Cf Chapitre 15 de « Performance by design » : Non-product form queueing models -&gt; resource contention, blocking, forking &amp; synchronization, priority scheduling  Idée clé du lean – 6 sigma : la variation de mu d’un système devient la variation lambda du second
  5. 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 
  6. Slide clé IO est soucvent un bottleneck car pas toujours parallèle (locks) Liens avec archi de données !
  7. 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.
  8. Exemples tirés de mon expérience Bytel
  9. Cf. p.48 de « Performance by Design » : # of thread du DBMS = compromis entre software contention (beaucoup de threads) et physical contention (peu de threads)
  10. 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&apos;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 &quot;pushed around&quot; :). 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&apos;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.
  11. 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% =&gt; asymptote = 10 Cf. Performance by Design p. 16 = trashing = la courbe decroit si le load est trop important
  12. Wikipedia: Un serveur d&apos;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&apos;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&apos;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&apos;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&apos;un même poste client, ainsi que la persistance des données partagées et les arbitrages d&apos;accès entre plusieurs postes clients concurrents. Les serveurs d&apos;applications sont des logiciels occupant la couche centrale dans une architecture multicouche, qu&apos;elle soit classique 3-tiers (postes clients, serveur de données, serveur d&apos;applications) ou étendue (n-tiers) lorsqu&apos;elle intègre des serveurs d&apos;acquisition (données de terrain, données de process, de back-office, etc.) et/ou des serveurs d&apos;interface (gateways, systèmes coopérants externes, etc.). www.labon-sun.com: Le serveur d&apos;application est l&apos;environnement d&apos;exécution des applications côté serveur. Il prend en charge l&apos;ensemble des fonctionnalités qui permettent à N clients d&apos;utiliser une même application :Gestion de la session utilisateur : N clients utilisant une même instance d&apos;application sur le serveur, il est nécessaire que le serveur d&apos;application puisse conserver des contextes propres à chaque utilisateur (par exemple, un panier de commandes). La plupart des serveurs d&apos;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&apos;utilisateurs, le serveur d&apos;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&apos;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&apos;est le serveur d&apos;application qui rend accessible les données des applications du système d&apos;information. Il doit donc pouvoir accéder à de nombreuses sources de données. On s&apos;attend également à ce qu&apos;il fournisse des mécanismes performants comme le pooling de connexion base de données. ...  Le serveur d&apos;application est donc indispensable si l&apos;on souhaite éviter de re-développer l&apos;ensemble de ces fonctionnalités (cas des GGI). Les moteurs JSP/Servlets, Microsoft ASP, Cold Fusion, PHP ... sont à ce titre des serveurs d&apos;application (même si il sont intégrés au ServeurWeb PHP/ASP).
  13. 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 !
  14. 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
  15. 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