Groupe Eyrolles, 2004, ISBN : 2-212-11395-1

Groupe Eyrolles, 2004, ISBN : 2-212-11395-1

Chapitre 3 modélisation Du test en charge à la L analyse des performances L analyse des performances est l étude du comportement d un système informatique en termes de ressources et de propriétés mesurables. Les techniques d analyse des performances sont utilisées pour déterminer la capacité d une architecture d un système informatique à supporter la charge et pour identifier les parties de l architecture où des problèmes de performance sont susceptibles de se produire. [26] Modèle de charge Relie le business et les performances Exigences Savoir quoi analyser en premier Objectifs Ce que les performances doivent être Modélisation Ce que les performances pourraient être Tests en charge Ce que les performances sont Performance et mesures Une approche pragmatique et proactive des performances Figure 24. La modélisation, méthode complémentaire des tests en charge. Les propriétés mesurables et la nature des ressources à analyser peuvent varier en fonction du système à étudier. En ce qui concerne les systèmes informatiques, les paramètres typiques sont les temps de réponse de bout à bout, le volume du trafic réseau, l utilisation des processeurs et le nombre d utilisateurs correspondant au volume de requêtes traitées. Cette liste n est pas exhaustive : beaucoup d autres propriétés d un système peuvent également influer sur les performances. L analyse des performances a pour objet de déterminer comment les systèmes se comportent dans certaines conditions. Elle peut être employée pour comparer différentes architectures d un système afin d évaluer leurs 39

mérites respectifs en termes de ressources nécessaires à la réalisation d objectifs et d exigences prédéterminées par les spécifications de l entreprise. Sont exclus du cadre de l analyse des performances les problèmes concernant l exploitation, la maintenabilité et la vérification de l exactitude fonctionnelle des applications. Ce sont des éléments importants qui concernent d autres métiers intervenant dans les processus de conception et de réalisation. Une architecture acceptable d un point de vue des performances peut être inacceptable selon tout ou partie des autres points de vue. De même, une architecture qui satisfait aux critères d exploitabilité peut ne pas être acceptable du point de vue de ses performances et devoir être révisée. L analyse des performances doit être perçue comme une discipline qui complète la famille des fonctions plus traditionnelles intervenant lors de la conception et du développement des systèmes informatiques, et qui ne les remplace pas. Elle est utilisée pour assister les autres disciplines à fournir des systèmes qui satisfont aux objectifs de performances spécifiés. L analyse des performances est multidisciplinaire et comprend : la compréhension des architectures et des technologies : une compréhension dynamique et expérimentale des technologies utilisées et de l architecture d un système à étudier est indispensable pour savoir le superviser, le modéliser, l évaluer avec pertinence, et produire des rapports circonstanciés ; la réalisation des tests en charge ; la modélisation des performances ; le capacity planning ; la gestion de la qualité de service, c est-à-dire comprendre les attentes des acteurs d un processus métier au cours de la négociation du contrat de service (SLA), définir les niveaux de service, surveiller, une fois l application déployée, que le contrat est bien respecté, et établir des rapports concis, clairs et compréhensibles par tous les acteurs. Nous ne nous intéresserons pas ici à la dernière discipline, dont le but est de superviser les performances des systèmes informatiques après leur mise en production. 40 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

Le test en charge et le benchmarking Les problèmes de performance sont consécutifs à des événements prévisibles ou imprévisibles. Ainsi, les tests de performance devraient être conçus autour de ces deux types d événements. Mais comment la performance estelle testée? Avec tant de variables, comment pouvons-nous en réalité mesurer la performance d un site Web, d une architecture ou d un système? Dans son sens le plus large, le test de performance permet d observer et d évaluer les réponses d un projet dans toutes les conditions de charge possibles pendant toutes les périodes possibles. Lorsque des incidents apparaissent durant les tests, les informations sont analysées avec la collaboration de l ensemble des acteurs du projet. Le test en charge ou le benchmarking sont des activités qui appartiennent aux domaines de la vérification et de la validation. Ils permettent de s assurer qu un système est conforme à ses spécifications. Tous les mois, des dizaines de magazines informatiques à grand tirage présentent des bancs d essais comparatifs de processeurs, de cartes-mères ou de cartes vidéos. Un benchmark est un ensemble de programmes étalons (banc d essai) permettant de mesurer la capacité d un composant ou un ensemble de composants. Afin que les fournisseurs ne puissent pas afficher des chiffres avantageux, les conditions de tests sont strictes, toujours les mêmes et vérifiées par une autorité indépendante. Ces bancs d essais existent également pour le matériel destiné aux entreprises. On les appelle «benchmarks» ; il en existe deux catégories principales : Les benchmarks au niveau processeur. Ils sont organisés et contrôlés par des autorités indépendantes des fournisseurs et permettent de comparer la puissance des machines. Le principal organisme est le Standard Performance Evaluation Corporation, dont le premier benchmark comparatif des processeurs date de 1989 (unité reconnue de comparaison : SpecINT). Citons également Whetstone ou Dhrystone. [35] Les benchmarks au niveau système. Différents organismes comparent les performances des serveurs informatiques complets soumis à de véritables applications de tests. L organisme le plus répandu est le Transaction Performance Council, dont le premier benchmark comparatif des processeurs date de la fin des années 1980 (unités reconnues de comparaison : tpmc et $/tpmc) Figure 25. Le benchmark : l étalon ou banc d essai de performance. Le terme «benchmark», lorsqu il est utilisé dans le domaine des tests en charge, décrit un test en charge permettant d évaluer les performances d un système informatique (ensemble composé de 1 à M machines, de 1 à N 41

logiciels, de 1 à P réseaux). Le benchmarking est en général associé à une notion de comparaison de plusieurs solutions à un problème posé. Vérification de l'ihm Test de compatibilité Validation des champs Test de profil Validation niveau global Test IHM Stratégie de test Test de scripts de BdD Test destructif Consistance de l'ihm Test de stress Test contrôle standard Test de performance Test fonctionnel Les tests de charge Tests de scénario Tests négatifs Figure 26. Les tests de charge et la stratégie de test. Le test en charge consiste à réaliser et à mettre en œuvre un logiciel spécifique de tests qui permettra de vérifier que, sous les conditions décrites, le système est capable de fonctionner correctement, et d en connaître les limites. Un système à tester Afin de quantifier la représentativité du comportement d un système à tester, il est nécessaire de définir un certain nombre de paramètres d entrée, intermédiaires ou de sortie, censés représenter l état du système. Il convient alors de comparer, pour ces paramètres représentatifs, les valeurs obtenues en simulation avec celles obtenues lors des essais réels pour des scénarios ou jeux de paramètres d entrée identiques. Entrées Sorties Utilisateurs -type, nombre État de l'application Contexte technique - serveurs, réseaux, stations Application Stations Réseaux Serveurs Activités applicatives Temps de réponse Activités systèmes Figure 27. Les paramètres du système à tester. 42 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

