Introduction de fonctionnalités d'auto-optimisation dans une architecture de selfbenchmarking

HAL Id: tel-00782233

https://tel.archives-ouvertes.fr/tel-00782233

Submitted on 29 Jan 2013

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

une architecture de selfbenchmarking

El Hachemi Bendahmane

To cite this version:

El Hachemi Bendahmane. Introduction de fonctionnalités d’auto-optimisation dans une archi-

tecture de selfbenchmarking. Autre [cs.OH]. Université de Grenoble, 2012. Français. �NNT :

2012GRENA020�. �tel-00782233�

THÈSE

Pour obtenir le grade de

DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE

Spécialité : Informatique

Arrêté ministériel : 7 août 2006

Présentée par

El Hachemi BENDAHMANE

Thèse dirigée par Patrice MOREAUX et codirigée par Bruno DILLENSEGER préparée au sein du Laboratoire LISTIC dans l'École Doctorale SISEO

Introduction de fonctionnalités d'auto-optimisation dans une architecture de

selfbenchmarking

Thèse soutenue publiquement le 25 septembre 2012 devant le jury composé de :

Mme Nihal PEKERGIN

Professeur des Universités, Université de Paris XII – Créteil, rapporteur

M. Mikaël SALAÜN

Professeur des Universités, École des Mines de Nantes - Nantes, rapporteur

M. Thomas BEGIN

Maître de Conférences, Université Claude Bernard – Lyon, examinateur

M. Laurent BROTO

Maître de Conférences, INPT/ENSEEIHT - Toulouse, examinateur

M. Didier DONSEZ

Professeur des Universités, Université Joseph Fourier – Grenoble,

examinateur

Remerciements

Lorsque vous r´ esolvez un probl` eme, vous devriez remercier Dieu et passer au probl` eme suivant. [David Dean Rusk]

Protocole oblige : d’abord la famille, mes parents, mes fr` eres et sœurs.

Ensuite, et par ordre chronologique, j’ai une pens´ ee pour

Limoges : Chercheurs et personnel du laboratoire XLIM. Je cite parmi les professeurs K. Tamine, J-L. Lanet, D. Ghazanfarpour, parmi les coll` egues : Salah, Djalil, Saif, Nassima et Thibault. Aussi les doctorants qui sont aujourd’hui docteurs : Nadir et Boussad.

Grenoble : Je n’oublierai jamais les trois ans pass´ es ` a Orange Labs. Je cite Christian Bayle, Alexandre Lefebvre, Aim´ e Vareil, V´ eronique, Collete, Christelle, . . . et la liste est longue. Merci ` a toutes et ` a tous.

Annecy : Le temps pass´ e au LISTIC. Je remercie le personnel du LISTIC de l’Universit´ e de Savoie, mes coll` egues et amis doctorants : Nabil, Renaud, Fabien et la liste est longue . . .

Enfin un Remerciement Sp´ ecial ` a mes deux encadrants de th` ese :

Bruno Dillenseger de France T´ el´ ecom, d’abord et avant tout pour ses qualit´ es hu- maines, pour ses conseils et sa disponibilit´ e, mais aussi pour son s´ erieux et son rigueur.

Merci pour toutes les heures d’Extreme Progamming que nous avons pass´ ees ensemble de- vant l’ordinateur. Je ne divulgue pas un secret si je dis que Bruno, en dehors de ses qualit´ es techniques, est quelqu’un avec qui on a toujours envie de travailler car tout simplement, c’est quelqu’un de bien.

Patrice Moreaux du LISTIC, pour tout l’effort qu’il a fait pour l’aboutissement de cette th` ese.

Et enfin, un grand remerciement ` a Nihal Pekergin et Mika¨el Sala¨ un d’avoir accept´ e de rapporter sur mon manuscrit, pour leur retour rapide pour leurs commentaires de qualit´ e et leurs conseils avis´ es.

Un grand merci ` a Didier Donsez, Laurent Broto et Thomas Begin d’avoir accept´ e de

faire partie de jury de ma th` ese, merci beaucoup.

Table des mati` eres

Remerciements i

1 Introduction g´ en´ erale 1

1.1 Motivations . . . . 1

1.1.1 Test de performance et benchmarking . . . . 1

1.1.2 Optimisation . . . . 2

1.1.3 Probl´ ematique . . . . 3

1.2 Approche . . . . 3

1.2.1 Principes . . . . 3

1.2.2 Composants et boucles de contrˆ ole autonome . . . . 3

1.2.3 Un algorithme adapt´ e . . . . 4

1.2.4 Validation . . . . 4

1.3 Organisation du document . . . . 4

I Etat de l’art ´ 7 2 Evaluation de performances et Benchmarking ´ 9 2.1 Evaluation de performances des syst` ´ emes informatiques . . . . 10

2.2 Evaluation de performance bas´ ´ ee sur les mod` eles stochastiques . . . . 13

2.3 Evaluation de performances bas´ ´ ee sur les mesures . . . . 14

2.3.1 Activit´ es de base d’un test de performances . . . . 14

2.3.2 Plan et sc´ enarios de test . . . . 16

2.3.3 Outils de test . . . . 18

2.4 Benchmarking . . . . 19

2.4.1 D´ efinition . . . . 19

2.4.2 Exemples de benchmarks . . . . 20

2.5 Conclusion . . . . 21

3 Optimisation des performances 23

iii

3.1 Principes et m´ ethodes . . . . 25

3.1.1 Principes . . . . 25

3.1.2 M´ ethodes de r´ esolution des probl` emes d’optimisation . . . . 26

3.1.3 Quelques m´ ethodes d’optimisation . . . . 28

3.2 Optimisation des syst` emes informatiques . . . . 31

3.2.1 Optimisation en informatique . . . . 31

3.2.2 Param` etres et niveaux d’optimisation . . . . 32

3.3 Approches « m´ etier » d’optimisation . . . . 33

3.3.1 Oracle et l’optimisation des Syst` emes de gestion de bases de donn´ ees 34 3.3.2 IBM et l’optimisation des serveurs d’application . . . . 36

3.3.3 Optimisation ` a base de points d’attente . . . . 38

3.4 Conclusion . . . . 40

4 L’auto-optimisation dans le contexte de l’autonomic computing 43 4.1 Autonomic computing . . . . 44

4.1.1 Bref historique . . . . 45

4.1.2 Travaux apparent´ es . . . . 47

4.1.3 Boucle de contrˆ ole MAPE-K . . . . 48

4.1.4 Coop´ eration entre ´ el´ ements autonomes . . . . 50

4.2 Approches autonomiques de l’auto-optimisation . . . . 51

4.3 Approche architecturale ` a composants . . . . 52

4.3.1 Les mod` eles ` a composants . . . . 52

4.3.2 Le mod` ele Fractal . . . . 53

4.3.3 Selfware : une architecture ` a composants pour l’Autonomic Com- puting . . . . 54

4.4 Injection de Charge Auto-R´ egul´ ee (ICAR) . . . . 56

4.4.1 Introduction . . . . 56

4.4.2 CLIF, un canevas logiciel de test de performance . . . . 56

4.4.3 R´ egulation automatique de la charge . . . . 59

4.5 Conclusion . . . . 60

II Contribution 61 5 Politique d’optimisation 63 5.1 Caract´ eristiques du probl` eme . . . . 65

5.1.1 Formalisation du probl` eme d’optimisation . . . . 65

TABLE DES MATI ` ERES v

5.1.2 Nature de la fonction ` a optimiser . . . . 66

5.1.3 Complexit´ e du probl` eme . . . . 67

5.2 Algorithme g´ en´ eral (en croix) . . . . 69

5.2.1 Principe . . . . 69

5.2.2 R´ eglage de l’algorithme . . . . 71

5.3 Algorithme ´ el´ ementaire . . . . 72

5.3.1 Principe . . . . 72

5.3.2 Algorithme d´ etaill´ e . . . . 75

5.4 Complexit´ e de l’algorithme . . . . 77

5.5 Prise en compte des contraintes . . . . 78

5.6 Int´ egration de l’algorithme ` a ICAR . . . . 79

6 Architecture logicielle de la plate-forme de Self-benchmarking 81 6.1 Architecture de l’application d’auto-optimisation . . . . 82

6.1.1 Introduction . . . . 82

6.1.2 Exploitation du type ”lame” de CLIF . . . . 82

6.1.3 Architecture globale . . . . 83

6.2 Le composant optimiseur . . . . 84

6.3 Les composants configurateurs . . . . 88

6.3.1 Application de l’architecture commune de lame CLIF . . . . 88

6.3.2 Exemples de configurateurs . . . . 89

6.4 Les composants d´ emarreurs . . . . 90

6.4.1 Principe . . . . 90

6.4.2 Exemple . . . . 90

6.5 Coordination des boucles de contrˆ ole . . . . 91

6.5.1 Les 3 boucles de contrˆ ole . . . . 91

6.5.2 Probl´ ematique . . . . 91

6.5.3 Approche choisie . . . . 93

6.5.4 R´ ealisation . . . . 93

6.6 Conclusion . . . . 95

III Validation exp´ erimentale 97 7 Exp´ erimentations 99 7.1 Auto-optimisation d’une application Java EE de type achat en ligne . . . . 100

7.1.1 Cas d’´ etude MyStore sur JOnAS . . . 100

7.1.2 Description du probl` eme d’optimisation . . . 101

