Nous présentons ici les principes du modèle permettant de capturer le comportement des
services multi-étagés soumis à des charges variables. Le modèle est basé sur la théorie des
files d’attente. Nous choisissons de modéliser le service comme un réseau de files d’attente.
En effet, ce type de modélisation permet de capturer de manière précise les phénomènes de
contention pouvant apparaître sur les différents serveurs composant le système multi-étagé.
Les bases théoriques des modèles à file d’attente ont été définies dans les années 1980 [47,18].
5.2.1 Files d’attente
Une file d’attente représente à la fois une ressource critique en terme de performance,
ainsi que la file de requêtes en attente pour accéder à cette ressource [38]. Il existe plusieurs
façon d’ordonnancer les requêtes à l’intérieur de la file. Les files les plus courantes sont les
files FIFO, pourfirst in, first out(premier entré, premier sorti). Dans ce type de file, chaque
re-quête est assurée d’être traitée après la rere-quête qui la précède dans la file, et avant la rere-quête
qui la suit dans cette même file. Nous considérons par la suite les files d’attente comme étant
des files FIFO, comme c’est le cas dans la plupart des serveurs composant les services
Inter-net. A chaque file d’attente et à chaque type de charge est associée untemps de service. Ce
temps correspond au temps moyen incompressible nécessaire au traitement d’une requête
de ce type de charge par la ressource critique (c-à-d le serveur). Dans notre cadre applicatif,
le temps de service sur les ressources est indépendant de la quantité de charge. En effet, le
temps de traitement reste constant même si la latence augmente. Cette augmentation de
la-tence est due au temps passé en attente de traitement dans la file, et non à la modification
du temps de service.
Le choix du niveau de granularité pour les ressources représentées par les files d’attente
influence la précision du modèle, mais aussi sa facilité d’utilisation. Une granularité fine
permet d’obtenir un modèle avec une vue plus riche du système. Son utilisation est
cepen-dant rendue difficile par le nombre plus important de paramètres du modèle, ces derniers
dépendant entre autres du nombre de files d’attente dans le système. Inversement, une
gra-nularité importante permet une utilisation plus facile du modèle en limitant la complexité
du paramétrage de ce dernier. Le modèle peut cependant perdre en précision dans certains
cas. Dans notre cadre applicatif, nous modélisons chaque serveur par une file d’attente.
5.2.2 Files d’attente pour services multi-étagés dupliqués
FIGURE5.2 – Réseau ouvert de files d’attente
FIGURE5.3 – Réseau fermé de files d’attente
Un service multi-étagé dupliqué est modélisé par un réseau de files d’attente. Les réseaux
de files d’attente sont divisés en deux catégories, les réseaux ouverts (boucles ouvertes) et les
réseaux fermés (boucles fermées). Dans lesréseaux ouverts, les requêtes sont envoyées vers le
système indépendamment de la vitesse de traitement de ce dernier. Les clients n’attendent
donc pas la réponse à leur requête pour envoyer une nouvelle requête. La figure5.2présente
un exemple de réseau ouvert. Dans lesréseaux fermés, les clients attendent la réponse à leur
requête avant d’en envoyer une autre. Nous supposons que toute requête admise dans le
service sera traitée sans erreur, quel que soit le niveau de qualité de service fourni par le
service. Les éventuelles erreurs applicatives pouvant résulter d’une surcharge du service
Internet ne font pas l’objet de cette étude. Dans les réseaux fermés, les clients marquent
un temps de réflexion entre la réception d’une réponse et l’émission de la requête suivante
(temps d’attente, outhink time). Dans les réseaux fermés, les clients sont donc vus comme
un délai supplémentaire dans la boucle de traitement. La figure 5.3 présente un exemple
de réseau fermé. Dans le cadre des services Internet, la modélisation se base sur un réseau
fermé de files d’attente. En effet, dans les applications considérées les clients attendent la
réponse à une requête avant d’en émettre une suivante. La figure5.4 présente un exemple
de modélisation de service Internet multi-étagé dupliqué.
FIGURE5.4 – Modélisation d’une application multi-étagée
La figure5.5présente un exemple de service Internet à 3 étages ayant une configuration
κ(3, AC < 1,1,2 >, LC < 20,15,3 >), une quantité de charge de 30 clients et un type de
charge caractérisé entre autres par des ratios de visiteV < 1,0.5,2 >. Cet exemple illustre
le comportement des 30 requêtes clients tentant d’accéder aux différents étages et files
d’at-tente. Ainsi, parmis lesN t1 = 30 clients tentant d’accéder à l’étageT1,N r1 = 10sont
re-jetés à cause de la configuration locale (c’est-à-dire le contrôle d’admission) sur cet étage et
N a
1= 20 clients sont admis sur le serveur deT
1. Ensuite, les 20 requêtes clients traitées
parT1 génèrentN t2 = 10sous-requêtes vers l’étageT2 (du fait du ratio de visiteV2 = 0.5).
L’ensemble des 10 requêtes sont admises sur le serveur deT
2, car ce nombre est inférieur à
la configuration locale deT
2(N a2 = 10). Enfin, les 10 requêtes surT
2induisent au total
40 requêtes surT3 (avec un ratio de visiteV3 = 2). Cependant, à cause de la
communica-tion synchrone entre les étages d’un service Internet, une requête surT
2induit à un instant
donné au plus une requête versT
3, et en moyenne 4 requêtes successives vers T
3. Parmis
ces 10 requêtes,N r3 = 4requêtes sont rejetées par la configuration locale deT3, etN a3 = 6
requêtes sont admises et réparties sur les deux serveurs composant cet étage. En résumé, sur
les 30 requêtes client tentant d’accéder au service multi-étagé, un total de 14 sont rejetées et
16 sont traitées, ce qui donne un taux de rejet de 47%.
Na1= 20 Nr1= 10 Nt1= 30 Na2= 10 Nr2= 0 Nr3= 4 Nt3= 10 Nt2= 10 AC3= 2; LC3= 3 V3= 2 AC2= 1; LC2= 15 V2= 0.5 AC1= 1; LC1= 20 V1= 1
Tier T
1Tier T
2Tier T
3Na3= 6
FIGURE5.5 – Modélisation d’une application multi-étagée - prise en compte de la
5.3 Algorithme de prédiction de performance, de disponibilité et
Dans le document
Performance, disponibilité et coût de services Internet adaptatifs
(Page 55-59)