Lors d un test en charge, différents paramètres sont à prendre en compte : le contexte informatique : le système à tester, matériel (une ou plusieurs machines, pour chaque machine d une ou plusieurs configurations différentes), et logiciel (des traitements des données, des requêtes utilisateur, des traitements par lots) ; le contexte d essais : une organisation des traitements effectués sur le système ces traitements sont supposés être représentatifs d un fonctionnement type du système ; le contexte de performance : un procédé de métrologie pour caractériser la charge informatique générée par le contexte d essais, il faut tenter de la quantifier à l aide de diverses mesures réalisées sur les composants du système à tester ; des outils d évaluation des performances du système informatique : les mesures s effectuent à l aide d outils non intrusifs ou intrusifs par rapport aux paramètres à observer (les outils intrusifs peuvent modifier les performances de fonctionnement du système à tester). La notion de performance Dans la théorie des systèmes asservis, on distingue trois types de performances : performance du processus, précision et stabilité. Performances d'un système de commande Performance du processus transitoire Précision Stabilité Figure 28. Les trois types de performance. Les performances d un système sont obtenues en introduisant à son entrée un signal de test. En général, il est déterminé par sa réponse indicielle. Ce type de réponse est facile à obtenir, de plus, pratiquement tous les systèmes réagissent à un échelon. [32] Dans un système asservi en réalité, il ne faut pas systématiquement donner préférence à un résultat donné, mais plutôt considérer un compromis sur les attendus qui dépendent surtout de la nature du système physique à commander. Par exemple, il ne faut pas seulement privilégier le nombre maximal d utilisateurs à atteindre car cela peut induire une dégradation du temps de réponse par utilisateur. 43

Réaction Régime transitoire Régime permanent Stimulus Temps Figure 29. Un graphique représentatif des deux phases de tests en charge. Sur le schéma (figure 29) deux phases typiques composent le test en charge : le régime transitoire : la phase de montée et d oscillation ; le régime permanent : la phase considérée comme plus stable. s(t) s(t) Système stable t Système instable t Figure 30. La stabilité et l instabilité. Un système en charge est stable si sous une charge injectée, il n y a pas de variation importante des valeurs dites «de sortie». Cela introduit indirectement la notion de domaine de fonctionnement d un système. Les zones de fonctionnement et de non-fonctionnement Une valeur d entrée est une valeur appliquée à un système indépendante des autres valeurs du système. Une valeur de sortie est fournie par le système en fonction des valeurs d entrée. Chaque entrée peut provoquer des variations sur les sorties. L analyse comportementale d un système complexe à travers un test en charge doit permettre de découper l espace des entrées en zones de fonctionnement homogènes. Une zone de fonctionnement homogène caractérise l ensemble de cas produisant des sorties appartenant majoritairement à une des classes de la sortie caractéristique du système. Là encore, le choix de la sortie, ainsi que les règles de classification qui lui sont appliquées sont fondamentaux dans 44 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

la démarche car le comportement du système n est alors plus vu qu au travers de la classe d appartenance de la sortie étudiée. En synthèse, si le résultat de sortie n appartient pas à la classe attendue, le système est supposé ne pas fonctionner. La non-linéarité évidente du fonctionnement des systèmes complexes, ainsi que la recherche des paramètres les plus influents sur son comportement, devraient pousser les maîtrises d œuvre à construire un graphe d état du système représentant le comportement du logiciel. En général, seule la structure des graphes est exploitée, notamment pour détecter les interblocages et connaître notamment le franchissement des transitions. A D F ADG ADF AEF B G B E H BDG BDF BDF Figure 31. Des automates modélisant un système et un extrait du graphe d état global. Avant de commencer les tests, il faut identifier les critères passe/échoue pour évaluer ce que sera la performance réelle. Trop souvent, les tests commencent sans que les testeurs comprennent ce qui devrait être testé. Autrement dit, il faut connaître les conditions de démarrage du test pour déterminer ce qui doit être mesuré ou testé. C est ce qui permet de déterminer si un test passe ou échoue. Ainsi, tester en charge un système revient à tracer les lignes entre les espaces de fonctionnement et de non-fonctionnement. Zone de non-fonctionnement Zone de fonctionnement Figure 32. La zone de fonctionnement. 45