7.1.3 Plate-forme de test et d’optimisation . . . 103

7.1.4 Observations et r´ esultats obtenus . . . 104

7.1.5 Analyse de r´ esultats . . . 108

7.2 Auto-optimisation d’une application multi-tiers . . . 110

7.2.1 Cas d’´ etudes : l’application clusterSample : Apache2-JOnAS-MySQL SampleCluster . . . 110

7.2.2 Description du probl` eme d’optimisation . . . 112

7.2.3 Plate-forme de test et d’optimisation . . . 114

7.2.4 Observation et r´ esultats obtenus . . . 115

7.2.5 Analyse de r´ esultats . . . 118

7.3 Bilan et conclusions . . . 120

8 Conclusion g´ en´ erale 123 8.1 Approche . . . 123

8.2 Bilan . . . 124

8.3 Perspectives . . . 125

8.3.1 Extensions de l’outil d’auto-optimisation . . . 125

8.3.2 Am´ elioration de l’algorithme d’optimisation . . . 126

IV Annexes 127 A Plans de test CLIF et sc´ enarios d’injection ISAC 129 A.1 Plan de test CLIF pour MyStore . . . 129

A.2 Sc´ enario d’injection ISAC pour MyStore . . . 131

A.3 Plan de test CLIF pour SampleCluster . . . 134

A.4 Sc´ enario d’injection ISAC pour SampleCluster . . . 137

B Configuration de l’injection de charge auto-r´ egul´ ee ICAR 141 B.1 Fichier de propri´ et´ es de Selfbench pour MyStore . . . 141

B.2 Fichier de propri´ et´ es de Selfbench pour SampleCluster . . . 143

C Probl` eme d’optimisation 145 C.1 Fichier de propri´ et´ es du probl` eme d’optimisation pour MyStore . . . 145

C.2 Fichier de propri´ et´ es du probl` eme d’optimisation pour SampleCluster . . . 147

Bibliographie 149

TABLE DES MATI ` ERES vii

R´ esum´ e 158

2.1 Les m´ ethodes d’´ evaluation de performance . . . . 10 2.2 Un benchmark doit ˆ etre appropri´ e (reproduit de [Hup09]) . . . . 19 3.1 Chemin typique d’une requˆ ete le long d’une pile Java EE . . . . 38 4.1 Un syst` eme autonome est un ensemble d’´ el´ ements autonome qui coop` erent

pour atteindre un objectif commun, Boucle MAPE-K, Source : J.O. Ke- phart, D. Chess, “The Vision of Autonomic Computing.” . . . . 49 4.2 El´ ´ ements de terminologie du mod` ele Fractal . . . . 54 4.3 L’´ el´ ement autonomique est la combinaison d’un Managed Element et d’un

Autonomic Manager . . . . 55 4.4 Sch´ ema de principe de test de charge avec contrˆ ole automatique d’injection 57 4.5 Principes fonctionnels de CLIF . . . . 58 4.6 Architecture d’un plan de test CLIF d´ eploy´ e . . . . 59 5.1 Exemple de fonction ` a plusieurs maxima locaux sous l’hypoth` ese 2 . . . . . 66 5.2 Illustration de l’algorithme de recherche en croix avec deux param` etres . . 69 5.3 Algorithme ´ el´ ementaire - cas 1, 2 et 3 . . . . 73 5.4 Algorithme ´ el´ ementaire - cas 3.1, 3.1.1 et 3.1.2 . . . . 74 5.5 Algorithme ´ el´ ementaire - cas 3.2 . . . . 74 5.6 Principe de l’int´ egration du syst` eme d’injection de charge auto-r´ egul´ e dans

l’algorithme . . . . 80 6.1 Vue globale des diff´ erents composants de l’architecture d’auto-optimisation 84 6.2 Architecture commune d’une lame CLIF (Common Blade Architecture) . . 89 6.3 Vue globale des composants et des boucles de contrˆ ole de l’architecture

d’auto-optimisation . . . . 92 6.4 Vue globale des composants et des boucles de contrˆ ole de l’architecture

d’auto-optimisation . . . . 94

viii

7.1 Exemple de mont´ ee en charge ICAR, correspond ` a un test de MyStore avec une configuration avec des MIN . . . 105 7.2 performance de l’application MyStore port´ ee par JOnAS avec diff´ erentes

configurations . . . 109 7.3 clusterSample en architecture mono-JOnAS . . . 111 7.4 performance de l’application clusterSample avec diff´ erentes configurations . 119

Liste des tableaux

2.1 Diff´ erents types de test et leurs objectifs . . . . 15 7.1 Description des param` etres d’optimisation pour l’application MyStore . . . 102 7.2 Calcul par dichotomie des valeurs possibles en prenant en compte la gra-

nularit´ e de chaque param` etre . . . 103 7.3 Tableau r´ ecapitulatif de l’outillage n´ ecessaire pour une exp´ erience d’auto-

optimisation avec le dispositif Self-Optimizer . . . 103 7.4 Description des param` etres d’optimisation pour l’application clusterSample 113 7.5 Calcul par dichotomie des valeurs possibles en prenant en compte la gra-

nularit´ e de chaque param` etre . . . 114 7.6 Tableau r´ ecapitulatif de l’outillage n´ ecessaire pour une exp´ erience d’auto-

optimisation avec le dispositif Self-Optimizer . . . 115

Listings

6.1 Extrait de la d´ efinition des interfaces Test control (superviseur) et Blade control (lames) du canevas logiciel CLIF . . . . 85 6.2 Exemple de d´ efinition de 2 param` etres pour l’optimisation de Tomcat au

sein du serveur d’application JOnAS. Chaque param` etre est ici d´ esign´ e par une expression XPATH car le param´ etrage repose sur des fichiers XML. . . 86

ix

6.3 Exemple de plan de test avec 2 injecteurs, 2 sondes, 2 configurateurs et un d´ emarreur, pour l’optimisation d’une application sur le serveur d’applica-

tion JOnAS. . . . 87

7.1 Extrait de la fin du log de l’optimizer . . . 106

7.2 Extrait du retour d’une requˆ ete d’utilisateur dans clusterSample avec une architecture mono-JOnAS . . . 110

7.3 Extrait de la fin du log de l’optimizer . . . 116

A.1 Extrait de la d´ efinition d’un plan de test pour MyStore . . . 129

A.2 Extrait de la d´ efinition d’un sc´ enario d’injection pour MyStore . . . 131

A.3 Extrait de la d´ efinition d’un plan de test pour SampleCluster . . . 134

A.4 Extrait de la d´ efinition d’un sc´ enario d’injection pour SampleCluster . . . 137

B.1 Extrait de la configuration de Selfbench pour MyStore . . . 141

B.2 Extrait de la configuration de Selfbench pour ClusterSample . . . 143

C.1 Extrait de la d´ efinition du probl` eme d’optimisation pour MyStore . . . 145

C.2 Extrait de la d´ efinition du probl` eme d’optimisation pour ClusterSample . . 147

Chapitre 1

Introduction g´ en´ erale

Sommaire

1.1 Motivations . . . . 1

1.1.1 Test de performance et benchmarking . . . . 1

1.1.2 Optimisation . . . . 2

1.1.3 Probl´ ematique . . . . 3

1.2 Approche . . . . 3

1.2.1 Principes . . . . 3

1.2.2 Composants et boucles de contrˆ ole autonome . . . . 3

1.2.3 Un algorithme adapt´ e . . . . 4

1.2.4 Validation . . . . 4

1.3 Organisation du document . . . . 4

1.1 Motivations

1.1.1 Test de performance et benchmarking

La complexit´ e croissante des syst` emes informatiques, en termes de passage ` a l’´ echelle, r´ epartition et architecture, rend de plus en plus d´ elicate l’´ evaluation de leur performance.

Si les approches ` a base de mod` eles permettent d’obtenir rapidement des pr´ evisions de performance avec des moyens r´ eduits, cette grande complexit´ e, ainsi que le manque ou l’absence de sp´ ecification formelle, en limitent la qualit´ e des r´ esultats ou la faisabilit´ e.

Ainsi, les techniques de test par injection de trafic et observation des performances du syst` eme sont tr` es largement utilis´ ees.

1

Le test de performance est souvent motiv´ e par le benchmarking, pratique qui vise ` a obtenir une mesure de performance comparable entre diff´ erentes alternatives techniques.

Ces alternatives peuvent consister en diff´ erents param´ etrages d’un mˆ eme syst` eme, ou ` a des implantations partiellement ou totalement diff´ erentes du syst` eme. Dans le domaine des serveurs d’application Java EE, on peut ainsi ˆ etre amen´ e ` a chercher le meilleur para- m´ etrage d’une machine virtuelle Java donn´ ee (e.g. politique du garbage collector, taille du tas), ou ` a choisir entre diff´ erentes machines virtuelles Java. Il en va de mˆ eme pour tous les autres ´ el´ ements de l’application vis´ ee : serveur HTTP, servlets, type d’EJB, syst` eme de gestion de base de donn´ ees (SGBD), etc.

