FLASH INFORMATIQUE FI



Performances des infrastructures Web

WebStressing




Philippe JOYE

Paul-Henri REY


avec l’appui de MM. Eric Oberson et Sébastien Piller (eb-Qual SA)

Introduction

L’utilisation du World Wide Web (WWW) en tant que moyen de communication s’est considérablement généralisée ces dernières années. Des informations de toute forme et de toute nature circulent sans retenue sur ce réseau. Afin de garantir un accès de bonne qualité au plus grand nombre d’utilisateurs possible, des protocoles simples et robustes tels que IP, TCP, UDP ou http ont été généralisés. Avec le succès croissant du Web, son trafic a augmenté de façon exponentielle, non seulement en terme de volume et de nombre d’utilisateurs, mais également en terme de diversité. En effet, de nouveaux services multimédias tels que la transmission de sons (téléphonie, radio diffusion) et d’images animées (séquences vidéo, télévision) se multiplient en se superposant au trafic de données traditionnel (http). Cette diversité, liée naturellement à de nouvelles exigences en terme de qualité, n’est pas sans poser de nombreux problèmes aux fournisseurs d’accès et de services [1].

Lors de la mise en place d’un service Web, le fournisseur mettra à disposition à travers un accès Internet une infrastructure complète. Elle comprendra, en plus du (ou des) serveur(s) http, les éléments du réseau interne tels que switchs, routeurs ou autres passerelles (Gateway) qui permettront aux nombreux utilisateurs de requérir aux différents services offerts avec la meilleure qualité possible [10]. Cette qualité englobe, entre autres éléments, la fiabilité d’utilisation, la rapidité de traitement et la sécurité d’utilisation [6].

Le succès commercial du service mis en place dépendra essentiellement de la qualité avec laquelle les utilisateurs pourront y accéder. Le temps de réponse et le taux de succès des requêtes adressées au serveur détermineront, du point de vue de l’utilisateur, la qualité de l’infrastructure [8]. Le fournisseur, sera tenu d’assurer un service de très haute qualité pour un très grand nombre de requêtes simultanées.

Afin de garantir au mieux le service, on dispose généralement dans l’infrastructure de mécanismes de caches hiérarchiques (Web Proxy Caching Hierarchy) dont les objectifs sont d’obtenir, d’une part, un temps de réponse plus faible lors d’une requête (latency) et, d’autre part, une charge moindre sur le serveur d’information et son réseau d’accès (bandwidth conservation). D’autres techniques permettent de répartir les requêtes sur plusieurs serveurs redondants. Ces techniques appelées en anglais Web Server Clustering peuvent être utilisées de manière isolée (Load Balancing) ou combinée avec des techniques de cache (Reverse-Proxy).

Le fournisseur de services devra en première priorité être capable d’évaluer, de tester et d’adapter son infrastructure s’il entend fournir un service de bonne qualité. Pour ce faire, le marché propose déjà des équipements complets de test permettant de mettre globalement sous pression une infrastructure Web existante. Ces systèmes génèrent de façon continue, soutenue et contrôlée de très grandes quantités de requêtes. Ils en analysent les réponses et livrent un protocole de test relativement précis destiné à évaluer l’infrastructure dans sa globalité [8].

L’infrastructure

Les infrastructures de sites Web à hautes performances ont considérablement évolué dans le courant des dernières années. Les structures dites multi-Tiers organisées en réseaux pour des raisons de fiabilité (redondance) et de performances ont remplacé les modestes infrastructures ne disposant que d’une faible largeur de bande. Au niveau du contenu, les pages générées dynamiquement et contenant une foule de données personnelles fournies par des bases de données, ont remplacé les pages statiques au format HTML.

Les grandes infrastructures actuelles sont, dans la majorité des cas, constituées d’un front-end englobant différents éléments comme des Firewalls, des répartiteurs de charges (Load-Balancers), des serveurs de cache et des accélérateurs SSL. Ë l’arrière de ce front-end, les parties constitutives des serveurs sont structurées en Tier comme le montre la figure 1. Le premier Tier représente le serveur Web chargé de recevoir et de traiter les requêtes http avant de générer les pages HTML retournées au client. Le deuxième Tier contient les applications commerciales relatives aux services et la troisième partie abrite les bases de données permettant la génération et l’archivage des documents destinés aux clients.

fig. 1 - architecture générique d’une infrastructure Web de grande dimension 

Pour de nombreuses infrastructures, une panne, quelle que soit sa nature, se révèle embarrassante et, dans la plupart des cas, financièrement dommageable. Les sites offrant des services de nature commerciale peuvent potentiellement perdre des millions de dollars de revenu en quelques minutes d’interruption. Le coût en terme d’image et de confiance, qui, lui, est difficilement mesurable, sera malgré tout significatif. En outre, les entreprises deviennent de plus en plus intolérantes avec les pannes et les performances insuffisantes des infrastructures Web. Il est donc non seulement urgent, mais également absolument nécessaire de pouvoir réaliser de manière systématique des tests de performance représentatifs de charges générées par les utilisateurs sur les infrastructures commerciales.