Tenir la charge et définir son évolution Les systèmes ont des ressources limitées. Par exemple, la capacité de calcul d un serveur, la capacité de parallélisme des processus et des modules de traitement (thread) sont limitées. Pour savoir si un système informatique va tenir la charge il faut étudier l évolution de divers paramètres de sortie du système et de leurs interactions. Si l on observe théoriquement l évolution des temps de réponse et du débit en fonction de la charge, il est possible de distinguer deux cas : le système parfait : quelles que soient les entrées, les sorties restent stables ; le système réel : rien ne se perd, rien ne se crée, tout se transforme et les temps de réponse ont tendance à croître lentement jusqu à un seuil où l évolution devient exponentielle ; quant au débit de traitement, il croit tant qu il peut, se stabilise, puis s écroule. Pour s assurer qu un système va tenir la charge, il faut effectuer divers essais afin de mesurer l écart selon les deux courbes types de la figure 33. Puis, il faut obtenir des informations sur l état de «santé» du système et sur son comportement. Il est possible de trouver des erreurs, des dysfonctionnements lors des tests en charge. Tout comportement non décrit dans les spécifications doit être noté. Le débit de traitement du système peut être un comptage des actions métier effectuées, un comptage de valeurs représentatives de l activité de l applicatif, des écrans, des pages Web, des hits. Temps de réponse Système réel Débit Système parfait Système parfait Système réel Charge en entrée Charge en entrée Figure 33. Le temps de réponse et le débit : les deux cas. Tracer la courbe de la figure 34 revient à effectuer plusieurs essais en faisant évoluer deux variables : la charge injectée et le nombre d utilisateurs servant à générer la charge correspondante. Pour s assurer que le système offre toujours de bonnes performances, il suffit de tracer la courbe et de préciser les zones qui sont considérées comme valables par rapport aux besoins définis dans le cahier des charges du système. 46 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

Temps de réponse Inacceptable Acceptable Charge injectée 1 essai Nombre d'utilisateurs Figure 34. Le temps de réponse selon le nombre d utilisateurs et la charge. Des opérations d optimisation peuvent amener la courbe des performances dans la zone acceptable (voir figure 35). Temps de réponse Performances initiales Performances améliorées Charge actuelle Charge à la cible Inacceptable Acceptable Nombre d'utilisateurs Figure 35. L évolution résultant d une optimisation. La surveillance de l utilisation des ressources système grâce à des courbes telles celles de la figure 36 permet d identifier des limites imposées par ces ressources, voire la sous-utilisation de certaines ressources. Valeurs système Accès réseau Mémoire Unité centrale Accès disque Nombre d'utilisateurs Figure 36. La consommation de ressources en fonction du nombre d utilisateurs. 47

Les différents types de tests en charge Les systèmes asservis sont généralement soumis aux signaux de tests comme illustré par la figure 37. Il est possible de classer les tests selon les catégories suivantes : les tests des accès concurrents : vérification de la réponse impulsionnelle ; les tests en charge (nominal et autour) : réponse indicielle et en vitesse ; les tests aux limites (au-delà du nominal) : réponse en vitesse ; les tests d endurance. Excitation Réaction Impulsionnelle Indicielle Vitesse Figure 37. Les systèmes asservis et les signaux de test. Trois types de charges transactionnelles sont généralement effectués : le fonctionnement en palier simple ; la variation au niveau de la montée en paliers (palier en escalier) ; la prise en compte de rafales (phases de stress) une fois le palier établi. Fiabiliser le système nécessite de s assurer d une part que quelle que soit la pente de charge le système pourra la gérer, et d autre part que les pentes non supportées par le système ne sont pas probables en production. Les tests des accès concurrents En ce qui concerne les utilisateurs asynchrones, il n y a pas de cohérence d ensemble dans le comportement des utilisateurs simulés. C est ce qui est observable dans la réalité : les utilisateurs travaillent à leur rythme, indépendamment les uns des autres. En ce qui concerne les utilisateurs synchrones, il y a une cohérence d ensemble dans le comportement des utilisateurs simulés. Cela peut s observer lors de la reconnexion au système suite à une panne : des cas de 48 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

synchronisation forte peuvent alors être observés, avec génération d un pic d activité. Utilisateurs A B C Figure 38. Des utilisateurs asynchrones et des utilisateurs synchrones. Temps Pour deux traitements A et B s exécutant en parallèle, il est possible de distinguer différents cas d exécution, comme illustré à la figure 39. Les tests de simultanéité ou de concurrence consistent à faire exécuter en parallèle des transactions afin de trouver la limite du système lors de la montée en charge simultanée. A et B séquentiels A B et B A A et B en parallèle en un point A B et B A A et B en parallèle à n/10 A B et B A A et B en parallèle total A B Temps Figure 39. Du parallélisme entre traitements. Si l on considère deux traitements concurrentiels, équivalents ou différents, il faudra, pour être sûr de leur bon déroulement, les faire exécuter selon tous les cas préalablement cités : l ordre entre deux traitements entre en ligne de compte dans la recherche des cas de dysfonctionnement. [4] Les tests à la charge nominale Effectuer la montée en charge d un système revient à faire exécuter le profil de charge suivant : 49