Le benchmarking peut donc servir ` a optimiser un syst` eme, afin d’en obtenir les meilleures performances. Pour cela, l’´ equipe de test doit effectuer des campagnes de test sur plusieurs param´ etrages ou configurations du syst` eme, et comparer les r´ esultats. En r´ ealit´ e, ce prin- cipe d’optimisation est incontournable dans toute pratique de benchmark. En effet, si le benchmarking vise ` a obtenir des mesures de performances significatives et effectivement comparables, encore faut-il que les diff´ erents ´ el´ ements alternatifs compar´ es soient test´ es dans leur param´ etrage optimal. Par exemple, pour choisir entre un SGBD A et un SGBD B, il est n´ ecessaire de r´ ealiser un benchmark de A et B dans leur param´ etrage optimal pour l’application et le trafic de requˆ etes d´ efinis.

1.1.2 Optimisation

L’optimisation d’un syst` eme informatique consiste ` a am´ eliorer son fonctionnement en regard d’un ou plusieurs crit` eres quantitatifs. Dans le domaine des performances, il s’agit d’am´ eliorer des indices mesurables tels que le temps de r´ eponse, le d´ ebit de requˆ etes trait´ es par seconde ou le nombre de clients simultan´ es. L’optimisation consiste alors ` a maximiser certaines m´ etriques et ` a en minimiser d’autres.

L’optimisation des performances n´ ecessite de modifier le syst` eme, afin d’´ evaluer dif-

f´ erentes configurations ou diff´ erents param´ etrages. Ces modifications s’int` egrent dans un

processus de g´ en´ eration/´ evaluation et de parcours d’espace de solutions, classique en in-

formatique. Il est typiquement conduit par l’´ equipe de test, qui utilise son expertise en

partie empirique afin de ne pas se retrouver submerg´ ee par la combinatoire ´ enorme entre

les diff´ erentes valeurs possibles des diff´ erents param` etres du syst` eme. Pour chaque para-

m´ etrage ou configuration jug´ e pertinent, un d´ eploiement du syst` eme test´ e et une ex´ ecution

du benchmark sont r´ ealis´ es.

1.2. Approche 3

1.1.3 Probl´ ematique

L’optimisation des syst` emes informatiques et le benchmarking sont des disciplines

´

etroitement li´ ees. Leur pratique implique l’expertise d’une ´ equipe de test et des tˆ aches r´ ep´ etitives et fastidieuses visant ` a chercher le param´ etrage optimal du syst` eme test´ e.

La probl´ ematique abord´ ee dans cette th` ese est celle de l’automatisation de l’optimi- sation et du benchmarking, que nous nommerons respectivement auto-optimisation et self-benchmarking. Ce dernier terme d´ esigne l’ex´ ecution automatique d’une campagne de benchmark qui d´ etermine de mani` ere autonome le param´ etrage donnant la meilleure per- formance.

Nous souhaitons fournir un cadre logiciel complet permettant de g´ en´ erer et d’appliquer des param´ etrages ` a un syst` eme ` a optimiser, et de conduire des tests de performance enti` erement automatis´ es. Pour ce faire, nous devons prendre en compte deux difficult´ es majeures :

– l’ind´ ependance et l’adaptabilit´ e vis-` a-vis du syst` eme ` a optimiser ;

– le temps d’ex´ ecution ”raisonnable”, ´ etant donn´ ees la combinatoire ´ enorme entre les valeurs des param` etres, et la dur´ ee d’ex´ ecution de chaque test.

1.2 Approche

1.2.1 Principes

Notre approche comporte deux volets. Le premier volet concerne l’architecture logi- cielle, afin de pouvoir assurer l’ind´ ependance et l’adaptabilit´ e aux diff´ erents syst` emes ` a optimiser. Le second volet consiste ` a proposer un algorithme d’optimisation adapt´ e aux contraintes d’utilisation r´ eelles, notamment en terme de temps d’ex´ ecution global.

1.2.2 Composants et boucles de contrˆ ole autonome

Nous proposons une approche ` a base de composants, h´ erit´ ee de travaux dans le do- maine de l’autonomic computing . En tout ´ etat de cause, l’auto-optimisation est l’une des propri´ et´ es cl´ es des syst` emes auto-administrables, et il est naturel de s’y r´ ef´ erer. De plus, l’essence de l’autonomic computing est justement la m´ ethodologie de construction des propri´ et´ es autonomes, notamment avec le principe de boucle de r´ etroaction observation- analyse-r´ eaction.

Techniquement, nous partons d’un canevas logiciel ` a composants d´ edi´ e au test de per-

formance (CLIF [Dil09]), et d’une extension permettant de piloter de mani` ere autonome

le niveau de charge inject´ e jusqu’` a atteinte de crit` eres de saturation (Selfbench). Ces ´ el´ e- ments logiciels nous fournissent la base pour obtenir le benchmark du syst` eme, ` a laquelle nous int´ egrons nos composants de param´ etrage (configurateurs, d´ emarreurs) et de contrˆ ole de l’optimisation. Pour r´ ealiser cette int´ egration, nous avons ´ et´ e amen´ es ` a traiter la ques- tion de la coordination entre plusieurs boucles de contrˆ ole, par une solution faiblement coupl´ ee ` a base de communication asynchrone de type publication-souscription.

1.2.3 Un algorithme adapt´ e

Nous proposons un algorithme d’optimisation bas´ e sur un principe de recherche dicho- tomique et de parcours « en croix » de l’espace des solutions. Sous des hypoth` ese s que nous justifions, l’algorithme permet de diminuer de mani` ere tr` es significative le nombre de solutions ` a tester, et donc le temps total d’ex´ ecution de l’auto-optimisation. De plus, une heuristique sur l’ordre des param` etres est propos´ ee afin de contribuer ` a r´ eduire encore ce temps.

Afin de r´ eduire la dur´ ee du processus de self-benchmarking , le nombre de param` etres et le nombre de leurs valeurs doivent ˆ etre aussi r´ eduits que possible. En compl´ ement, une granularit´ e de valeur est fix´ ee pour chaque param` etre, afin de r´ eduire le nombre de tests, moyennant une approximation de la valeur optimale des param` etres jug´ ee satisfaisante.

L’expertise initiale reste donc tr` es importante afin d’´ eviter une dur´ ee totale d’ex´ ecution r´ edhibitoire.

Par ailleurs, grˆ ace ` a une repr´ esentation abstraite du probl` eme d’optimisation, cet al- gorithme est ind´ ependant du syst` eme ` a optimiser.

1.2.4 Validation

Pour la validation de notre travail, nous avons r´ ealis´ e deux campagnes de test et d’optimisation sur deux applications WEB qui diff` erent significativement quant ` a leur fonctionnement, mˆ eme si elles sont port´ ees par des serveurs d’applications identiques.

La premi` ere est une application exemple de type achat en ligne, d´ eploy´ ee sur le serveur d’applications Java EE JOnAS. La seconde est le benchmark RUBIS, une application de type ench` eres en ligne, ´ egalement d´ eploy´ ee sur JOnAS.

1.3 Organisation du document

Le manuscrit se divise en trois parties : ´ etat de l’art en trois chapitres, contribution

en deux chapitres et validation en un seul chapitre, plus une introduction g´ en´ erale et une

1.3. Organisation du document 5 conclusion g´ en´ erale.

Le chapitre 1 est la pr´ esente introduction du m´ emoire.

Le chapitre 2 fait un rappel des diff´ erentes notions li´ ees ` a l’´ evaluation de performances en informatique ainsi que les diff´ erentes m´ ethodes employ´ ees dans ce domaine. Ce chapitre se concentre ´ egalement sur la pratique du testing et son application dans le domaine du (benchmarking).

Le chapitre 3 est d´ edi´ e ` a l’optimisation, ses notions et principes, les approches princi- pales et m´ ethodes de r´ esolution. Il aborde aussi l’optimisation en informatique du point de vue des niveaux et de param` etres d’optimisation. Ce mˆ eme chapitre d´ ecrit quelques approches m´ etiers phares d’optimisation des syst` emes informatiques.

