SETIT 2009 5 th Internatonal Conference: Scences of Electronc, Technologes of Informaton and Telecommuncatons March 22-26, 2009 TUNISIA Analyse des Performances et Modélsaton d un Serveur Web Fontane RAFAMANTANANTSOA*, Patrce LAURENCOT* et Alexandre AUSSEM** *LIMOS UMR 6158 CNRS, Unversté Blase Pascal, Clermont Ferrand II, France fontane@sma.fr patrce.laurencot@sma.fr ** PRISMa, Unversté Claude Bernard,Lyon I, France alexandre.aussem@unv-lyon1.fr Résumé: Depus quelques années, le nombre d utlsateurs du servce Web a connu un accrossement phénoménal. Ces utlsateurs sont très exgeants quant à la rapdté d accès aux nformatons sur Internet. C est pourquo les performances du serveur Web sont d une mportance captale. Pluseurs facteurs affectent les performances : la vtesse de la machne clente, la bande passante entre le clent et le serveur et la capacté du serveur lu-même. Cette dernère dépend consdérablement de la confguraton du serveur web et du système d explotaton utlsés. De part leur melleur performance et stablté, Apache est souvent utlsé avec le système d explotaton FreeBSD pour héberger des pages web. Ce paper montre des résultats de l analyse des performances de ces systèmes. En utlsant les outls d évaluaton des performances «webstone» et «bsdsar», nous analysons les effets de tros paramètres d optmsatons sur les métrques des performances du serveur web, d une part, et les dfférentes ressources systèmes, d autre part. Nous présentons également un modèle de fle d attente smple qu rasonnablement représente le comportement d un serveur Web saturé en utlsant l algorthme d analyse de valeur moyenne (MVA). Mots clés : Analyse des performances, fle d attente, modélsaton, serveur web. INTRODUCTION Le World Wde Web est un système clent/serveur qu ntègre dfférents types d nformaton sur Internet. Il permet aux utlsateurs de navguer sur dfférents stes à travers le monde. Le web est devenu de plus en plus populare. La technologe Web mplque la combnason des navgateurs Web et des serveurs Web. Ensemble, les deux éléments forment un outl graphque facle permettant de navguer sur Internet. Les utlsateurs du Web sont très exgeants quant à la rapdté d accès à dfférents documents sur Internet. C est pourquo les performances du serveur Web sont d une mportance captale. Le clent, le serveur et le réseau qu lent les clents avec les serveurs affectent la latence c'est-à-dre le temps de réponse d une requête. Le déla d attente au nveau du clent est le temps requs par le navgateur pour affcher le document. La latence au nveau du réseau est le temps d accès au serveur dstant plus le temps de transmsson des données. Le déla sur le serveur est le temps que met ce derner pour trater la requête. Dfférents travaux [MJM 03], [YMH 00], [[KhA 02], [JMC 03], [RRP 01] ont proposé des modèles de fle d attente M/M/1/k, M/G/1/K*PS et MMPP/G/1/K*PS pour évaluer les performances d un serveur Web et/ou d un proxy. Ils ont étudé l mpact sur les performances des paramètres tels que le trafc d arrvée, la dstrbuton de la talle des documents, la mémore cache et le nombre maxmal de connexons. D autres travaux ont porté sur l analyse et le dmensonnement d un serveur Web [VJC 96], [JeP 96], [RTJ 96] [KSM 01] [TTH 01], [BaC 99a], [BaC 99b], [Bar 99] afn d dentfer l élément qu consttue un goulet d étranglement stué sur le chemn entre les clents et le serveur. Une fos celu-c dentfé, des solutons permettant de dmensonner la capacté de chaque élément sont proposées : CPU, mémore, mémore tampon des routeurs et bande passante du réseau. L étude des performances de serveurs web reste un thème qu ntéresse des chercheurs. Plus récemment encore, [BWM 06] et [DTA 07] ont respectvement étudé les nfluences des archtectures auxquelles tourne le serveur et le type de l outl générateur de trafc (ouvert ou fermé) sur les métrques des performances d un serveur web. - 1 -
L optmsaton des paramètres du système d explotaton, et du serveur web est une soluton pour amélorer les performances. Cette tâche n est pas facle du fat que les valeurs optmales de ces paramètres varent selon les confguratons matérelles et la lo de servce demandé au serveur. Ce paper analyse et modélse les performances de Apache sous FreeBSD et est organsé en 4 sectons. La secton 1 présente une descrpton et des outls de mesure des performances d un serveur web. Les confguratons des expérmentatons et les résultats obtenus sont examnées respectvement dans les sectons 2 et 3. Un modèle smple qu représente le comportement d un serveur web saturé est donné en fn d artcle. 1. Performance de serveur web Un serveur Web est un système sur un réseau qu peut trater des requêtes http. Le HyperText Transfer Protocol (http) est le premer protocole utlsé par le Web pour récupérer des nformatons à partr des serveurs dstrbués. Afn de ben organser les mesures des performances d un serveur Web, le système dot respecter les condtons suvantes : une machne sur laquelle un serveur Web à tester est nstallé, des machnes clentes en nombre suffsant avec un logcel de mesure des performances pour évter leur saturaton, un réseau de très haut débt et dédé au trafc HTTP relant le serveur avec les clents pour évter la saturaton de la lason, une machne pour la synchronsaton et les collectes des résultats Quatre métrques sont utlsées pour mesurer la capacté d un serveur Web : le nombre des requêtes tratées par seconde (unté de mesure : rps ou HTTPPops/sec) : est une mesure du nombre de requêtes gérées par un serveur Web durant une pérode de temps détermnée. Les requêtes peuvent être adressées à des fchers statques de dfférente talle, mas auss à des fchers HTML dynamques, des commandes CGI ou accès aux bases de données à travers dfférentes API. S les requêtes arrvent avec une fréquence plus grande que la capacté du serveur, elles ne sont pas tratées. le débt (unté de mesure : octets par seconde): la quantté maxmale de données que le serveur Web peut transmettre à toutes les connexons HTTP ouvertes pour une durée de temps prédétermnée (le débt dépend fortement de la bande passante du réseau). la latence d une requête (unté de mesure : RTT) : le temps nécessare pour commencer à répondre à une requête après l établssement de la connexon. le nombre d erreurs : les requêtes non tratées par le serveur en rason d un très grand nombre de requêtes reçues. 1.1. Méthodologe d analyse des performances Les avantages de l analyse des performances d un serveur Web sont multples. Le premer, est d évaluer le nveau du servce fourn par le serveur, en terme de temps de réponse, de taux d erreur, et de débt. D autres avantages sont les suvants : permettre d évaluer l usage des ressources afn d dentfer le goulet d étranglement, antcper des problèmes de performance et comprendre l nfluence du nombre maxmum de connexons, de la poltque d ordonnancement du processeur, sur la performance du serveur. Ce derner peut ader l admnstrateur système pour optmser les paramètres matérels et logcels du système. L ultme avantage de l analyse des performances est de détermner la capacté d un serveur Web qu peut être défne comme le débt maxmal observé correspondant au temps d exécuton de requêtes acceptables. Les étapes prncpales permettant l évaluaton des performances sont les suvantes: Comprendre l envronnement du serveur. La queston prncpale abordée dans cette étape est le nveau du servce à fournr aux utlsateurs et les performances requses ; Surveller les opératons du serveur. La prncpale source d nformaton sur l étude des performances est la donnée collectée à partr de l observaton des actvtés du serveur. Le comportement du serveur peut être survellé par dfférents outls du système d explotaton, comme l Unx/sar ou le NT/Performance Montor de Mcrosoft. Ces outls fournssent des nformatons sur l utlsaton des ressources. Caractérser le Workload Les fchers de log sont utles pour caractérser le workload. Les tros paramètres les plus mportants pour caractérser le workload d un serveur web sont : les types de document (HTML, mage, vdéo, etc), leur popularté et leur talle. Analyser la capacté et les performances du serveur. Dans les sectons suvantes, on utlse la méthode présentée c-dessus pour analyser les performances du serveur web notamment sous l nfluence de quelques paramètres d optmsaton de Apache et de FreeBSD. 1.2. Les outls de mesure et d évaluaton des performances webstone Il exste dfférents outls de mesure et d évaluaton des performances d un serveur web: SURGE [BaC 99b]; SpecWeb96 ; WAGON [ZNC 99] ; SpecWeb99 [Er 99] ; Webbench; HTTPERF [DaT 98] ; WEBSTONE [GeM 96]. - 2 -
Ces outls tournent ndépendamment de la plateforme serveur ou du logcel serveur sur lesquels ls sont exécutés. Côté clent, ces outls génèrent des requêtes au serveur pour examner les comportements et les performances de ce derner. Dans le cadre de l étude, on a utlsé WEBSTONE comme outl de mesure et d évaluaton des performances. Ce chox est justfé par le fat que WEBSTONE permet de spécfer la dstrbuton de la talle de document demandé, la fréquence d accès au serveur web et le nombre de clents qu génère de charge pour le serveur. La Fgure 1 llustre la structure de WEBSTONE. Fgure 1. Structure de Webstone Les «Webchldren» sont contrôlés par le «WebMASTER», qu lance à dstance pluseurs «Webchldren» sur une ou dfférentes machnes clentes. Chaque Webchld émet des requêtes l un après l autre au serveur web. Plus précsément, après que le Webchld établt une connexon avec le serveur, l envoe une requête. Il ferme mmédatement la connexon après avor reçu le document ensute la nouvelle connexon est étable pour obtenr le document suvant. Après exécuton de chaque clent, les données sont collectées sur des machnes clentes par le WebMASTER et un rapport sur les performances est généré. Autre mportante mesure est le Lttle s Load Factor (LLF), dérvée de la lo de Lttle. Ce facteur reflète le degré de concurrence dans l exécuton des requêtes. C est le nombre moyen de requêtes que le serveur peut gérer à un moment donné. Le LLF est calculé par la formule : LLF total _ cumulatve _ tme test _ tme = (1) total _cumulatve_tme est la somme des latences mesurées pour toutes les connexons et Test_tme représente la durée de l exécuton des tests avec l outl de mesure de performance. Idéalement, LLF dot être égal au nombre de processus clents. Une valeur nféreure ndque que le serveur est surchargé et certans clents n ont pas été servs avant le tme out. Les règles de confguraton suvantes sont prescrtes lorsqu on utlse WEBSTONE [GeM 96]: Fle set : content la lste de la page demandée et la fréquence d accès Benchmark Run Confguraton : le temps d exécuton de l outl dovent être au mnmum de dx mnutes ce qu permettent d avor un temps nécessare pour le serveur et le clent avant d attendre l état stable. Ce temps peut être suffsamment long pour annuler les varatons mportantes observées pendant les premères mnutes d exécuton. Le nombre de clents : le nombre de clents dot varer entre 20 et 100 avec une ncrémentaton de 10 pour que les performances du serveur sous dfférentes charges soent observées. La confguraton de la machne serveur : l est nécessare que l utlsateur devrat rapporter le système d explotaton, la confguraton mémore et n mporte quelle modfcaton spécal à apporter au système d explotaton notamment la ple de protocole TCP/IP. 1.3. FreeBSD et survellance des performances FreeBSD fournt dfférents outls permettant de collecter et d affcher des nformatons concernant les performances du système. Bsdsar est un outl basé sur une sére de compteurs qu représentent les mesures des performances. Il permet à un utlsateur d étuder les comportements des ressources telles que CPU, mémore, dsque et réseau. Bsdsar peut fournr des mesures sur l utlsaton CPU, dsque, le nombre de paquets transms par seconde, le nombre d nterruptons par seconde et l utlsaton RAM. L outl est écrt en langage Perl et possède dfférentes optons. Le Tableau 1 donne la descrpton des objets et des compteurs survellés. Objet Compteur Descrpton Mémore Octets/sec. Nombre d octets transférés à partr ou vers le dsque Dsque % Temps dsque Pourcentage du temps physque où le dsque est occupé Processeur % Temps processeur Interrupton/sec. Pourcentage du temps où le CPU est occupé Nombre d nterruptons des pérphérques Tableau 1. Descrpton des objets et des compteurs survellés 1.4. Flux de sesson et archtecture d Apache Le serveur Apache verson 1.3 est structuré comme un pool de processus contrôlés par le processus «master». Comme le montre la Fgure 2, le processus «master» - 3 -
contrôle les processus «workers» et gère leur créaton et destructon. Les processus «workers» sont responsables de la geston de la communcaton avec les clents Web, y comprs le traval nécessare pour générer les réponses. Un processus «worker» ne peut gérer qu une seule connexon jusqu à la termnason de celle-c. Fgure 2. Flux de sesson et archtecture d Apache Le paramètre MaxClents de Apache lmte le nombre de processus «workers». S le nombre de requêtes reçues par le serveur est supéreur au nombre de processus «workers» générés par le processus «master», certanes requêtes seront mses en attente dans la fle d attente du protocole TCP. Dans le cas du système d explotaton FreeBSD, la talle de cette fle d attente TCP peut être contrôlée avec le paramètre sysctl, kern.pc.somaxconn du noyau. 2. Confguraton des expermentatons Le système expérmental utlsé est llustré sur la Fgure 3. Afn d évter que le réseau ne consttue un goulet d étranglement, on a utlsé un commutateur CISCO Catalyst 2950 confguré en Etherchannel pour nterconnecter les clents avec le serveur. Il est à fare remarquer que la latence causée par le réseau est néglgeable par rapport au temps de tratement au nveau du serveur. C est pourquo dans cet artcle, on ne va pas dscuter du déla au nveau du réseau. Serveur Clents C P U Pentum III Pentum III 800MHz 800MHz Mémore Prncpale 256 Mo 128Mo Système d Explotaton FreeBSD Lnux Serveur Web Apache 1.3 Outls bsdsar 1.0 Webstone 2.5 Tableau 2. Caractérstques des matérels et des logcels utlsés Le Tableau 2 résume les matérels et les logcels utlsés pendant les expérmentatons. On a utlsé Apache (Verson 1.3) [GbD 97 ] pour le serveur HTTP. Il exste actuellement dfférents serveurs HTTP : Internet Informaton Server de Mcrosoft Co [DaT 98], Entreprse Server de Netscape Communcatons Co. NCSA [FKF 03] et CERN [MaC 96]. On a chos Apache qu représente 65% des serveurs Web [WYV 01]. Les expérmentatons ont été effectuées sur une plateforme de serveur dédé, ayant les caractérstques suvantes : Pentum III 800 MHz de processeur, 256 Mo de mémore, FreeBSD 5.1 avec TCP/IP et carte Ethernet. Dans nos expérmentatons, on va utlser Webstone (Ver 2.5) comme outl de mesure des performances du serveur. Pour chaque jet de smulatons, on a testé cnq expérmentatons. Pour obtenr des résultats fables, chaque expérmentaton a été lancée pendant dx mnutes. Les résultats présentés c sont donc la moyenne des résultats obtenus des cnq expérmentatons. On remarque que dans les expérmentatons, on a seulement consdéré de requêtes sur des documents statques et n ncluent pas des requêtes qu nécesstent d autres tratements au nveau du serveur telles que cg. Fgure 3. Confguraton expérmentale 3. Résultats expérmentaux du serveur web Des séres d expérmentatons ont été effectuées pour examner les performances du serveur Web. Les expérmentatons consstaent en exécutant le Webstone sur les machnes Lnux avec la charge de traval (workload) décrt par les paramètres Flelsts. Les expérmentatons ont été survellées en utlsant l outl bsdsar de FreeBSD. Les ressources survellées sont : mémore, dsque physque et CPU. Caractérstques Workload Nombre de fchers 25 Talle totale de fchers 3,6 Moctets Talle moyenne de fchers 150 Koctets Tableau 3. Workload durant les expérmentatons Côté clent, l outl Webstone collecte dfférentes métrques des performances telles que le débt, le temps de réponse et la vtesse de connexon. L outl «bsdsar» assure la collecte les nformatons sur l utlsaton des ressources (RAM, dsque, CPU, etc). - 4 -
Durant les expérmentatons, le workload du Tableau 3 a été utlsé. Dans cette secton, on représente les résultats des expérmentatons comme sut : Expérmentaton 1: Relaton entre le nombre de clents et le débt du serveur Expérmentaton 2: La relaton entre la talle de documents et le temps de réponse Expérmentaton 3: Effet du paramètre MaxClents de Apache Expérmentaton 4: Effet du paramètre Maxconn du noyau du système FreeBSD Expérmentaton 5: Effet du paramètre Maxusers du noyau du système FreeBSD Quand le CPU devent saturé, la vtesse de connexon attent sa valeur maxmale. L allure des courbes de la vtesse de connexon et le débt sont smlares. Dans les expérmentatons, la vtesse de connexons et le débt ont la même sgnfcaton. La dfférence est que la vtesse de connexon est mesurée en http requêtes/sec tands que le débt est spécfé en octets/sec. Lorsque le nombre de clents augmente, le nombre de paquets TCP/IP reçu par le serveur augmente également. Pusque le CPU a à gérer toutes les nterruptons, la ressource CPU nécessare pour les processus HTTP devent nsuffsante, et par conséquent la vtesse de connexon dmnue. 3.1. Expérmentaton 1 : La relaton entre le nombre de clents et le débt du serveur Les expérmentatons ont été réalsées en utlsant les valeurs par défaut des paramètres d optmsaton de Apache et de FreeBSD. Fgure 6. Temps moyen de réponse en foncton du nombre de clents Fgure 4. Vtesse de connexon par seconde en foncton du nombre de clents Fgure 7. Taux d nterrupton Le temps moyen de réponse est une métrque des performances mportante d un serveur Web. Les Fgures 6 et 7 montrent respectvement la courbe du temps moyen de réponse en foncton du nombre de clents et du taux d nterruptons sur le serveur obtenu à l ade de l outl bsdsar. Fgure 5. Utlsaton CPU en foncton du nombre de clents La Fgure 4 montre qu en dessous de 80 clents, la vtesse de connexon augmente lorsqu on augmente le nombre de clents. A partr de 80 clents, la vtesse de connexon dmnue en rason de la surcharge du CPU qu attent presque 100% (Fgure 5). On constate que logquement, la courbe du temps moyen de réponse augmente avec le nombre de clents. La courbe augmente jusqu au nombre de clents égal à 100 et semble se stablser à ce nveau. - 5 -
Ce comportement serat dû à la surcharge du CPU et l nterface réseau. Certans paquets TCP/IP sont perdus et les nterruptons correspondantes n ont pas été créées. Pour cela, on n a pas utlsé les documents de l expérmentaton 1. Pour chaque expérence, on fxe la talle de documents respectvement à 0.1Koctets, 1 Koctets, 10 Koctets, 100 Koctets et 1000 Koctets. Le nombre de clents pour stresser le serveur a été fxé à 60. Les Fgures 10 jusqu à la Fgure 11 montrent le temps moyen de réponse et la vtesse de connexon du serveur. On donne auss le débt en Mbts/sec, Fgure 12 lequel a été obtenu en multplant la vtesse de connexon par la talle de document. Fgure 8. Taux d utlsaton dsque en foncton du nombre de clents Fgure 10. Temps moyen de réponse en foncton des talles des documents Fgure 9. Utlsaton mémore en foncton du nombre de clents Les Fgures 8 et 9 montrent respectvement les comportements de la mémore et du dsque. Les deux courbes octets/sec et l utlsaton dsque sont semblables. On constate que n la mémore, n le dsque ne consttue un goulet d étranglement. 3.2. Expérmentaton 2 : Relaton entre la talle des documents et le temps de réponse du serveur Le ste Web comporte dfférents types de documents tels que texte, mages, sons et vdéos. De plus, les talles des documents sont largement varées selon leurs contenus. Par exemple, les auteurs ont montré que la talle de document sut une dstrbuton log-normal. D autres [FKF 03] et [WYV 01] affrment que la talle de document sur le ste Internet sut la dstrbuton de Pareto. On veut savor le temps de servce requs pour une talle de document donnée. Dans cette secton, on examne la relaton entre la talle de document et le temps de tratement requs sur le serveur. Fgure 11. Vtesse de connexon par seconde en foncton des talles des documents De la Fgure 10, on peut constater que les temps de réponse sont presque constants quand les talles de documents sont pettes. Cela est dû à la durée de tratement des entêtes de paquets qu est constante pour n mporte quelle talle de document. Par contre, le temps de transfert est proportonnel à la talle de document. Ce derner devent néglgeable lorsque la talle de document est pette. - 6 -
Quand la talle de document augmente, le temps moyen de réponse du serveur et le débt augmentent graduellement. Il est alors apparemment nadéquat d affrmer que le temps moyen de réponse est proportonnel à la talle de document. Fgure 12. Débt en foncton des talles des documents 3.3. Expérmentaton 3 : Effet du paramètre MaxClents de Apache Pour démontrer l effet de MaxClents sur les performances du serveur, on a effectué dfférentes expérmentatons en fasant varer la valeur de MaxClents. Le nombre de clents durant les expérmentatons a été fxé à 100 et la charge de traval (workload) reste la même que lors des expérmentatons précédentes. On a changé les deux paramètres MnSpareServers et MaxSpareServers pour que seul le paramètre MaxClents contrôle la talle de workers. Le Processus Maître de Apache crée ou tue les processus worker pour s assurer que le nombre total de workers sot égal à MaxClents. La Fgure 13 montre la vtesse de connexon en foncton du paramètre MaxClents. nféreure pour la valeur 80 de Maxclents (processus nsuffsants) et est devenue médocre pour la valeur 100 de MaxClents (trop de processus en compétton). On remarque qu on a gardé le serveur en état complètement chargé pour avor le nombre de requêtes toujours supéreur au nombre de processus dsponbles. C'est-à-dre que certanes requêtes sont mses en attente dans la fle, et ne peuvent pas être serves mmédatement. Quand le nombre de processus est au dessus de 80, de plus en plus de temps ont été ms par les processus en état dormant et le changement de contexte qu par conséquent dmnue la performance du serveur. Avec seulement 60 processus dsponbles, le CPU n est pas complètement chargé et la commande «vmstat» nous a perms de savor qu on a encore assez de mémore dsponble. On a réalsé les mêmes expérmentatons que les précédentes, en augmentant la RAM de la machne serveur à 512 Mo, mas on a obtenu presque la même courbe que celle de la Fgure 13. Le résultat a condut à fare la concluson suvante : augmenter la talle de la RAM ne veut pas forcément dre augmenter la performance s le CPU est déjà complètement chargé avec le nombre de processus. En effet, s on lance plus de processus, on a une dégradaton de la performance. Fgure 14. Vtesse de connexon par seconde en foncton de MaxClents La Fgure 14 montre un résultat dfférent lorsqu on a dmnué à 128Mo la talle de la RAM de la machne serveur. On constate qu à partr de MaxClent égal à 60, on constate une dégradaton de performance en rason d une utlsaton ntensve de swap. Fgure 13. Vtesse de connexon par seconde en foncton de MaxClents En consdérant la Fgure 13, on peut constater que la performance est presque dentque pour les valeurs de MaxClents entre 120 et 150, mas relatvement 3.4. Expérmentaton 4 : Effet du paramètre Somaxconn Pour démontrer l effet du paramètre somaxconn, on a effectué dfférentes smulatons en fasant varer la valeur du paramètre somaxconn. On a consdéré deux cas. Dans le premer cas, le nombre de processus dans le système est nféreur à MaxClents. - 7 -
La courbe de la Fgure 15 montre le LLF obtenu en foncton du nombre de clents. Le nombre maxmal de clents dans les expérmentatons a été chos de façon à ne pas charger complètement le CPU. D après la Fgure 15, LLF coïncde avec le nombre de clents. Toutes les requêtes émses ont été donc serves parce que le nombre de processus est encore nsuffsant pour charger complètement le CPU. Fgure 15. LLF en foncton du nombre de clents Par alleurs, pour des valeurs de Somaxconn trop élevées, on constate également un taux d erreur élevé. Cette stuaton s explque par le fat que certanes requêtes ont ms trop de temps à attendre dans la fle et ont été vctmes de déla d attente dépassé (tme out). 3.5. Expérmentaton 5 : Effet du paramètre Maxusers Pour mettre en évdence l effet du paramètre Maxusers, on a procédé à des expérmentatons en fasant varer la valeur du paramètre Maxusers. Les paramètres MaxClents et Sommaxconn ont été fxés à leur valeur optmale respectve. Le nombre de clents durant les expérmentatons a été fxé à une valeur qu peut complètement charger le CPU. La Fgure 17 montre la vtesse de connexon en foncton du paramètre Maxusers. Sur cette fgure, on constate que la vtesse de connexon augmente avec Maxusers pour des valeurs de Maxusers nféreures à 125. Et les performances obtenues pour des valeurs de Maxusers comprses entre 125 et 300 sont les mêmes. Cependant, s Maxusers est supéreur à 300, on observe une dégradaton consdérable des performances. Dans le deuxème cas, on a fxé le nombre de clents à une valeur de façon à avor un nombre de processus largement supéreur à MaxClents. La Fgure 16 montre la vtesse de connexon par seconde obtenue en foncton de la talle de Somaxconn. Sur cette fgure, on constate que la vtesse de connexon augmente avec Somaxconn pour les valeurs de Somaxconn nféreurs à 125. Et les performances obtenues pour des valeurs de Somaxconn comprses entre 125 et 700 sont les mêmes. Cependant, s Somaxconn est supéreur à 700, on observe une dégradaton des performances. Fgure 17. Vtesse de connexon par seconde en foncton de Maxusers Une valeur trop pette de Maxusers engendre des ressources nsuffsantes (buffer, descrpteur, etc). Une smple consultaton du fcher de log du serveur permet de le confrmer. Fgure 16. Vtesse de connexon par seconde en foncton de Somaxconn Comme le nombre de processus est largement supéreur à MaxClents, certans processus ont été ms en attente dans la fle. Et s la longueur de cette fle (Somaxconn) est trop pette, l y a des rejets de requêtes. De même, s Maxusers a une valeur trop grande, on constate de même une dégradaton mportante de la performance. En effet, comme la talle mémore utlsée par le réseau «mbufs» est proportonnelle à Maxusers (Formule), «mbufs» devent trop mportant, et les ressources mémores utlsées par d autres modules du système devennent nsuffsantes. Cette stuaton rédut consdérablement les performances du système (buffer cache nsuffsante, mémore nsuffsante). - 8 -
D autres expérmentatons, permettant d examner les relatons entre le paramètre Maxusers et le nombre de «mbufs» alloués, le nombre maxmal de fchers ouverts et le nombre maxmal de processus que l on peut créer ont été effectuées. Les formules (2), (3) et (4) exprment respectvement le nombre maxmal de fchers ouverts, le nombre de processus maxmal et la talle de «mbufs,» que l on peut créer en foncton du paramètre Maxusers. a. Intalser le nombre moyen de clents dans chaque pérphérque : n (0) = 0 b. Pour chaque clent de n = 1,2,,N b.1. Calculer le temps moyen de séjour dans chaque pérphérque (5) ymax fle = 32x + 40 (2) R ( n ) = V S [1 + n ( n 1)] = D [1 + n ( n 1)] (6) ymax proc = 28,8x + 36 (3) b.2. Calculer l ensemble de temps de réponse dans le système ynmbcluster = 64x + 1024 (4) K R ( n ) = [ V R ( n )] = R ( n ) 0 = 1 = 1 K (7) y max fle : représente la lmte du nombre de fchers ouverts y max proc : représente la lmte du nombre de processus y : représente le nombre de clusters alloué nmbcluster pour le réseau x : représente la valeur du paramètre Maxusers. 4. Modèle analytque du serveur web On présente dans cette secton un modèle smple basé sur la fle d attente représentant l archtecture du serveur (processeur, mémore, et dsque). La charge de traval consste en une classe : les requêtes HTTP reçues par le serveur. La charge du système d explotaton sera mplctement représentée dans cette classe. Le serveur est représenté par un modèle fermé (closed model). Un modèle fermé d une seule classe peut être représenté par les équatons MVA (Mean Value Analyss) [DVL 94]. Il s agt d une technque tératve pour résoudre le problème de réseaux de fles d attente. 4.1. Algorthme de calcul de MVA L algorthme pour le MVA est donné c-dessous. C est pour un réseau de classe unque avec N clents et K pérphérques. Le temps moyen de servce d un clent sur le pérphérque est S, et le nombre moyen de vstes qu un clent a effectuées pour le pérphérque est V. Pour tout clent n (1 n N), l algorthme cherche à trouver les métrques des performances suvantes : le temps moyen de séjour dans chaque pérphérque, le temps moyen de réponse, le débt de l ensemble ou par pérphérque, le taux d utlsaton et le nombre moyen de clents dans chaque pérphérque. n X ( n ) = 0 R0 ( n ) X ( n) = V X ( n) U ( n) = S X ( n) n ( n) = X ( n ) R ( n ) 0 b.3. Calculer l ensemble de débt du système b.4. Calculer le débt dans chaque pérphérque 0 b.5. Calculer le taux d utlsaton de chaque pérphérque (8) (9) (10) b.6. Calculer le nombre moyen de clents dans chaque pérphérque (11) Le paramètre d entrée de base est le total des temps moyens de servce qu une requête HTTP passe dans le CPU et le dsque. D après la référence [DVL 94], le temps de servce dans le pérphérque est donné par l expresson suvante : D = T / C U global (12) - 9 -
Où D est le temps de servce, T est la durée de l observaton, C est le nombre total des requêtes effectuées durant T, donné par Webstone, et U global est le taux d utlsaton du CPU relevé par l outl bsdsar. Fgure 18. Performance du serveur : mesurée et prédte La Fgure 18 montre les vtesses de connexon mesurées dans les expérmentatons et calculées à partr du modèle de fle d attente, en utlsant la même charge de traval que lors des expérmentatons précédentes. Les paramètres MaxClents, Somaxconn et Maxusers ont été fxés à leur valeur optmale respectve. La qualté de la prédcton est rasonnablement bonne, notamment dans la deuxème parte des résultats, qu correspond au nombre de clents où le débt attent le maxmum. Dans la premère parte de la courbe, le modèle n a pas capturé le comportement du serveur Web. En effet, au dessous de 80 clents, le nombre de requêtes est plus bas que le nombre maxmal que peut gérer le serveur. Le modèle de fle d attente fermé suppose que le nombre de clents actuel est maxmal. Ans, au dessus de 80 clents, la vtesse de connexon prédte est très bonne. 5. Concluson Ce paper a présenté une analyse et une modélsaton des performances d un serveur Web. En utlsant l outl de survellance des ressources, bsdsar et l outl de mesure des performances, Webstone, on a effectué une sére d expérmentatons pour surveller le comportement du serveur Web. Avec ces deux outls, l a été possble d examner le goulet d étranglement du serveur. Il a été possble également d étuder l nfluence de quelques paramètres du système d explotaton FreeBSD et le serveur Web, Apache sur les performances d un serveur Web. Un modèle de fle d attente smple qu représente rasonnablement le comportement d un serveur Web saturé a été également présenté. REFERENCES [BaC 99a] Barford P., Crovella M., 1999a, Performance Evaluaton of Hyper Text Transfer Protocols. Proceedng of ACM SIGMETRICS '99, (Extended verson avalable drunk as Boston Unversty Techncal Report BU-TR-98-016 98 016), p. 188-197. [BaC 99b] Barford P., Crovella M., 1999b, Measurng Web Performance n the Wde Area. Internatonal Sgmetrcs'99, p.37-48. [Bar 99] Barford P., 1999, Web Server Performance Analyss. Tutoral at ACM SIGMETRICS. [BWM 06] B. Schroeder, A. Werman, and M. Harchol- Balter, 2006, Closed versus open system models: a cautonary n proceedngs of Networked Systems Desgn and Implementaton (NSDI). [DaT 98] HTTPerf Davd Mosberger and Ta Jn. A Tool for Measurng Web server Performance. HP Research Labs. volume 26 ssue 3, ACM Sgmetrcs Performance Evaluaton Revew, December 1998. [DTA 07] D. Parag, T. Brecht, A. Harj, P. Buhr, A. Shukla, D. R. Cherton, Comparng the performance of web server archtectures, ACM SIGOPS Operatng Systems Revew, volume 41, page 231 243, June 2007. [DVL 94] D. Menascé, V. Almeda and L. Dowdy, Capacty Plannng and Performance Modelng : from manframes to clent/server systems, PTR Prentce- Hall, Englewood Clffs, 1994. [Er 99] Erch M. Nahum. Deconstructng SPEC Web99, IBM T.J. Watson Research Center Yorktown Heghts, NY, 10598. [FKF 03] F. Hernandez-Campos, K. Jeffay, F.D. Smth. Trackng the Evoluton of Web Traffc : 1995-2003. Unversty of North at Chapel Hll, Departement of to Computer Scence, Chapel Hll, NC 27599-3175 USA. [GbD 97 ] G. Banga P. Druschel, Measurng the capacty of a Web Server, n USENIX Symposum on Internet Technologes and Systems, December 1997, p. 61-67. [GeM 96] Gene Trent and Mark Sake,Webstone: The frst generaton n http server benchmarkng, February 1996. Sllcon Graphcs Whte Paper. [JeP 96] Jean C. B., Phylpp H., 1996. Performance Engeneerng of the world wde web: applcaton to dmensonng and cache desgn, INRIA. Proceedng of the ffth nternatonal World Wde Web conference on computer network and ISDN systems, p.1397-1405. [JMC 03] J. Cao, M. Anderson, C. Nyberg and M. Kh, 2003: Web server performance modellng usng an M/G/1/K*PS Queue. Telecommuncaton, ICT 2003, 10th Internatonal conference, p.1501-1506 vol.2. [KhA 02] Khaled M.Ellethy, Ananthan Komaralngan, 2002. Usng queueng model to analyzes the performance of web servers. Internatonal Conference on Advances n Infrastructure for e-busness, e- Educaton, e-scence, and e-medecne on the Internet, Rome, Italy, January 21-27. - 10 -
[KSM 01] Kazamne M., Shngo A., Masayuk M, 2001, Capacty dmensonng Based on Traffc Measurement n the nternet.proceedngs of IEEE GLOBECOM, Vol4. San Antono,TX. p. 2532-2536. [MaC 96] Martn F. Arltt, Carey L. Wllamson. Web Server Workload Characterzaton: the search for Invarants. In ACM Sgmetrcs 96, pages 126-137, May 1996. Extended Verson. [MJM 03] Mkael A., Janhua C., Mara K., Chrstan N. Performance modelng of an Apache web server wth bursty arrval traffc.internatonal Conference Computng p. 508-514,2003 [RRP 01] R. D. V. D. Me, R Harharan, and P. K. Reeser "web server performance modelng", Telecomuncaton systems, vol. 16, no. 3,4, p. 361-378,2001. [RTJ 96] Rodney B.Wal1ace, Tyrone E. Mckoy, Jr A performance montorng and capacty plannng methodology for web servers, NCR Corporaton.Internatonal CMG Conference 1996 pp.186-197. [TTH 01] Tatsuhko T., Takuya O., Hasegawa G., Masayuk M., 2001: Desgn and Implementaton Experments of Scalable Socket Buffer Tunng, Proceedngs of fourth Asa-Pacfc Symposum on Informaton and Telecommuncaton Technologes (APSITT 2001), (Katmandu & Atam).p. 213-217. [VJC 96] Vrglo A., Jussara of A., Chrstna M., 1996. Performance analyss of a www server. Internatonal CMG Conference, p. 829-838. [WYV 01] W. Gong, Yong Lu, V. Msra, Don Towsley. On tal of Web Fle Sze Dstrbutons. [YMH 00] Yasuyuk F., Masayuk M., Hdeo M., 2000. Performance modelng and evaluaton of web server systems wth proxy cachng, Thèse de Doctorat, Osaka unversty, Japon. [ZNC 99] Z. Lu, N. NIclausse, C. Jalpa-Vllaanueva. «Web Traffc Modelng and Performance Comparson between HTTP 1.0. and HTTP 1.1», 1999. - 11 -