montée en charge progressive, connexion progressive des utilisateurs ; palier de fonctionnement, avec la possibilité d une variation de durée des transactions (par exemple, de 10 secondes à 3 minutes) ; décroissance progressive de la charge. Nombre de stations actives... Une connexion toutes les x secondes Une déconnexion toutes les y secondes Temps de fonctionnement Figure 40. La variation des montées en charge. Il est indispensable d effectuer différents essais, en faisant varier le nombre d utilisateurs et la fréquence de soumission des transactions. On peut faire varier la pente de charge en fonction de la durée : l élément variable est le laps de temps entre deux connexions. Les courbes de charge versus temps de réponse peuvent alors être tracées : elles permettent de vérifier la capacité de tenue en charge. Le test à la charge nominale consiste à injecter une charge représentative de la charge «standard» attendue en production. On considère une journée d utilisation standard (hors événement particulier) et on simule la charge de cette journée, réduite sur une période courte (généralement deux heures). Les résultats d un test en charge déterminent si la configuration du système (serveur Web, serveur d applications, base de données, bande passante de réseau) satisfait les exigences normales de performances pour ce projet. Il permet de déterminer les temps de réponse moyens typiques. Mis en œuvre tôt dans le cycle de développement, ce test peut aussi aider à établir la faisabilité ou la pertinence d une architecture particulière avant d investir dans des équipements et des développements qui s avéreraient incompatibles dans l usage réel. L afflux d une forte charge nominale ne doit pas provoquer l écroulement du système, sinon celui-ci est jugé non robuste. 50 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

Les tests de stress ou aux limites Le test de stress est utilisé pour déterminer si la configuration du système a la capacité de supporter un fonctionnement acceptable pendant le pic des heures d affluence. De plus, le test de stress est utilisé pour déterminer ce qui arrivera quand la capacité maximale du projet sera atteinte ainsi que l élément dimensionnant du système. Supposons, par exemple, que le système ne puisse supporter que 100 utilisateurs simultanés. Que va-t-il se passer quand arrivera le 101 ème? Il faut le savoir à l avance, puisque la performance du système devrait théoriquement se dégrader lentement et d une manière prévisible. Il faut donc comprendre comment le système réagira quand il travaillera au-delà de sa capacité. Une attention toute particulière doit être portée sur l intégrité fonctionnelle du système et de ses données pour s assurer que ses fonctions opèrent toujours correctement, même avec des charges dépassant les limites prévues. Qu arriverait-il si, en raison de charges excessives, le système calculait inexactement une opération toutes les 1000 transactions? La mise en œuvre d un crash test permet de répondre à ce type de question. Selon les circonstances, l impact d une surcharge peut être minimal ou catastrophique. Lorsque l impact du test de stress est important au point d entraîner la saturation totale du système en fin de test, il faut mesurer l intérêt du test avant de le réaliser. En effet, la durée de la restauration est parfois plus longue que le délai accordé pour réaliser les tests. Le test de stress aide à éviter une situation potentiellement désastreuse. Cela est particulièrement important lorsque le système utilise des répartiteurs de charge ou la réplication de données pour améliorer la performance. Les cas de tests doivent alors inclure les possibilités de conflits et il faut savoir comment le système les résout. Les tests de stress incluent les transactions qui réalisent des tests non seulement sur l unité centrale mais également sur les dispositifs d entrée/sortie et les systèmes de gestion des bases de données. Ces tests ont deux buts essentiels : trouver quand et où le système tombe, et analyser ce qui arrive quand il tombe. Cependant, certains de ces cas de tests peuvent ne pas être applicables à tous les systèmes : les cas de tests de stress dépendent fortement de la nature spécifique de l application. 51

Les tests de pic/rebond Le pic des heures d affluence peut se produire n importe quand. Une analyse des systèmes transactionnels classiques montre que les périodes de charge se situent entre 9 heures et 12 heures et entre 14 heures et 16 heures en Europe. Pour des sites de bourse en ligne, les pics se situent immédiatement après l ouverture et immédiatement avant la fermeture des marchés. Les tests de pic ou de rebond font partie des tests de stress. Ils sont liés à des variations de la distribution d arrivée des requêtes : à un instant donné il peut y avoir une arrivée massive et quelques minutes après un retour vers une faible charge. Les rebonds de la charge permettent, avec leurs variations hautes et basses, de mieux déterminer comment le système supporte les pics. Les tests de pics sont l équivalent de la prévision d ouragans en météorologie. Les prévisionnistes se demandent toujours quand la tempête arrive-t-elle, où sera-t-elle la plus puissante et quelle sera la force du vent? La tempête qui soufflera sur un site Web, bien que quelques systèmes soient plus susceptibles de subir des rafales que d autres, est une combinaison d événements prévisibles ou non de caractère mondial tels que les vacances, les dernières nouvelles importantes ou les événements spéciaux, et les publicités sur des produits, qui génèrent des pics «imprévisibles» ou des attaques volontaires. D où la question existentielle pour un testeur : Quand le pic aura-t-il lieu et quelle sera sa force? Les pointes sont caractérisées par les arrivées aléatoires et massives de clients ou de requêtes qui excèdent significativement des moyennes normales. Un site Web peut subir une croissance de charge exceptionnelle au cours d un laps de temps très court. Même lorsqu un site Web est capable d encaisser une forte charge, la nature soudaine d un pic de charge peut générer de sérieux problèmes. Certains sites Web ne peuvent pas gérer de telles montées en pic et il convient d effectuer des essais de pic qui mettent en œuvre à la fois la phase de connexion et la phase d exécution de transaction : variation de vitesse dans la montée en charge ; montée en charge suite à l atteinte d un palier ; connexion/déconnexion des utilisateurs une fois le palier atteint. 52 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

