Pour des performances globales, il est généralement souhaitable d'avoir une vision globale de l'architecture au lieu de se concentrer sur des éléments matériels spécifiques. Peu importe le nombre de composants matériels que vous ajoutez à une machine, ceux-ci doivent offrir un niveau maximal de performance.
La section traite des points de l'architecture réseau à prendre en compte lors de l'installation de Caching Proxy.
Si le site Web de votre entreprise est très apprécié, la demande de contenu peut excéder la capacité d'un serveur proxy et potentiellement diminuer les performances. Pour optimiser les performances réseau, vous pouvez ajouter des clusters de machines Caching Proxy à équilibrage de charge ou utiliser une architecture de cache partagée avec Remote Cache Access (RCA) dans votre architecture réseau globale.
Une façon de faire évoluer l'architecture est de créer des clusters de serveurs proxy et d'utiliser le composant Load Balancer afin de répartir la charge entre eux. La création de clusters de serveurs proxy est une pratique de conception avantageuse non seulement pour les performances et l'évolutivité mais aussi pour la redondance et la fiabilité. L'utilisation d'un seul serveur proxy présente également l'inconvénient de constituer un point de défaillance unique. Si le serveur proxy tombe en panne ou devient inaccessible en raison d'un incident sur le réseau, les utilisateurs ne peuvent plus accéder à votre site Web.
RCA permet de bénéficier d'une architecture de cache partagé. Une architecture de cache partagé répartit la mémoire cache virtuelle totale entre plusieurs serveurs Caching Proxy utilisant un protocole d'intercache, tel que le protocole ICP (Internet Cache Protocol) ou le protocole CARP (Cache Array Routing Protocol). RCA est conçu pour optimiser les ratios d'occurrences de cache en cluster en fournissant un cache virtuel de grande taille.
Un tableau RCA de serveurs proxy est plus performant qu'un Caching Proxy autonome ou qu'un cluster de machines Caching Proxy autonomes. Les meilleures performances sont dues à l'augmentation de la taille totale du cache virtuel, qui optimise le ratio d'occurrences du cache et réduit au minimum le manque d'homogénéité et la latence du cache. Avec RCA, un seul exemplaire d'un document particulier réside dans le cache. Avec un cluster de serveurs proxy, la taille totale du cache est accrue mais plusieurs serveurs proxy permettent d'extraire et placer en mémoire cache les mêmes informations. Le ratio d'occurrences de cache total n'est donc pas plus élevé.
RCA est généralement utilisé dans des scénarios d'hébergement de données d'entreprise de grande envergure. Toutefois, RCA n'est pas limité à ce type de déploiement. Vous pouvez envisager d'utiliser RCA si la charge de votre réseau requiert un cluster de serveurs de cache et si la plupart des demandes portent sur des données résidant en mémoire cache. Selon la configuration de votre réseau, RCA n'améliore pas toujours les performances en raison de l'augmentation du nombre de connexions TCP utilisées par le client lorsque RCA est utilisé. En effet, non seulement un membre RCA doit traiter les URL les plus demandées mais il doit également acheminer les demandes à d'autres membres ou clusters s'il reçoit une demande d'une URL qui ne fait pas partie des plus demandées. Ceci signifie qu'un membre d'un tableau RCA peut avoir plus de connexions TCP ouvertes que s'il fonctionnait comme serveur autonome.
L'amélioration des performances est en grande partie due aux fonctions de cache de Caching Proxy. Cependant, le cache du serveur proxy peut devenir un goulet d'étranglement s'il n'est pas configuré correctement. Pour déterminer la meilleure configuration de cache, un effort significatif doit être apporté à l'analyse des caractéristiques du trafic. Le type, la taille, la quantité et les attributs des données influent sur les performances du serveur proxy en termes de vitesse d'extraction de documents sur les serveurs origine et de charge du serveur. Quand vous comprenez le type de trafic que Caching Proxy s'apprête à mandater ou à servir à partir du cache, vous pouvez prendre en compte ces caractéristiques au moment de la configuration du serveur proxy. Par exemple, savoir que 80 % des objets à placer en mémoire cache sont des images (*.gif ou *.jpg) d'une taille approximative de 200 Ko vous permet de personnaliser les paramètres du cache et la taille du cache. En outre, savoir que la plupart des données sont des pages dynamiques qui ne seront pas placées en mémoire est un facteur déterminant pour le réglage de Caching Proxy.
L'analyse des caractéristiques du trafic permet de déterminer si l'utilisation d'un cache mémoire ou d'un cache disque peut optimiser les performances de votre cache. De même, une bonne connaissance de ces caractéristiques permet de déterminer si l'utilisation de la fonction de cache dynamique de Caching Proxy engendrera une amélioration des performances.
Les caches disque sont bien adaptés aux grandes quantités de données à placer en mémoire cache. Par exemple, si le contenu du site est important (d'une taille supérieure à 5 Go) avec un taux de correspondance de 80 à 90 %, un cache disque est recommandé. Pourtant, du fait de sa vitesse plus élevée, un cache RAM peut être employé sur certains sites de grande taille. Par exemple, la quantité de données extraites du cache de Caching Proxy n'est pas aussi élevée ou si une configuration de cache partagé est employée, un cache mémoire est approprié.
Caching Proxy peut mettre en cache et invalider des données dynamiques (résultant de JSP et de servlets) générées par le cache dynamique de WebSphere Application Server, fournissant une extension virtuelle du cache Application Server dans les caches réseau. L'activation de la fonction de cache des données générées en dynamique améliore les performances réseau dans un environnement comptant de nombreuses demandes de pages Web publiques générées en dynamique d'une durée de vie basée sur la logique applicative ou sur un événement tel qu'un message extrait d'une base de données. La durée de vie de la page est finie mais un déclencheur d'expiration peut être défini au moment de sa création ; En conséquence, les hôtes sans fonction de cache dynamique et d'invalidation doivent régler la valeur TTL des pages sur zéro.
Si une page générée en dynamique est appelée plusieurs fois par un ou plusieurs utilisateurs, le cache dynamique allège la charge du réseau et réduit la charge de travail des hôtes de données. L'utilisation du cache dynamique améliore également les performances réseau en fournissant des temps de réponse aux utilisateurs, car elle supprime les attentes et réduit l'utilisation de la bande passante en raison d'un nombre plus faible de noeuds Internet.