Les campagnes de mesures mettant sous charge les infrastructures Web permettent d’évaluer avec une étonnante précision non seulement les performances d’une infrastructure Web mais également d’en connaître les limites d’exploitation. Le Laboratoire de Télécommunications de l’Ecole d’Ingénieurs et d’Architectes de Fribourg (EIA-FR) dispose depuis quelques mois d’un équipement hautement performant permettant cette évaluation.

Que mesurer ?

Que se passe-t-il lors des périodes de charge sur une infrastructure ? Dans un premier temps, le ou les serveurs seront capables de supporter correctement les différentes requêtes qui lui ont été adressées. A partir d’une certaine charge, les performances du serveur vont aller en diminuant. Les temps de réponse vont augmenter sensiblement. Passée une certaine limite, l’infrastructure ne sera plus capable de servir les sollicitations qui lui sont adressées. On mettra donc en évidence une limite de rupture au-delà de laquelle le serveur peut, dans le pire des cas être mis complètement hors service.

La charge d’un serveur Web peut typiquement être décrite par cinq caractéristiques principales directement mesurables :
• le nombre de transactions par seconde. Ce qui représente le nombre de requêtes GET ou POST adressées au serveur par ses différents clients ;
• le nombre de nouvelles connexions acceptées par seconde. Ce qui correspond au nombre de nouveaux visiteurs servis chaque seconde ;
• le nombre d’utilisateurs servis en parallèle. Cette valeur est l’une des plus critique en regard aux ressources consommées par chaque utilisateur ;
• les temps de réponse moyens aux diverses requêtes. Cette valeur sera définie à plusieurs niveaux, soit TCP (temps de connexion), http (temps d’émission du premier byte de donnée) et URL (temps de réponse lors de la réception complète de la page) ;
• la largeur de bande utilisée pour un service donné.

Méthodologie

Globalement, 3 approches distinctes sont possibles :

La première, dite qualitative, concerne les infrastructures déjà en service et dont les exploitants désirent connaître les performances. Cette mesure permettra de préciser les temps de réponse moyens en exploitation lorsque la charge correspond à une charge moyenne nominale. Cette valeur peut permettre de qualifier le ou les services fournis par l’infrastructure.

La deuxième, dite de validation, se rapporte à une infrastructure dont le développement est en voie d’être achevé et dont les concepteurs désirent évaluer les performances en vue d’une mise en exploitation. Cette approche se fera sans risque de perturbation puisqu’en principe l’infrastructure ne se trouvera pas en service.

La troisième approche, dite destructive, rejoint dans ses conditions de réalisation la seconde, à la différence près que l’on ira jusqu’à la limite de fonctionnement de l’installation. On cherchera donc à définir avec le plus de précision possible cette limite.

La figure 2 représente une mesure réalisée sur un serveur du marché poussé à ses limites d’exploitation. En effet, on remarque très distinctement la zone de rupture représentant le nombre maximal de transactions par seconde que l’infrastructure est en mesure de servir. Dans ce cas, nous avons donc amené le serveur aux limites de ses capacités de traitement.

fig. 2 - zone de rupture lors d’un test destructif 

Conclusion

La méthodologie d’évaluation développée dans le cadre du projet de recherche appliquée WebStressing par le laboratoire de Télécommunications de l’Ecole d’Ingénieurs et d’Architectes de Fribourg permet de définir avec une grande précision les limites de rupture ainsi que les performances d’un serveur Web et de l’infrastructure qui l’accueille.

La démarche proposée permettra de vérifier et valider les caractéristiques de performance préalablement spécifiées par les concepteurs et les exploitants.

Références

[1] Web Performance Tuning, Patrick Killelea, O’Reilly, March 2002
[2] HTTP, The definitive Guide, David Gourley & Brian Totty, O’Reilly, September 2002
[3] Hypertext Transfer Protocol — HTTP/1.1, IETF rfc 2616, June 1999
[4] Scalable Web Server Clustering Technologies, Trevor Schroeder, Steve Goddard and Byrav Ramamurthy, IEEE Network, May/June 2000
[5] Internet Traffic Measurement, Carey Williamson, November 2001
[6] High-Volume Web Site Capacity Assessment, Philip Joung, Spirent Communications, June 2001
[7] The Network Commandments : Ten Ways to Improve Quality and Performance, Philip Joung, Spirent Communications, September 2002
[8] Reality Bytes : Why Realism Matters for Capacity Assessment, Philip Joung, Spirent Communications, June 2002
[9] General Network Performance Testing Methodology, Philip Joung, Spirent Communications, March 2003
[10] Meeting Service Level Agreements Using Web Infrastructure Stressing Appliances, John Kenney, Caw Network Application Brief, June 2001



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.