La montée en charge Lors des tests de montée en charge, il convient de distinguer deux phases : la montée en charge et le palier (régime stationnaire). Le point à surveiller dans la phase de montée en charge est la pente de connexions simultanées effectuées par les utilisateurs : comme le Web utilise un protocole a priori non connecté, cette pente est matérialisée par chaque demande de page. Le profil de charge nécessaire à la réalisation de ces tests est similaire à celui décrit précédemment. Il suffit de reprendre les tests précédents et de raccourcir la phase de montée en charge (par exemple : une nouvelle station active toutes les 2 secondes au lieu de toutes les 30 secondes). Cette accélération permet de vérifier que le système est bien dimensionné pour supporter le nombre d utilisateurs simultanés prévu. Nombre de stations actives 100 toutes les 1 s 10 toutes les 1 s 1 toutes les 1 s Temps Figure 41. Des exemples de taux de montée en charge. Plusieurs cas sont possibles. Montée en charge suivie d un retour à la charge nominale : profil de sûreté pour un portail. Montée en charge suite à l atteinte d un palier : à partir d un palier atteint, une nouvelle montée en charge a lieu. Ce cas permet de simuler, par exemple, le décalage d activité de deux centres supposés se connecter au même système : le mélange des deux charges (connexion et palier) ne doit pas provoquer l écroulement du système. Connexion/déconnexion des utilisateurs : à partir d un palier atteint, il y a oscillation au niveau des connexions et des déconnexions. Ce profil de charge permet de simuler le phénomène de déconnexion par inactivité que l on rencontre sur certains systèmes. Prise en compte de rafales : à partir d un palier atteint, une nouvelle montée en charge a lieu, le plus rapidement possible. Ce profil de charge permet de simuler, par exemple, l afflux rapide d appels dans un centre d appels générant un travail supplémentaire pendant une période courte. 53

Nombre de stations actives Charge nominale Portail Palier Temps de fonctionnement Connexion/déconnexion Rafales Figure 42. Les profils de montée en charge. Les tests d endurance Les tests d endurance sont là pour simuler une période de production classique. Certains problèmes se manifestent au bout d un certain temps. Ils sont de type famine de ressources comme le manque de mémoire (fuite mémoire) ou la non-libération de ressources applicatives. La modélisation des performances Aujourd hui, les systèmes informatiques, qui reposent sur des architectures de type N-tier, sont constitués d un grand nombre de plates-formes et de technologies différentes. Les clients légers (navigateur, déport d interface) sont situés sur des stations de travail connectées à un réseau souvent hétérogène et de grande échelle. Des serveurs dédiés peuvent exister pour chaque fonctionnalité (par exemple, serveurs d applications Web sous Unix, serveurs de fichiers de type Filer utilisant un système d exploitation propriétaire). Le temps d accès aux données sur disque diminuant moins rapidement que la croissance de la capacité de traitement des processeurs (loi de Moore), les éléments de stockage sont de plus en plus souvent importants et mutualisés sur des baies ou des bandes externes, voire déportés géographiquement et utilisés via des middlewares de communication à forte capacité. Lorsqu il s agit d évaluer les interactions entre toutes ces ressources matérielles, les équipements réseau, des données jusqu aux utilisateurs, il apparaît que les flux à considérer sont à la fois nombreux et complexes. Le comportement du système tout entier ne peut être prédit par simple inspection ou application numérique d une formule mathématique 54 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

