Si les commutateurs Web constituent l’élément fondamentale d’une politique d’optimisation des services d’un site, ils n’en sont qu’une brique. La répartition de charge peut être effectuée à différents niveaux et son architecture doit être soigneusement pensée puis testée afin de parvenir à une solution optimisée sur tous les traitements qu’implique une requête.
De la base de données à la répartition de la charge entre serveur et client
Aujourd’hui, les sites statiques tendent à disparaître au profit de pages dynamiques constituées à la volée à partir de bases de données. En répartissant les requêtes entre différents serveurs Web, les commutateurs de niveau 7 ne tiennent pas compte des accès aux bases et des temps de traitement nécessaires à l’assemblage de la page. Résultat, bien qu’optimisé au niveau du serveur Web, le traitement de la requête peut être retardé par une base de données saturée. Pour ces sites dynamiques, il est donc préférable d’opter pour deux niveaux de répartition de charge. Le premier est basé sur de la commutation Web en amont des serveurs Web, le second derrière le serveur et avant les bases de données. Pour ce dernier, les fonctions d’analyse d’URL ne jouant pas un rôle critique s’il n’est question que d’accéder à des enregistrements d’une table, il est possible de privilégier des outils d’entrée de gamme s’arrêtant à la couche IP. Parallèlement aux pages dynamiques liées à des données, les sites reposant sur des composants (COM ou EJB [Enterprise JavaBeans]) se développent de plus en plus. Ces sites s’appuient sur des serveurs d’application qui exécutent les requêtes, mais peuvent également devenir des goulets d’étranglement, bien qu’équipés de fonctions de répartition de charge entre les différents composants. Dès lors, interviennent les notions de répartition des traitements entre la partie cliente et le serveur, la distribution des composants entre différents serveurs ou encore leur duplication, ceci afin d’aller vers des architectures redondantes offrant une meilleure qualité de service et des fonctions de tolérance aux pannes.
Ces architectures distribuées restent très difficiles à gérer faute d’outils de simulation avant déploiement. Elles nécessitent de véritables compétences réseau et applicatives, encore rares sur le marché en raison de la jeunesse des technologies. De plus, les paramètres à prendre en compte sont nombreux : temps d’accès disque d’un moteur de recherche, temps d’accès à la base, intelligence sur le poste client qui suppose des téléchargements ponctuels, répartition d’objets serveurs en local ou à travers un réseau distribué géographiquement afin de rapprocher les composants de l’utilisateur final et ainsi de réduire la consommation de bande passante… Souvent empirique, l’approche de la majorité des entreprises repose sur une réflexion interne qui débouche sur des méthodologies élaborées avec difficulté. Les outils de simulation ne permettent pas de tester des hypothèses de répartition de charge. C’est pourquoi l’empirisme et l’expérience restent de mise…
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