Le chapitre 4 fait un rappel des diff´ erentes notions et principes du Calcul Auto- nome (Autonomic Computing). Il introduit les approches autonomiques de l’auto-optimisation, nous y avons consacrons une section au mod` ele architectural de composants que l’on a uti- lis´ e pour la mise en place de notre dispositif d’auto-optimisation. Un exemple des syst` emes autonomes est donn´ e dans ce chapitre, il s’agit d’un syst` eme d’injection de charge auto- r´ egul´ ee que nous ´ etendons justement dans le cadre de ce travail par l’ajout des aspects d’auto-optimisation.

Le chapitre 5 pr´ esente l’aspect algorithmique de notre contribution concernant l’auto- optimisation qui se traduit dans notre contexte par la recherche du param´ etrage opti- mal du syst` eme sous test. Notre algorithme se d´ ecompose en deux parties. La premi` ere concerne le niveau global, c’est ` a dire le contrˆ ole de l’´ evolution de la valeur de l’indica- teur de performance, en fonction des valeurs des param` etres de r´ eglage du syst` eme. La deuxi` eme partie est relative ` a la recherche de l’optimum lorsqu’un seul param` etre est mo- difi´ e. Nous d´ etaillons dans ce chapitre ´ egalement les r´ eglages ` a r´ ealiser sur l’algorithme et nous indiquons comment cet algorithme est mis en œuvre dans l’architecture de notre application d’auto-optimisation.

Le chapitre 6 d´ ecrit l’architecture logicielle de la plate-forme de Self-benchmarking que nous proposons, et d´ etaille les diff´ erents composants Fractal qui la composent : l’op- timiseur, les configurateurs et les d´ emarreurs. Ce mˆ eme chapitre aborde ´ egalement la probl´ ematique de la communication entre les composants contrˆ oleurs, les diff´ erentes ap- proches possibles, et la mise en place de la solution adopt´ ee.

Le chapitre 7 pr´ esente deux s´ eries d’exp´ erimentations r´ ealis´ ees pour la validation de

notre dispositif d’auto-optimisation. La premi` ere exp´ erimentation sert ` a trouver le meilleur

param´ etrage d’une application WEB de type achat en ligne simplifi´ ee (application exemple

MyStore) s’ex´ ecutant sur le serveur d’application JOnAS. La deuxi` eme exp´ erimentation

concerne une application Java EE dont les trois tiers sont r´ epartis sur des machines dis-

tinctes. Nous pr´ esentons et analysons dans ce chapitre les r´ esultats obtenus ainsi que les gains de performances obtenus par rapport ` a des configurations par d´ efaut.

Le chapitre 8 dresse ` a la fois un bilan des r´ esultats obtenus ` a l’occasion de ce travail,

une ´ evaluation de ces derniers et aussi une projection dans le futur sous forme de quelques

perspectives d’am´ eliorations et d’extensions possibles de notre travail.

Premi` ere partie Etat de l’art ´

7

Chapitre 2

Evaluation de performances et ´ Benchmarking

Nous introduisons dans ce chapitre les diff´ erentes notions li´ ees ` a l’´ evaluation de performances en informatique. Nous rappelons les principales m´ ethodes em- ploy´ ees dans ce domaine. Nous nous concentrons ensuite sur la d´ emarche de test et son application dans les approches par comparaison (benchmarking).

Sommaire

2.1 Evaluation de performances des syst` ´ emes informatiques . . . . 10 2.2 Evaluation de performance bas´ ´ ee sur les mod` eles stochastiques . . . . 13 2.3 Evaluation de performances bas´ ´ ee sur les mesures . . . . 14 2.3.1 Activit´ es de base d’un test de performances . . . . 14 2.3.2 Plan et sc´ enarios de test . . . . 16 2.3.3 Outils de test . . . . 18 2.4 Benchmarking . . . . 19 2.4.1 D´ efinition . . . . 19 2.4.2 Exemples de benchmarks . . . . 20 2.5 Conclusion . . . . 21

L ^a croissance rapide des syst` emes informatiques actuels, ´ egalement de nature de plus en plus complexe, entraˆıne des probl` emes des performances parfois critiques, qui peuvent aller d’une simple d´ egradation de performance sous des charges plus ou moins importantes ou une diminution de la qualit´ e de service, jusqu’` a un effondrement total du syst` eme.

L’´ evaluation des performances, bien qu’elle soit une discipline universelle, est devenue en informatique une discipline ` a part enti` ere avec un ensemble de m´ ethodes sp´ ecifiques.

La figure 2.1 r´ esume les diff´ erentes approches utilis´ ees en ´ evaluation de performance.

9

Évaluation de performance

Évaluation non stochastique

Mesures Prototypage

Modélisation stochastique

Simulation Résolution Analytique/

numérique

Figure 2.1: Les m´ ethodes d’´ evaluation de performance

L’´ evaluation de performances s’applique ` a la fois avant la constitution du syst` eme et sur des syst` emes existants. Dans le premier cas, on dispose d’une description du syst` eme

`

a construire pour lequel on ´ elabore un mod` ele math´ ematis´ e (voir section 2.2) ` a partir duquel on peut calculer des indicateurs de comportement et par cons´ equent pr´ evoir les performances du syst` eme concern´ e. Dans le deuxi` eme cas, on distingue trois cas de figures : – On peut abstraire le syst` eme par un mod` ele math´ ematis´ e. on est alors ramen´ e au

premier cas.

– La mod´ elisation du syst` eme est trop complexe ou impossible parce qu’on ne dispose pas d’assez d’informations. Dans ce cas, on est r´ eduit ` a des mesures sur le syst` eme.

On parle alors de test de performances.

– Il est ´ egalement possible de construire un syst` eme simplifi´ e, un prototype ou un simulateur, pour le faire fonctionner en lieu et place du syst` eme final. On fournit alors ` a ce syst` eme des stimuli qui repr´ esentent les donn´ ees d’entr´ ee du syst` eme et l’on observe le comportement du prototype.

2.1 Evaluation de performances des syst` ´ emes infor- matiques

Dans ce m´ emoire, nous nous cantonnons aux aspects scientifiques et techniques de la notion de performance, en ´ ecartant par exemple les probl` emes de coˆ ut ou de consommation

´

energ´ etique. En informatique, les performances d’un syst` eme, d’une application ou d’un service sont les caract´ eristiques de fonctionnement de ce dernier relatives ` a un ensemble de crit` eres donn´ es.

Ces crit` eres de performances parfois appel´ es indices de performances sont de natures

2.1. ´ Evaluation de performances des syst` emes informatiques 11 diverses. On distingue en particulier les indices suivants :

1. le d´ ebit souvent not´ e χ : nombre de tˆ aches, requˆ etes, traitements, r´ ealis´ es pendant une p´ eriode de temps donn´ ee ;

2. le temps de r´ eponse souvent not´ e R : temps de traitement d’une tˆ ache. Par exemple dans les r´ eseaux de communication, le temps de r´ eponse de bout en bout est le d´ elai d’acheminement des paquets ` a travers le r´ eseau.

3. le nombre de « clients » souvent not´ e Q ou N : nombre de tˆ aches pr´ esentes dans le syst` eme ;