générique, comme cela peut se faire sur des systèmes homogènes situés sur une plate-forme unique. Dans le monde du client-serveur et des applications N-tier, il n est pas évident d identifier les goulots d étranglement et les principaux facteurs déterminant les performances des services applicatifs. Ce qui motive le développement de modèles de performances, c est la possibilité de capturer l essence du comportement d un système réel et de le représenter dans un modèle afin de gagner en perspicacité dans la compréhension de ce comportement. Une fois le modèle d un système établi, il devient possible de l expérimenter et de déterminer alors les facteurs limitant ses performances. Cela permet de suggérer des améliorations pertinentes sur la structure du vrai système afin d en améliorer les performances. Dans le monde réel, une telle expérimentation est difficilement réalisable, et ce pour plusieurs raisons : le système peut ne pas encore exister et en être à la phase de conception ; le système peut être trop complexe pour être reproduit sur plate-forme ; le réseau peut constituer le goulot d étranglement du système ; il est souvent trop coûteux de dégrader la cohérence d un système sur une base purement spéculative. La disponibilité d un modèle de performances permet d identifier des problèmes de dimensionnement, de capacité et de temps de réponse tôt dans le cycle de vie d un projet, bien avant de déployer le système en production, et bien sûr avec plus de fiabilité qu en se fondant sur son intuition. Sans cette approche, le risque est de ne pas ou de mal identifier les goulots d étranglement réels du système. La tentation est alors de se fonder sur l intuition, laquelle est souvent trompeuse. En l absence d un modèle de performances, il est fort probable que des sommes d argent importantes seront dépensées inutilement pour «améliorer» des parties du système qui n ont que peu d influence sur les performances globales de l application. L argent investi aura alors été gaspillé. C est ce qu IBM appelle l e-panic quand un problème de performances conduit quasi systématiquement les managers à ajouter des processeurs ou des lignes réseau sans que la cause du problème soit identifiée. La modélisation des performances fournit un moyen relativement peu coûteux d évaluer l impact de différentes configurations de système sur les performances. L effort à fournir dans un projet de modélisation ne doit cependant pas être sous-estimé. Les gains potentiels liés à l absence de réingénierie ou de modification de la conception d un système grâce à la mise 55

en œuvre du modèle de performances tôt dans la vie du projet font plus que justifier son coût. La modélisation d une application de type client-serveur ou N-tier a pour objectif de comprendre le comportement dynamique d un système et d en évaluer les facteurs sensibles (par exemple, le nombre maximal de threads) et les principaux paramètres de performances (temps de réponse, utilisation, débit de traitement). La modélisation des performances et le capacity planning Les enseignements tirés de l expérience acquise à France Télécom sont donnés ci-après. Modélisation La modélisation des performances offre une vue d ensemble sur les solutions étudiées, qui peuvent impliquer beaucoup de serveurs et des réseaux hétérogènes multiples. Ainsi, la modélisation des performances permet de prévoir les temps de réponse de bout en bout perçus par l utilisateur final. La modélisation des performances se positionne sur l analyse proactive et ponctuelle des performances tôt dans le cycle de vie d un projet (préproduction) en garantissant que les calculateurs à déployer satisferont aux objectifs de performance spécifiés, et ce sans interrompre les systèmes en exploitation. La modélisation des performances utilise le processus de capacity planning pour injecter des données permettant de valider ses modèles et transmettre les résultats de ses modèles aux équipes de capacity planning pour mise à jour lors des évolutions du système Capacity Planning Le capacity planning s intéresse à l impact d évolutions existantes de la charge sur un environnement de production spécifique et permet de prévoir l évolution de la capacité de systèmes appartenant à une plate-forme spécifique ainsi que les durées internes de traversée de ces systèmes pour une transaction applicative donnée. Le capacity planning est un service récurrent qui vérifie régulièrement la capacité d un système en production en planifiant les upgrades du système. Figure 43. La distinction entre la modélisation et le Capacity planning. 56 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

Le capacity planning est plus rentable et efficace s il est réalisé avant le déploiement du système. Les problèmes de performance résultant d un manque de capacité sont plus complexes et coûteux à résoudre après le déploiement. Le capacity planning fournit des informations nécessaires à la définition des exigences futures en termes de nouveaux équipements informatiques, de capacité réseau supplémentaire ou de nouveaux besoins relatifs à l infrastructure technique. Une organisation indépendante et spécialisée dans les architectures des applications Web est la garantie d une analyse objective des exigences en termes de ressources applicatives : en conséquence, cela permet de préparer de manière adéquate le système et le réseau au trafic spécifié. La modélisation des performances apporte une plus-value complémentaire aux tests en charge. Le nombre de demandes en amont du cycle de vie des projets qui permettent de fournir une vue globale sur les performances d un projet ne cesse d augmenter. Il est prévisible que nous aurons bientôt besoin de prévoir des outils et des méthodes permettant de transmettre et de pérenniser nos modèles pour les équipes de supervision en production. Marché Services, réseau, système À quelle vitesse la charge va-t-elle augmenter? Quelle est la QoS du service, du réseau, du système? Comment améliorer le service? Prévision Monitoring Architecture, conception Quelles sont les demandes des clients? Avec quelle qualité de service? Quel est l'impact de l'introduction d'un nouveau service? Comment va évoluer la qualité de service lorsque la charge va augmenter? Utilisabilité Modélisation Evaluation Les performances satisfont-elles les exigences? Figure 44. L utilisation de la modélisation par le capacity planning. 57

La modélisation des performances et les tests en charge La modélisation et les tests de performance sont deux activités complémentaires : l une n exclut pas l autre. La modélisation des performances peut commencer très tôt dans le cycle de vie d un projet. Cette participation en amont permet d initier rapidement le processus de découverte, de comprendre et d identifier les problèmes de performance et le modèle d usage d un système ou d une application. Des données telles que les objectifs de performance, les niveaux de service (temps de réponse) associés aux différentes transactions, le débit et la répartition des cas d usage ou scénarios, le nombre d utilisateurs simultanés et l architecture du système ont besoin d être connus avec le plus de précision possible avant la spécification du plan de tests et lors de l exécution des expériences réalisées lors des tests de performance. Les différents types de modèles de performances Les modèles de performances sont généralement classés en deux catégories : les modèles analytiques ; les modèles de simulation. Les modèles analytiques Les modèles analytiques s appuient sur des formules pour représenter le comportement des composants d un système. Si des formules existent, la solution du modèle est susceptible d être trouvée rapidement. Malheureusement, dans beaucoup de circonstances, les formules «magiques» n existent pas ou ne sont valides que pour un domaine restreint d utilisation. Historiquement, les modèles analytiques ont plus servi à décrire le comportement transactionnel moyen des applications (patterns de performances) qu à évaluer précisément des distributions probables et valides de valeurs de métriques de performance pertinentes. Depuis 1976 et l analyse opérationnelle introduite par J.P. Buzen et améliorée en 1978 avec l aide de P.J. Denning [29], des techniques analytiques ont pu être utilisées pour vérifier l homogénéité des mesures réalisées sur un système. La détermination des valeurs des 5-percentiles et 95-percentiles peut être résolue également de manière analytique. Avec la 58 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

théorie des files d attente et son utilité pour représenter et évaluer les performances de systèmes simples, la portée des modèles analytiques croît sans cesse. L intégration de modèles analytiques qui représentent des plates-formes matérielles hétérogènes n est pas chose triviale [17] ; pour tirer profit au maximum de ces modèles, il est nécessaire d y intégrer une représentation du réseau reliant les machines entre elles. Dans la plupart des cas, il est impossible de résoudre le modèle de manière analytique en obtenant des résultats pertinents. Les prédictions qui utilisent les valeurs moyennes seront d un usage plus limité seulement dans le cas d un seul serveur car il est nécessaire de caractériser le système par un plus grand nombre de facteurs. Les modèles de simulation Il existe deux types de modèle de simulation. Les modèles de simulation à temps continu : ceux-ci conviennent pour les processus de type continu comme la modélisation des concentrations des produits chimiques dans le réacteur d un navire : les concentrations varient sans à-coup avec le temps et, à chaque instant, la réaction s effectue avec un débit connu. Les modèles de simulation à événements discrets : les événements constituent des entités fondamentales et, du point de vue de la modélisation, seuls les instants où les événements surviennent comptent. Ce type de modèle est adapté pour modéliser les systèmes informatiques ou les processus métier. Les événements sont, dans ce cas, la transmission des paquets IP à travers le réseau, les frappes sur un clavier, les entrées/sorties des disques, l allocation ou la libération de la mémoire. Les modèles de simulation tentent, à partir de représentations distinctes de chaque composant d un système et des interactions entre ces différents composants, d en dériver le comportement du système global. Une charge est ensuite injectée dans le système, constituée d un ensemble d éléments discrets arrivant soit de manière aléatoire soit à intervalles réguliers. Chaque composant réagit à cette charge et le comportement global du modèle est tracé et mesuré. Des modèles de simulation peuvent être développés pour résoudre un grand nombre de problèmes de performance. Cependant, leur comportement doit être interprété statistiquement, et un grand nombre d exécutions d un modèle d un même système est nécessaire pour obtenir une vision pertinente 59

de l intervalle de variation correspondant aux différents comportements du système évalué. C est pour cette raison que le processus de développement des modèles et d interprétation des résultats issus des simulations est lent comparé à l usage de modèles analytiques (mais beaucoup moins cher que la simulation du «vrai» système). C est également lors de ce processus que l incertitude des résultats peut être quantifiée, optimisée et validée par rapport aux objectifs de performances. [27] La comparaison entre les différentes techniques d analyse Lorsqu il s agit de choisir la technique la plus adaptée à l analyse d un problème concret de performance, l ingénieur-testeur a le choix : tests en charge sur plate-forme, modélisation analytique, modèles de simulation à événements discrets. Les sections suivantes tentent de cerner les limites de chacune de ces techniques et de signaler les pièges à éviter dans la démarche afin de faciliter la sélection. Les erreurs courantes à éviter lors des tests en charge L injection de charge sur un système ou la simulation d un modèle de performances ne se fait pas sans réflexion : c est un exercice difficile où l on a besoin de contrôler un maximum d éléments. En effet, lors d une métrologie «classique» ou lors de tests servant à valider des modèles de performances, l objectif des expériences est de pouvoir simuler le comportement des utilisateurs réels. En outre, il est nécessaire que les expériences réalisées soient mesurables, répétables, fiables, réutilisables et représentatives de l activité spécifiée (appelée souvent «modèle d usage»). Sans modèle d usage, les tests ne sont forcément pas représentatifs. Certaines erreurs peuvent gravement dégrader la qualité d une expérience. Les plus courantes sont les suivantes : les variations dues aux erreurs expérimentales sont ignorées ; des paramètres importants ne sont pas contrôlés ; les effets des facteurs sur les performances ne sont pas isolés ; les interactions entre les facteurs sont ignorées ; trop d expériences sont réalisées ; la durée des tests n est pas assez longue ; le système n est pas stable ; les mesures ne sont pas déclenchées une fois le système stabilisé ; 60 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