4. le taux d’utilisation d’une ressource r souvent not´ e U (r) : le taux d’utilisation U (r) est soit la proportion de temps pendant lequel r est utilis´ ee sur une p´ eriode de temps donn´ ee (par exemple : taux d’utilisation d’une uit´ e centrale de traitement (CPU ), soit la proportion de ressources r utilis´ ees dans un ensemble R de telles ressources (par exemple le taux d’utilisation d’un groupe de processus l´ egers (Threads) d’un serveur WEB).

Pour chacun de ces param` etres, on peut s’int´ eresser ` a sa valeur ` a un instant de temps donn´ e t, ` a sa valeur moyenne sur une dur´ ee donn´ ee (ainsi qu’` a d’autres statistiques comme la variance), ou, lorsqu’elle existe, ` a leur valeur limite au cours du temps, aussi appel´ ee valeur ` a l’´ equilibre.

Chacun de ces param` etres poss` ede une signification dans pratiquement tous les do- maines de l’informatique. On peut par exemple s’int´ eresser aux performances d’un serveur en mati` ere de d´ ebit, au temps de r´ eponse d’une application de r´ eservation en ligne, ou encore ` a la comparaison de plusieurs compilateurs d’une machine multiprocesseurs.

L’´ evaluation de performances a donn´ e lieu ` a de nombreux travaux d’ing´ enierie dont l’ouvrage de Raj Jain [Jai91] est une des r´ ef´ erences du domaine. Jain identifie dix ´ etapes importantes pour mener ` a bien toute ´ etude de performances d’un syst` eme informatique.

Nous avons r´ esum´ e ces ´ etapes dans les points suivants :

1. Fixer les objectifs de l’´ evaluation et d´ efinir les contours du syst` eme ´ etudi´ e. Par exemple, pour deux CPUs (Central Processing Unit ), si l’objectif est d’´ etudier l’im- pact de leurs performances sur le temps d’ex´ ecution de plusieurs programmes, le syst` eme pourrait consister en le syst` eme ` a temps partag´ e et les r´ esultats de l’´ etude pourraient d´ ependre significativement d’autres composants que les CPUs. Par contre si les deux CPUs sont identiques ` a l’ALU (Arithmetic and Logical Unit ) pr` es, le CPU est consid´ er´ e comme syst` eme et les composants au sein du CPU sont consid´ er´ es comme parties du syst` eme.

2. Identifier la liste des fonctionnalit´ es ou services offerts par le syst` eme ainsi que les

r´ esultats qu’ils fournissent. Par exemple, un r´ eseau informatique permet la trans- mission de paquets entre diff´ erents destinataires ; un syst` eme de gestion de base de donn´ ees (SGBD) r´ epond ` a des requˆ etes ; un processeur traite diff´ erentes instructions.

3. Choisir les indicateurs de performances que l’on veut obtenir en fonction des objectifs de l’´ etude.

4. Identifier la liste des param` etres du syst` eme qui affectent les performances ´ etudi´ ees.

On distingue ici les param` etres li´ es au syst` eme (CPU, m´ emoire, r´ eseau, . . .) et les param` etres li´ es ` a la charge de travail demand´ ee au syst` eme (nombre ou vitesse d’arriv´ ee des requˆ etes, . . .). Ce point est important. Nous verrons dans le reste de ce m´ emoire qu’une connaissance approfondie du syst` eme test´ e est n´ ecessaire pour identifier l’ensemble de ces points. Ces param` etres sont appel´ es param` etres d’optimisation (tunning parameters).

5. S´ electionner parmi les param` etres, ceux, en nombre r´ eduit, sur lesquels on va jouer au cours de l’´ evaluation (Jain les nomme « facteurs d’´ evaluation » ).

6. Choisir la m´ ethode d’´ evaluation. Il existe trois m´ ethodes : analyse et simulation qui se basent sur une mod´ elisation du syst` eme ´ etudi´ e, test qui se base sur des mesures directes sur le syst` eme test´ e.

7. D´ efinir les caract´ eristiques de la charge sous laquelle le syst` eme va ˆ etre ´ etudi´ e. Ce point est important du fait que si la charge n’est pas adapt´ ee au syst` eme (charge de r´ ef´ erence, mont´ ee de la charge dans le temps, etc.) on ne peut obtenir que des r´ esultats peu significatifs et parfois inutiles.

8. Calculer les indicateurs de performances. Il s’agit donc de calculer les diff´ erents indices de performances ` a partir du mod` ele d´ efini (analyse ou simulation) ou bien de mesurer ces m´ etriques directement sur le syst` eme test´ e via des sondes mises sur les ´ el´ ements concern´ es (JVM, CPU, r´ eseaux, .etc.),

9. Analyser et interpr´ eter les r´ esultats. Pour les m´ ethodes de simulation et de mesures,

l’analyse des r´ esultats doit ˆ etre pr´ ec´ ed´ ee par une phase de traitements statistiques,

10. Exprimer de mani` ere synth´ etique les r´ esultats et les analyses. Cette ´ etape est n´ e-

cessaire lorsqu’il s’agit d’exploiter les r´ esultats de l’´ etude en vue de prendre des

d´ ecisions.

2.2. ´ Evaluation de performance bas´ ee sur les mod` eles stochastiques 13

2.2 Evaluation de performance bas´ ´ ee sur les mod` eles stochastiques

Comme pour les autres cat´ egories de m´ ethodes (voir figure 2.1), la d´ emarche consiste

`

a d´ ecrire le syst` eme ´ etudi´ e, choisir et d´ efinir des indicateurs de performance, obtenir leurs valeurs et analyser les r´ esultats obtenus. Mais, dans les approches par mod´ elisation stochastique, les indices de performance sont obtenus comme r´ esultats de calculs.

Au niveau des mod` eles, on distingue deux cat´ egories. D’une part, ce qu’on appelle des mod` eles fondamentaux ou de bas niveau, qui sont des syst` emes stochastiques ` a ´ ev` enements discrets (SSEV). Ils d´ ecrivent les syst` emes avec des ´ etats et des transitions entre ces ´ etats.

Les dur´ ees de s´ ejour dans les ´ etats suivent des distributions de probabilit´ e dont les lois sont d´ efinies dans le mod` ele. Parmi ces mod` eles, les chaˆınes de Markov sont le mod` ele le plus employ´ e. Dans une chaˆıne de Markov, les dur´ ees de s´ ejour dans les ´ etats suivent des lois exponentielles n´ egatives (temps continu) ou g´ eom´ etriques (temps discret). Cette propri´ et´ e est effectivement v´ erifi´ ee ou repr´ esente une approximation satisfaisante dans de nombreux cas et les chaˆınes de Markov permettent d’obtenir des r´ esultats pertinents depuis bientˆ ot un si` ecle, pas uniquement dans le domaine de l’informatique.

Les mod` eles SSEV sont tr` es complexes ` a d´ efinir en partant d’un syst` eme technolo- gique comme un syst` eme informatique ou un atelier de production. Le nombre d’´ etats et de transitions peut ˆ etre en effet extrˆ emement grand (10 <sup>12</sup> ´ etats) et la description tr` es laborieuse. On emploie donc souvent des mod` eles de plus haut niveau s´ emantique, i.e.

`

a plus fort pouvoir d’expression. Parmi ces mod` eles, nous citerons les files d’attente, les r´ eseaux de files d’attente [Bay00], les r´ eseaux de Petri stochastiques [ABC <sup>+</sup> 95, HM01] les alg` ebres de processus stochastiques. Dans chaque cas, on d´ efinit des algorithmes de tra- duction automatique de ces mod` eles vers des SSEV. Les risques d’erreur de mod´ elisation sont ainsi r´ eduits et les concepteurs de syst` emes sont plus ` a mˆ eme de d´ efinir les ´ el´ ements du mod` ele (structure et param` etres).

Lorsque le mod` ele est d´ efini, on met en œuvre des m´ ethodes de r´ esolution du pro- bl` eme math´ ematis´ e, on parle de « r´ esolution du mod` ele » , pour calculer les indices de performance que l’on a d´ efini.

Notons enfin qu’il est possible d’employer ` a la fois une m´ ethode fond´ ee sur un mod` ele

stochastique tout en utilisant des mesures sur syst` eme effectif. Dans ce cas, les mesures

permettent de param´ etrer, caract´ eriser, le mod` ele avant de calculer les indices de perfor-

mance.

2.3 Evaluation de performances bas´ ´ ee sur les me- sures

La mesure de performances est l’une des m´ ethodes les plus utilis´ ees, si ce n’est la plus utilis´ ee, pour ´ evaluer les performances des syst` emes existants. La proc´ edure qui permet d’obtenir ces mesures s’appelle un test de performances [Bar04]. On distingue plusieurs cat´ egories de test. Les plus pratiqu´ es sont indiqu´ es dans le tableau 2.1.

2.3.1 Activit´ es de base d’un test de performances

La tˆ ache principale de toute campagne de test, quel qu’en soit le type, est de fournir un ensemble d’informations concernant le fonctionnement du syst` eme test´ e afin d’ˆ etre en mesure d’aider les testeurs ou les chefs de projets de validation des tests ` a prendre des d´ ecisions ´ eclair´ ees relatives ` a la qualit´ e globale de l’application test´ ee. Les tests de perfor- mances ont ainsi tendance ` a se concentrer sur l’identification des goulets d’´ etranglement dans un syst` eme, l’am´ elioration de son r´ eglage, ou encore l’aide ` a ´ etablir une base de r´ e- f´ erence pour les essais futurs En outre, les r´ esultats des tests et leur analyse permettront d’estimer la configuration mat´ erielle requise pour un usage de l’application en production.

Il existe de nombreux outils de test (voir section 2.3.3) qui couvrent ` a degr´ es divers, l’ensemble des cat´ egories de tests pr´ esent´ ees ci-dessus. Tous ces outils pr´ esentent de nom- breux points communs. Inspir´ es sans doute par l’approche de Jain et al. [MFB ⁺ 07] listent un ensemble d’´ etapes pour la bonne pratique des tests des performances dans le domaine des applications web. Ces ´ etapes sont r´ esum´ ees dans les points suivants :

1. Identification de l’environnement du test : une connaissance approfondie de l’envi- ronnement physique du test (configurations mat´ erielles, logicielles et r´ eseau) et de l’environnement de production permet la conception des tests plus efficaces et une identification plus rapide des objectifs du test d` es le d´ ebut du projet,

2. Identification des crit` eres de performances. Il s’agit de d´ efinir les objectifs ainsi que les contraintes concernant le temps de r´ eponse, le d´ ebit et l’usage des ressources.

En g´ en´ eral, le temps de r´ eponse est une pr´ eoccupation de l’utilisateur, le d´ ebit est une pr´ eoccupation de l’entreprise et l’usage de ressources est une pr´ eoccupation du gestionnaire du syst` eme.

3. Plans et sc´ enarios de test. Il s’agit de d´ efinir les principaux sc´ enarios, d´ eterminer

les comportements des utilisateurs et simuler la variabilit´ e parmi ces utilisateurs, de

d´ efinir les donn´ ees de test, et de d´ efinir les mesures qui doivent ˆ etres collect´ ees.

2.3. ´ Evaluation de performances bas´ ee sur les mesures 15

Type de test Objectif Remarques

Test de performances S’assurer du bon fonction- nement de l’application en utilisation r´ eelle. Obtenir un r´ ef´ erentiel de temps de r´ eponse de l’application.

On ne cherche pas ` a atteindre les limites de l’application ou de l’infra- structure mais uniquement

`

a mesurer les temps de r´ eponse moyens lors d’une utilisation normale (fonc- tions utilis´ ees, nombre d’utilisateurs).

Test de stress Ce test permet de simu- ler un pic de charge r´ eel et de d´ etecter certaines failles (fuite de m´ emoire, inter- blocage, . . .) en poussant les conditions de tests au- del` a de l’utilisation nor- male de l’application.

La d´ etection de ces failles n’est possible que dans un contexte de stress de l’application. En utilisa- tion normale ces failles sont souvent invisibles.

Test d’endurance S’assurer du bon fonction- nement de l’application en utilisation r´ eelle et sur la dur´ ee. Utile lorsqu’il y a un engagement sur le taux de disponibilit´ e de l’appli- cation.

Consiste ` a faire fonction- ner l’application ` a un rythme normal, pendant une p´ eriode de temps relativement longue pour voir si une d´ egradation des temps de r´ eponse, une fuite m´ emoire ou un blocage n’apparaˆıt pas au bout d’un certain temps.

Test de robustesse S’assurer du bon fonc- tionnement de l’applica- tion avec une charge im- portante sur la dur´ ee.

N´ ecessite qu’il y ait eu au pr´ ealable un test d’endu- rance complet

Test de mont´ ee en charge Observer les limites que peut supporter l’applica- tion ou un de ses compo- sants.

On augmente le nombre d’utilisateurs simul´ es de mani` ere r´ eguli` ere et on recherche le « point de rupture » , c’est-` a-dire le moment o` u l’application ne r´ epond plus dans le temps maximum accept´ e par l’utilisateur.

Table 2.1: Diff´ erents types de test et leurs objectifs

4. Configuration de l’environnement du test. Il s’agit de pr´ eparer l’environnement de test, les outils et les ressources n´ ecessaires pour ex´ ecuter chaque plan de test, et de s’assurer que l’environnement de test est instrument´ e pour la surveillance des ressources monitoring .

5. Mettre en œuvre la conception du test. Il faut produire les artefacts du test de performance conform´ ement ` a la conception du test.

6. Ex´ ecution et suivi du test : Valider le test, les donn´ ees de test, et collecter les r´ esul- tats. Apr` es validation, ex´ ecuter les tests en les surveillant ainsi que l’environnement de test.

7. Analyse des r´ esultats, r´ edaction des rapports et re-test. Il s’agit de la consolidation et du partage des r´ esultats du test, de l’analyse des donn´ ees individuellement et avec l’´ equipe inter-fonctionnelle, de la re-d´ efinition des priorit´ es des tests et si n´ ecessaire de leur re-ex´ ecution. Lorsque toutes les m´ etriques sont dans les limites accept´ ees, qu’aucun des seuils fix´ es n’est viol´ e, et que toutes les informations souhait´ ees ont

´ et´ e recueillies, la fin du test est atteinte.

2.3.2 Plan et sc´ enarios de test

Toute campagne de test doit commencer par l’´ elaboration d’un plan de test. On y trouve :

– un r´ esum´ e du projet ;

– l’architecture technique et logicielle de l’application ` a tester ; – les objectifs du test ;

– le type de test ; – le mod` ele de charge ; – les sc´ enarios du test ;

– le plan d’ex´ ecution des tests.

Quelque soit le type de test ` a effectuer, la s´ election de la charge est une partie cruciale de toute ´ etude de performances. Un mauvais choix de la charge peut mener ` a des r´ esultats non significatifs, incoh´ erents ou erron´ ees. Le niveau de la charge est un facteur important.

Selon l’objectif du test, une charge doit mener le syst` eme ` a ses capacit´ es compl` etes (dans

le meilleur cas) ou au-del` a de ces capacit´ es (mauvais cas) ou enfin au meilleur niveau

de charge observ´ e dans un cas d’usage r´ eel du syst` eme (cas typique). Enfin, une bonne

charge doit permettre de reproduire facilement les r´ esultats sans ´ ecart significatifs. Les

charges qui font des demandes de ressources fortement al´ eatoires sont g´ en´ eralement moins

souhaitables car elles n´ ecessitent beaucoup plus de tests et par cons´ equent plus de temps

2.3. ´ Evaluation de performances bas´ ee sur les mesures 17 pour avoir des r´ esultats significatifs.

Dans de nombreux outils de test, on g´ en` ere la charge sous la forme d’utilisateurs virtuels (Virtual User , VUsers). Un VUser est la reproduction du comportement d’un utilisateur r´ eel de l’application (login, ouverture d’une session, connexion ` a une BD, trai- tement m´ etier, etc.). Le comportement d’un VUser est d´ efini dans un sc´ enario (Behavior ).

Le nombre initial de VUsers et la strat´ egie de mont´ ee en charge sont d´ efinis dans le profil de charge.

Un bon plan est celui qui repr´ esente le plus possible le comportement d’un utilisateur r´ eel du syst` eme. Une d´ efinition de cette repr´ esentativit´ e peut ˆ etre r´ edig´ ee dans des scripts sous forme d’un ou plusieurs sc´ enrios. Un sc´ enario refl` ete le plus fid` element possible le comportement d’un utilisateur r´ eel de l’application ; il doit tenir en compte les points suivant :

1. le taux d’arriv´ ee : le taux d’arriv´ ee des requˆ etes doit ˆ etre le mˆ eme ou proportionnel

`

a celui de l’application r´ eelle.

2. la demande de ressources : la totalit´ e des demandes en ressources (i.e. requˆ etes des clients) doit ˆ etre similaire ou proportionnelle ` a celle de l’application r´ eelle.

3. le profil d’usage de ressources : le s´ equencement et la fr´ equence avec lesquels les diff´ erentes ressources sont utilis´ ees doivent ˆ etre du mˆ eme ordre que ceux des requˆ etes r´ eelles.

Le comportement de l’utilisateur en fonction du temps est un autre facteur crucial dans la d´ efinition la charge. Les clients changent leurs comportement dans le temps et tout changement dans les performances du syst` eme les obligent ` a changer leur comportement d’usage de ressources du syst` eme. Un bon plan de test doit accorder une importance particuli` ere ` a la d´ efinition du comportement des clients du syst` eme en fonction du temps.

L’impact d’´ el´ ements externes du syst` eme sous test peut aussi ˆ etre plus ou moins fort ; par exemple la comparaison entre la vitesse de deux processeurs peut ˆ etre compl` etement masqu´ ee ` a cause de l’impact des composants d’E/S.

Il est tr` es important d’identifier les sc´ enarios pertinents et de les pond´ erer. Pour d´ efinir ces sc´ enarios on peut :

– r´ ecup´ erer des statistiques de l’utilisation de l’application si elles existent (par exemple le nombre quotidien ou mensuel de transactions m´ etier, l’analyse des statistiques WEB (fichiers de connexions, acces log )).

– d´ efinir avec les utilisateurs les sc´ enarios principaux d’utilisation (les fonctions les plus utilis´ ees) de leur application.

Enfin, toute plate-forme de test de performances comporte g´ en´ eralement un g´ en´ erateur

de charges et un syst` eme de sondes. Un syst` eme de g´ en´ eration de charge, appel´ e aussi

moteur de charge est un logiciel qui est capable de simuler les actions des utilisateurs et de ce fait g´ en´ erer la charge sur l’application. Ces actions sont d´ efinies dans des scripts automatisant les sc´ enarios et valoris´ es sur un lot de donn´ ees particulier. On peut donc distinguer deux cat´ egories d’outils :

– Les simulateurs d’utilisateurs qui, essentiellement, font ex´ ecuter les scripts de test pour un grand nombre d’utilisateurs virtuels ;

– Les g´ en´ erateurs de donn´ ees qui vont permettre de valoriser les scripts utilis´ es et ainsi assurer que chaque utilisateur virtuel n’effectue pas exactement la mˆ eme op´ eration ce qui n’aurait pas beaucoup de sens du point de vue des performances mesur´ ees ensuite.

Un syst` eme de sondes est plac´ e au niveau du syst` eme sous test. Ces sondes permettent de remonter des mesures dont l’objet est de savoir comment r´ eagissent individuellement des composantes du syst` eme (m´ emoire, CPU, r´ eseau, disques .etc.).

2.3.3 Outils de test

Il est ´ evident qu’une d´ emarche de test ne peut ˆ etre conduite qu’avec l’aide d’outils logiciels adapt´ es. Il existe de nombreux outils de test. Citons parmi les plus connus, sinon les plus employ´ es :

– Outils commerciaux :

– LoadRunner (HP), leader du march´ e ; – Silk-performer (Micro Focus) ;

– Load Testing (Oracle) ;

– IBM Rational Performance Tester (IBM) ; Outils open source :

– CLIF (France T´ el´ ecom, http://clif.ow2.org/) ;

– JMeter (Apache fundation, http://jmeter.apache.org/) ; – Grinder (http://grinder.sourceforge.net/)

Nous renvoyons le lecteur aux descriptions d´ etaill´ ees de chaque outil pour de plus amples informations.

On peut d’une part distinguer les outils « open source » et les outils commerciaux, en g´ en´ eral tr` es coˆ uteux. Les outils open source sont fr´ equemment des solutions ad hoc

`

a des probl` emes sp´ ecifiques d’´ evaluation de performance. CLIF [Dil09] est une exception notable ` a cette situation. C’est l’outil que nous utiliserons dans notre ´ etude et nous le pr´ esentons en d´ etails dans le chapitre 4.

Les outils commerciaux proposent des palettes de fonctions plus ´ etendues. Cepen-

dant, peu d’entre-eux disposent, ` a la fois, des fonctionnalit´ es d’injection de charge, de

2.4. Benchmarking 19

Figure 2.2: Un benchmark doit ˆ etre appropri´ e (reproduit de [Hup09]) surveillance d’usage des ressources et de profilage de l’ex´ ecution.

2.4 Benchmarking

2.4.1 D´ efinition

Le terme mˆ eme de benchmarking a donn´ e lieu ` a de multiples d´ efinitions, dans la sph` ere commerciale comme dans la sph` ere technique et scientifique. Par exemple, David Kerns, directeur ex´ ecutif de Xerox, donne la d´ efinition suivante du Benchmarking : « the continuous process of measuring products, services, and practices against the toughest competitors or those recognized as industry leaders » (le process continu de la mesure des produits, services et pratiques par rapport aux concurrents les plus directs ou aux leaders du march´ e).

Plus techniquement, le benchmarking est la pratique de tests de performances en vue d’une comparaison

– entre plusieurs alternatives de conception du mˆ eme syst` eme ; – ou entre diff´ erentes configurations d’un syst` eme donn´ e ;

– ou encore entre deux ou plusieurs syst` emes de mˆ eme type ou avec les mˆ emes fonc- tionnalit´ es (Serveurs d’applications, syst` emes de disques, syst` emes de gestion de bases de donn´ ees, etc.).

Le benchmarking consiste consiste donc ` a comparer plusieurs syst` emes ou ´ etalonner un

syst` eme pour un fonctionnement donn´ e vis ` a vis d’un syst` eme de r´ ef´ erence, selon des

crit` eres quantifi´ es. Le mot anglais benchmarking, que l’on peut traduire par ´ evaluation,

´

etalonnage, est en g´ en´ eral conserv´ e tel quel dans la communaut´ e francophone de l’´ evalua- tion et du test de performance, du test et des syst` emes informatiques. Nous suivrons cet usage.

En pratique, concevoir puis pratiquer un benchmark pertinent, rel` eve, comme le sou- ligne [Hup09], de l’art de l’ing´ enieur comme de la science. La figure 2.2 tir´ ee d’une pr´ esen- tation de Huppler r´ esume deux ´ ecueils classiques du benchmarking : mesurer des grandeurs non significatives par rapport au probl` eme pos´ e, tirer des conclusions fausses de r´ esultats de benchmarks.

Notons que pour comparer diff´ erents syst` emes de mani` ere coh´ erente, il est n´ ecessaire de r´ egler chacun d’entre-eux de sorte qu’il fonctionne avec les meilleures performances relativement aux crit` eres retenus pour le benchmark. Ainsi, toute proc´ edure de bench- marking implique l’optimisation des syst` emes concern´ es, qui se traduit par un r´ eglage des configurations et de leurs param` etres.

2.4.2 Exemples de benchmarks

Il existe de tr` es nombreux benchmarks dans le domaine de l’informatique. Deux or- ganismes ´ elaborent des s´ eries de benchmarks, TPC et SPEC. Par ailleurs, plusieurs com- munaut´ es ont d´ efini des benchmarks sp´ ecifiques qui font en quelque sorte r´ ef´ erence dans leur domaine, sans pour autant ˆ etre d´ ecrits de mani` ere totalement formelle.

2.4.2.1 TPC

Le Transaction Processing Performance Council (http://www.tpc.org/) est un orga- nisme a but non lucratif dont la mission est de d´ efinir des benchmakrs de performances de syst` emes informatiques transactionnels et de publier les r´ esultats de ces benchmarks.

Les origines de TPC remontent au d´ ebut des ann´ ees 80, o` u les constructeurs avaient cha-

cun leur propre syst` eme de mesure de puissance de machine, ce qui ne permettait pas la

comparaison entre ces derniers [Gra85]. Le TPC en tant qu’organisme a ´ et´ e cr´ e´ e en 1988

par huit compagnies. Les premiers r´ esultats TPC-A ont ´ et´ e annonc´ es en juillet 1990. Par

la suite d’autres benchmarks ont ´ et´ e mis au point pour mesurer d’autres points de vue,

comme par exemple les performances des syst` emes client-serveur. L’originalit´ e des classe-

ments du TPC est non seulement de fournir des tableaux de puissance relative, mais aussi

des tableaux faisant intervenir le ratio performance/coˆ ut [Cou]. Les acteurs du march´ e

publient r´ eguli` erement les records atteints lors des passations des benchmarks TPC, en

particulier pour le plus utilis´ e d’entre-eux, TPC-C.

2.5. Conclusion 21 2.4.2.2 Spec

La Standard Performance Evaluation Corporation (http://www.spec.org/), est une organisation ` a but non lucratif, dont la vocation est de produire, cr´ eer, maintenir et ap- prouver un ensemble standard de benchmarks. SPEC at´ e cr´ ee en 1988 et ses benchmarks sont largement utilis´ es pour l’´ evaluation des syst` emes informatiques. Les benchmarks de SPEC concernent diff´ erents syst` emes ou sous-syst` emes informatiques tel que : Bench- marks de CPU, Benchmarks Cient/Serveur, Benchmarks Serveurs de mail, Benchmarks SIP, Benchmark SOAP et Benchmark ´ energie. La description des diff´ erentes benchmarks, de leurs plateformes ainsi que les r´ esultats sont publi´ ees sur le site web de la corpora- tion [SPE].

2.4.2.3 Benchmarks de type cas d’´ etude

Il s’agit de syst` emes ou applications ou ensemble d’applications, dans un domaine donn´ e, qui, sans ˆ etre compl` etement d´ efinis, correspondent ` a des cas d’´ etude (use case) fr´ equemment rencontr´ es dans ce secteur. Dans le contexte des serveurs WEB par exemple, nous citerons les architectures Apache-PHP-MySQL (LAMP ou WAMP). Dans le domaine des serveurs d’application, on associe en g´ en´ eral un serveur ` a une application d´ eploy´ ee d’un type donn´ e (e-commerce, consultation d’horaires, r´ eservation en ligne, etc). Deux exemples caract´ eristiques et largement utilis´ es, MyStore (e-commerce) et RUBIS (ench` eres en ligne) toutes deux d´ eploy´ ees sur le serveur Java EE JOnAS seront utilis´ es dans nos exp´ erimentations (voir le chapitre 7).

2.5 Conclusion

Dans ce chapitre, nous avons r´ ealis´ e un ´ etat de l’art relatif ` a l’´ evaluation de perfor-

mance. Nous avons vu qu’il y a trois m´ ethodes possibles pour ´ evaluer les performances des

syst` emes informatiques. Nous avons pr´ esent´ e succinctement ce que c’est l’´ evaluation bas´ ee

sur la mod´ elisation. Nous avons vu en d´ etails les principes de l’´ evaluation bas´ ee sur des

mesures r´ ealis´ ees sur le syst` eme en fonctionnement. C’est cette approche que nous suivons

dans ce m´ emoire. Nous avons ´ egalement introduit le concept de benchmarking. Dans le

chapitre suivant, nous pr´ esentons une br` eve synth` ese sur les probl` emes d’optimisation.

Chapitre 3

Optimisation des performances

Nous rappelons dans ce chapitre les notions et principes de l’optimisation. nous introduisons les principales approches et m´ ethodes de r´ esolution. Nous abordons ensuite l’optimisation en informatique et nous dressons une liste des param` etres et des niveaux d’optimisation. Nous pr´ esentons ´ egalement quelques approches m´ etiers d’optimisation des syst` emes informatiques.

Sommaire

3.1 Principes et m´ ethodes . . . . 25 3.1.1 Principes . . . . 25 3.1.2 M´ ethodes de r´ esolution des probl` emes d’optimisation . . . . . 26 3.1.3 Quelques m´ ethodes d’optimisation . . . . 28 3.2 Optimisation des syst` emes informatiques . . . . 31 3.2.1 Optimisation en informatique . . . . 31 3.2.2 Param` etres et niveaux d’optimisation . . . . 32 3.3 Approches « m´ etier » d’optimisation . . . . 33

3.3.1 Oracle et l’optimisation des Syst` emes de gestion de bases de donn´ ees . . . . 34 3.3.2 IBM et l’optimisation des serveurs d’application . . . . 36 3.3.3 Optimisation ` a base de points d’attente . . . . 38 3.4 Conclusion . . . . 40

L ^e mot optimisation est d’origine latine, d´ eriv´ e du mot Optimum qui signifie le meilleur.

L’optimisation est originalement une branche des math´ ematiques qui sert ` a analyser et ` a r´ esoudre analytiquement ou num´ eriquement les probl` emes qui consistent ` a d´ eterminer le meilleur ´ el´ ement d’un ensemble, au sens d’un crit` ere quantitatif donn´ e.

De nos jours, les applications de l’optimisation sont innombrables. Chaque proces- sus qu’il soit en industrie, en ´ economie en sciences ou en ing´ enierie est potentiellement

23

optimisable, et peut donc tirer profit des m´ ethodes d’optimisation.

Aujourd’hui il n’y a pas d’entreprise qui ne soit impliqu´ ee dans la r´ esolution de pro- bl` emes d’optimisation [Tal09]. En effet, de nombreuses applications difficiles dans les sciences et l’industrie peuvent ˆ etre formul´ ees comme des probl` emes d’optimisation. Dans les r´ eseaux de communication, et afin d’optimiser les coˆ uts et la qualit´ e de service il faut d´ eterminer les configurations ou les topologies. Dans les syst` emes de production il existe plusieurs fa¸cons d’ordonnancer les tˆ aches afin d’optimiser le temps de fabrication. En sciences biologiques, il existe plusieurs fa¸cons de d´ efinir la forme 3D d’un prot´ eine pour optimiser l’´ energie.

En sciences de l’ordinateur, et depuis l’apparition des premi` eres machines calculateur l’optimisation est pr´ esente partout et sur tout le niveau : optimisation du mat´ eriel (i.e. cir- cuits, cartes m` ere, m´ emoire, processeur, interfaces r´ eseaux, .etc) ou optimisation logicielle (i.e. algorithmes, langages, frame-works, .etc).

L’accroissement de la puissance des machines de derni` ere g´ en´ eration (depuis pratique- ment le d´ ebut des ann´ ees 70) a ´ et´ e accompagn´ ee par une ´ evolution dans le monde de conception et de d´ eveloppement des syst` emes informatiques. Ces syst` emes sont devenus distribu´ es avec plus de capacit´ e de traitement. Le World Wide Web est un des exemples de cette (r)´ evolution.

Dans de tels syst` emes de plus en plus complexes (plates-forme, architectures et pro- tocoles plus complexes qu’auparavant), l’ouverture partielle ou totale de ces syst` emes et applications sur les r´ eseaux, et une capacit´ e assez limit´ ee d’administration, de configu- ration et de gestion de ces application dans un contexte en mouvement et en ´ evolution permanents et soumis ` a des charges non contrˆ olables et non maitris´ ee.

L’optimisation d’un syst` eme informatique quelconque concerne essentiellement son fonctionnement, elle peut signifie l’assurance maximale de la disponibilit´ e du service cens´ e ˆ

etre offert par le syst` eme surtout dans des situations critiques, elle peut signifie aussi l’am´ elioration du temps de r´ eponse du syst` eme, comme elle peut signifie la maximisation de la capacit´ e du traitement parall` ele du syst` eme en question.

Dans la pratique, quand on parle d’optimisation d’un syst` eme d’information, on entend par cela l’am´ elioration de ses performances. Les performances d’un syst` emes sont mesur´ ees (ou calcul´ ees) en terme d’un indice de l’´ etat actuel du syst` eme (i.e. d´ ebit, temps de r´ eponses, nombre de clients, nombre de requˆ etes trait´ ees , .etc) 2.1.

La complexit´ e des syst` emes informatiques rend difficile et complexe la tˆ ache d’am´ e-

lioration de performances de ces syst` emes. De toutes mani` eres l’optimisation de perfor-

mances est un travail quotidien concerne pratiquement tout les m´ etiers de l’informa-

tique(d´ eveloppeurs, int´ egrateurs, responsables de mise en production, administrateurs

3.1. Principes et m´ ethodes 25 syst` eme ou r´ eseaux, .etc) et touche plusieurs niveaux de l’application en question et cela tout au long de son cycle de vie. Nous consacrons une section ` a l’optimisation en infor- matique 3.2 et pr´ esentons trois approches m´ etier d’optimisation de syst` emes informatique dans la section 3.3 avant de conclure ce chapitre par le concept d’auto-optimisation des syst` emes informatiques.

3.1 Principes et m´ ethodes

3.1.1 Principes

D´ efinition 3.1.1 Optimiser la fonction f sur A , consiste ` a trouver l’´ el´ ement x <sub>0</sub> de A tel que pour tout ´ el´ ement x de A , f (x) est major´ ee par f (x <sub>0</sub> ) (s’il s’agit d’une maximisation) et minor´ ee par f(x <sub>0</sub> ) (s’il s’agit d’une minimisation). De mani` ere formelle, nous avons donc pour un probl` eme de maximisation :

f : A → R ∃?x ₀ ∈ A , ∀x ∈ A, f (x ₀ ) ≥ f (x) (3.1) et pour un probl` eme de minimisation :

f : A → R ∃?x ₀ ∈ A , ∀x ∈ A, f (x ₀ ) ≤ f (x) (3.2) La fonction f est appel´ ee fonction objectif et les ´ el´ ements de l’ensemble A sont appel´ es solutions admissibles. L’´ el´ ement f(x ₀ ) est appel´ e Optimum ou solution optimale. Lorsque l’ensemble A ⊂ R ⁿ , on parle d’optimisation multivariables.

Nota : Un probl` eme d’optimisation combinatoire est susceptible d’avoir plusieurs so- lutions optimales.

D´ efinition 3.1.2 (Optimisation multiobjectifs) Lorsque la fonction objectif n’asso- cie pas une valeur num´ erique, mais un point d’un ensemble c.` a.d. elle est associ´ ee ` a un vecteur, dans ce cas on parle de l’optimisation multiobjectifs. Le but est alors d’optimiser simultan´ ement l’ensemble des composantes de ce vecteur.

On peut aussi voir l’optimisation multiobjectif comme un ensemble de probl` emes d’opti- misation portant sur les mˆ emes param` etres, ayant des objectifs ´ eventuellement contradic- toires, et que l’on cherche ` a r´ esoudre au mieux.

Nous n’abordons pas le sujet de l’optimisation multiobjectifs dans le pr´ esent manuscrit,

nous nous contentons donc dans le reste des sections par l’´ etude des mod` eles et m´ ethodes

d’optimisation ayant un seul objectif d’optimisation. La section suivante montre les deux m´ ethodes de r´ esolution possibles pour tout probl` eme d’optimisation.

3.1.2 M´ ethodes de r´ esolution des probl` emes d’optimisation

3.1.2.1 R´ esolution exacte

C’est des m´ ethodes d´ eterministes permettant de r´ esoudre certains probl` emes d’une mani` ere exacte en un temps fini. Ces m´ ethodes d’optimisation explorent de fa¸con syst´ e- matique l’espace de recherche. Souvent on parle des m´ ethodes arborescentes car elles se basent sur un parcours d’arbre afin de trouver la solution optimale, les nœuds de l’arbre sont les affectations des valeurs des variables du probl` eme.

Ces m´ ethodes n´ ecessitent g´ en´ eralement un certain nombre de caract´ eristiques de la fonction objectif, comme la stricte convexit´ e, la continuit´ e ou encore la d´ erivabilit´ e. On peut citer comme exemple de m´ ethodes de r´ esolution de ce type de fonction : la pro- grammation lin´ eaire, quadratique ou dynamique, la m´ ethode du gradient et la m´ ethode de Newton.

Parmi les m´ ethodes exactes, on trouve la plupart des m´ ethodes traditionnelles (d´ eve- lopp´ ees depuis une trentaine d’ann´ ees) telles les techniques de s´ eparation et ´ evaluation (branch and bound), ou les algorithmes avec retour en arri` ere (backtracking). Les m´ ethodes de r´ esolution ` a base de solveurs de contraintes font partie de cette cat´ egorie de m´ ethodes, car la majorit´ e des solveurs de contraintes impl´ emente des algorithmes de type branch and bound et de backtracking lors de la construction de l’arbre de solutions. Les m´ e- thodes exactes permettent de trouver des solutions optimales pour des probl` emes de taille raisonnable. D` es que la taille du probl` eme soit plus grande le temps de calcul n´ ecessaire pour trouver une solution risque d’augmenter exponentiellement et donc ces m´ ethodes montrent des difficult´ es avec les applications de taille importante.

Notons en fin, qu’il existe des logiciels g´ en´ eriques tel que : AMPL [FGK02] qui est

un langage de mod´ elisation pour la programmation math´ ematique qui simplifie la mod´ e-

lisation et la formulation des probl` emes d’optimisation compliqu´ es, la r´ esolution de ces

mod` eles peut ˆ etre faite ` a l’aide de plusieurs logiciels tel que : CPLEX [IBMa] qui est

un solveur d’optimisation d’IBM pour la programmation lin´ eaire mixte et quadratique,

LINDO [LIN] qui est un logiciel d’optimisation pour la programmation en nombres en-

tiers, lin´ eaire, non-lin´ eaire, stochastique et globale, MPL [Max] et XPRESS [FIC] qui est

l’un des logiciels priv´ es de la programmation lin´ eaire et en nombres entiers les plus utilis´ es

sur le march´ e.