les résultats varient trop d un test à l autre ; l environnement n est pas isolé ; les erreurs des outils de tests sont ignorées. La rigueur du protocole expérimental est le principal facteur de réussite des tests qui permettent de valider une analyse des performances. Les limites des tests de performance La migration d architectures déployées de type client-serveur vers les systèmes distribués Web a rendu incomplètes les analyses traditionnelles fondées sur les résultats issus de simulation d une charge, aussi représentative soit-elle, sur un ensemble de serveurs situés sur une plateforme unique et dans un réseau parfait. Cela est d autant plus vrai lorsqu il s agit d évaluer les services Internet pour lesquels les informations sont envoyées à un grand nombre d utilisateurs par publication/abonnement et non par requête/réponse. Comme vu précédemment, les tests en charge sont un moyen sûr pour évaluer les performances des serveurs d un projet. Ils ont toutefois des limites. La représentativité des tests de performance impose de connaître avec un minimum de précision le modèle d usage et les exigences de performance de l application, ainsi que de disposer d un code applicatif relativement stable et de jeux de données valides. Le montage de la plate-forme de tests est souvent lent et la mise à disposition d un environnement à l image de celui de production est souvent une opération coûteuse. Il est néanmoins utile pour préparer le déploiement de l application et mettre au point le code et la configuration du système. La qualité des résultats produits lors des tests en charge nécessite de disposer et de tester un environnement dédié au sein d un réseau parfait. Il est ainsi impossible de mesurer l impact d une application sur les performances des autres applications ou du réseau cible partagé. Réciproquement, l influence du «bruit» causé par l environnement existant (serveurs ou réseau partagé par plusieurs applications) dans lequel s insère le système est difficile à évaluer. Enfin, les progrès réalisés sur les outils de test en charge permettent de simuler quelques milliers d utilisateurs simultanés. Cependant, l analyse des performances d un système très fortement sollicité est, sinon irréalisable, du moins extrêmement coûteuse. 61

Lorsque la modélisation des performances a commencé à se développer à France Télécom, certains ont imaginé qu elle était synonyme de suppression des tests en charge dans le service de métrologie. Cette idée a rapidement été balayée car il est apparu évident que la modélisation des performances n avait pas la capacité de représenter correctement l ensemble des bogues et des anomalies présents dans le code des applications, mais visait plutôt à déterminer les valeurs (par exemple, temps de réponse) optimales ou pouvant être atteintes. Les limites de la modélisation analytique Par rapport aux modèles de simulation événementielle, la modélisation analytique présente des limites connues qui permettent de décider, sur un projet donné, quand il ne faut pas sélectionner cette technique. Voici un certain nombre de cas dans lesquels il vaut mieux ne pas l utiliser : des temps de service distribués de manière non exponentielle : cela provoque peu d erreurs sur l utilisation des ressources, mais beaucoup plus sur les temps de réponse et la longueur des files d attente ; des arrivées de requêtes non séquentielles ; les instructions «fork()» et «join()» ; les arrivées de requêtes dépendant des traitements effectués sont difficiles à modéliser (par exemple celles qui dépendent des temps de réponse) ; les blocages (overflow) ; l analyse des transitions est complexe ; les problèmes de contention ; les problèmes d exclusion mutuelle ; la modélisation de la mémoire est difficile car elle est gérée souvent de manière propriétaire : il faut alors trouver un compromis entre la mémoire disponible et le nombre d écritures sur le swap disque. Il est souvent préférable de faire appel à la simulation événementielle. Cependant, la modélisation analytique est plus adaptée et précise lors de l étude de petits systèmes ou de la représentation simple d un système. Les erreurs courantes des modèles de simulation événementielle Sans méthode rigoureuse, la réalisation de modèles à événements discrets permet rarement d aboutir à des résultats pertinents qui permettent de représenter fidèlement un système informatique. Les erreurs les plus courantes sont les suivantes : 62 CHAPITRE 3 DU TEST EN CHARGE À LA MODÉLISATION

le choix du niveau d abstraction est inapproprié par rapport à l objectif fixé et à la précision demandée sur les résultats ; le langage de programmation est inadapté pour simuler le modèle ; le modèle n est pas complètement vérifié ; le modèle a été insuffisamment validé pour quantifier l incertitude sur les résultats ; la topologie du modèle a été mal représentée ; la période de simulation du modèle est trop courte : trop peu d échantillons ont été simulés pour l intervalle de confiance spécifié ; le générateur de nombres aléatoires ou pseudo-aléatoires n est pas assez performant sur l outil utilisé ; la validation a été réalisée sur des expériences non représentatives du comportement réel du système. En réalité, le meilleur moyen de bien développer un modèle de performances est de suivre le célèbre principe d économie d Einstein : «Un modèle doit être aussi simple que possible, mais pas plus simple». Les limites de la modélisation événementielle La construction de modèles de simulation événementielle possède certaines limitations. Elle est souvent imprécise pour des architectures simples. Elle dépend fortement des outils utilisés pour permettre la simulation : les outils fiables permettant de construire des modèles macroscopiques sur étagère sont rares, coûteux et évoluent rapidement. Ils nécessitent donc un investissement constant en termes de suivi, de formation et de validation de leur fiabilité. La rapidité de développement des modèles dépend de la mise à disposition des modèles réutilisables de composants sur étagère. Il est parfois nécessaire de vérifier que les composants sont réellement utilisables dans le contexte du projet à évaluer. La durée des simulations peut être longue si le moteur de simulation n est pas optimisé. 63