Infrastructure Web
Web ASP.NET Cache Spurs performances et évolutivité
Iqbal Khan
En un coup de œil :
- Réduction de goulot d'étranglement considérable
- Mise en cache statique et dynamique Web
- Fonctionnalités doivent avoir : délais d'expiration, base de données dépendance, contenu partiel PDF, plus
- Avantages spéciales pour les organisations internationales
- Clusters de serveurs cache Web
- Solutions gratuites et commerciale
Le problème : Les goulots d'étranglement ASP.NET
La solution : Cache Web ASP.NET
Fonctionnalités doivent avoir de Cache Web
Délais d'expiration
Rechargement des pages sur les délais d'expiration
Cache de page partielle
Dépendances de base de données
Dépendances de fichier
Contenu partiel PDF
Mise en cache de ViewState
Compression gzip
Cluster de Cache Web évolutif et dynamique
Distribution de cache géographiques
Rester rangement à partir de la base de données
Instructions
Applications basées sur ASP.NET, infrastructure d'application Web de Microsoft, effectuez inroads supérieurs dans l'entreprise. En même temps, goulots d'étranglement résultant d'augmente le nombre d'utilisateurs et transactions continuent à demander informaticien pour améliorer les performances et évolutivité.
Le problème : Les goulots d'étranglement ASP.NET
Les goulets d'étranglement peuvent apparaître dans les applications ASP.NET pour diverses raisons. Le plus évident : technologie de stockage de données n'est pas aussi évolutive qu'architecture d'applications Web. N'importe où dans une application ASP.NET qui traite immédiatement de stockage des données ou accès aux données devient un logjam lorsque vous essayez de faire évoluer votre application. Deux zones où cela se produit sont état de session les données de stockage et l'application d'une base de données relationnel ou macroordinateur (voir figure 1 ).
Figure 1 engorgements zones communes de performances dans les applications ASP.NET.
Un autre goulet d'étranglement se produit si votre application ASP.NET fait orienté service-SOA (architecture) appelle aux services Web. Ici, le ralentissement se produit car les services Web ont les mêmes problèmes que votre application ASP.NET (à savoir, de stockage de données et accès). Il est probable qu'est une batterie de serveurs Web services est partagé entre plusieurs applications et, par conséquent, être sollicités beaucoup plus que tout une application ASP.NET, crée le goulet d'étranglement l'évolutivité.
Les goulets d'étranglement peuvent se produire également entre navigateur de l'utilisateur et de la batterie de serveurs Web ASP.NET. Ces clogs concernent le fait que les pages ASP.NET avoir à exécuter à plusieurs reprises au moment d'impliquant gourmandes en ressources processeur. Ce processus implique également l'envoi des éléments de données importante (images, documents, etc.) à l'utilisateur fois.
Dans une précédente TechNet Magazine article, j'abordés problèmes de performances et évolutivité ASP.NET, se concentrant sur l'état de session et données d'application (voir" Fournissant l'évolutivité pour les applications ASP.NET«Juin 2009). Dans cet article, j'ai abordé comment ces problèmes, y compris les raisons que l'état de session ASP.NET devient un logjam comme une batterie de serveurs Web augmente. J'ai abordé le fait que distribuée en mémoire cache constitue une alternative supérieure à Microsoft d'existant option de stockage d'état de session ASP.NET. J'ai décrit comment données d'application provenant d'une base de données peuvent entraîner des goulets d'étranglement l'évolutivité. Je détaillées également comment distribuée résout la mise en cache les engorgements de stockage état de session ASP.NET à l'aide de différentes topologies de mise en cache chaque offre différentes fonctionnalités, mais toutes les adresses évolutivité et de garantit la disponibilité de 100 pour cent.
Enfin, je génériquement profilé les différents distribué mise en cache les options disponibles sur le marché. Certaines options sont gratuites avec fonctionnalités limitées, tandis que d'autres sont plus robustes et riche commerciales produits. Toutefois, pour optimiser les performances et évolutivité, il est prudent d'envisager des produits commerciaux en haut de ligne.
La solution : Cache Web ASP.NET
Avec cette définition de problème comme toile de fond, principal objectif cet article est de performances et évolutivité goulots d'étranglement entre navigateur de l'utilisateur et le serveur Web ou batterie de serveurs Web. Dans l'idéal, vous souhaitez réduire le nombre de fois que la page Web s'exécute. Si la page Web est exécutée une fois la modification de sa sortie n'est pas encore brièvement, pourquoi exécuter ensuite à nouveau ? Pourquoi ne pas seulement en cache la sortie ? Puis la prochaine fois un utilisateur peut simplement extraire sortie de cette page directement dans le cache, et non ré-exécution il. Ré-exécution de la page implique l'UC, consomme de la mémoire et utilise d'autres ressources de serveur Web, et ensuite, bien sûr, il existe les problèmes de goulot d'étranglement au niveau de l'évolutivité du stockage des données.
Sortie d'une page ASP.NET peut être mise en cache sur le serveur Web lui-même, Microsoft fournit le mécanisme de cache de sortie ASP.NET vous permet de faire et fonctionne bien. Cependant, j'ai deux questions sur le cache de sortie ASP.NET.
Tout d'abord, elle nécessite que vous modifiez votre code ASP.NET et, au minimum, placez les balises sur ces pages pour indiquer que vous souhaitez mettre en cache de leur sortie. Ce n'est pas toujours possible pour une personne informatique qui gère les développées en interne et externe acheté des applications ASP.NET. Chaque fois que vous modifiez votre code d'application, vous devez accéder via les efforts d'assurance qualité pour vous assurer que rien n'a interrompu dans le processus. Cela augmente le coût d'intégrer la mise en cache.
Deuxièmement, cache de sortie ASP.NET met en cache sortie de page locale sur chaque serveur Web et, en fait, dans chaque processus de travail. Cela crée des problèmes majeurs en termes de cohérence et l'évolutivité si vous avez un jardin Web (c'est-à-dire plusieurs processus de travail sur un serveur Web) ou une batterie à charge équilibrée. Dans ces cas, vous avez plusieurs copies déconnectés de la mémoire cache ; pour le trafic élevé sites Web, cela peut devenir un cauchemar de gestion. Dans ASP.NET 4.0, Microsoft est promesse d'une infrastructure de mise en cache extensible qui vous permet de conserver le cache dans une processus distinct ou le niveau en incorporant un cache distribué par des tiers.
Au vu de ce développement, je préfère sortie de page cache pas sur le serveur Web, mais sur un serveur cache Web distinct qui se trouve entre les utilisateurs et votre site Web de la batterie (type de comme un proxy inverse ; voir la figure 2 ). Si de nombreuses requêtes de l'utilisateur ne le faites à la batterie de serveurs Web et proviennent d'un cache entre en revanche, vous êtes en réduisant la charge sur votre batterie de serveurs Web et améliorer l'évolutivité de la batterie. L'extraction de sortie d'une page Web à partir du cache et retourner à l'utilisateur nécessitent beaucoup moins de ressources qu'en réalité l'exécution de cette page Web. C'est parce que le cache est un stockage en mémoire très performant et évolutif, contrairement à un stockage sur disque qui peut avoir des problèmes de performances et évolutivité.
La figure 2 serveurs cache Web située entre les utilisateurs et serveurs Web.
Dans ce contexte, je vais étudier comment la mise en cache la sortie de pages Web peut résoudre les goulots d'étranglement et améliorer considérablement l'évolutivité et les performances. Un serveur cache Web peut jouer un rôle important dans ces objectifs.
Un serveur cache Web intercepte des requêtes http par les utilisateurs de pages Web et vérifie pour voir si sortie les pages d'existe déjà dans le cache. Si tel est le cas, le serveur cache Web renvoie que la sortie à l'utilisateur. La demande utilisateur jamais même rend les serveurs Web. Car il est en cours extraites à partir du cache, le retour est extrêmement rapide. Et car elle se trouve dans la mémoire et la page ne doit pas être réexécutée, un grand nombre de processeur est ainsi enregistré.
Un serveur cache Web peut fonctionner avec n'importe quelle plate-forme de technologie Web back-end. Tant qu'elles sont talking tout HTML et JavaScript, peu importe si l'application Web est développée dans Java, .NET, PHP ou une autre langue. En revanche, un serveur cache Web peut inclure certaines fonctionnalités spécifiques à la plate-forme, afin que les fonctionnalités différer à partir d'une solution à une solution.
Il existe deux types de solutions de la mise en cache Web. Des données relativement statiques, ce qui signifie que chaque page en cours mis en cache est censé être principalement met en cache totalement statique ou de modifier à des intervalles prévisibles. La page entière est mis en cache pendant un certain moment, après laquelle il expire et est supprimé du cache. L'autre type est pour la mise en cache dynamique, qui est plus approprié pour des sites Web dynamiques ou des applications Web.
Si votre application Web ou site Web est dynamique, où les données changent fréquemment et imprévisible, vous devez opter pour la mise en cache dynamique. De nos jours, la plupart des sites Web modifier au moins fréquemment leur contenu. Vous devriez pouvoir mettre en cache quelque chose pour au moins 15 à 30 secondes, mais normalement pour n'importe où à partir de quelques minutes à quelques heures et dans certains cas, pour les jours, voire plusieurs semaines.
Mise en cache Web offre un avantage important aux grandes entreprises dans le monde entier : la possibilité de répartir géographiquement les serveurs de la mise en cache Web. Dans une entreprise globale, votre application de site principal peut être hébergée à New York, mais que des utilisateurs du monde, San Francisco et Londres et Tokyo et Sydney et Dubaï. Maintenant, il est relativement facile pour que la mise en cache Web serveurs géographiquement situés dans chacun de ces domaines. Toutes les demandes provenant d'Europe passe via le serveur cache Web Europe avant qu'ils atteint votre site Web. De cette manière, ils ne doivent traverser l'Océan Atlantique et supporter cette latence de 100 millisecondes que chaque paquet doit traverser. Elles puissent obtenir en fait une copie d'un cache à proximité.
Prenons un autre exemple. Vous avez un serveur dans Dubaï desservant les régions Moyen-Orient et Asie du Sud et vous avez des centaines de milliers d'utilisateurs accédant simultanément votre site Web. Avec la mise en cache Web, le trafic vers votre centre de données principale à New York supprime considérablement. Pas tout le trafic est arrêté, car vous ne pas mettre en cache tout et tout ce que vous mettez en cache est également supprimé du cache (qui est, invalidé) le temps. Mais selon la nature de votre application, vous avez probablement réduit le trafic de 30 à 50 pour cent.
Fonctionnalités doivent avoir de Cache Web
Au fil du temps, sites Web ont transformé d'afficher uniquement du contenu statique pour devenir des applications Web entièrement interactives avec des données dynamiques qui changent fréquemment. Que signifie que, dès aujourd'hui, un cache Web doit répondre à toutes les exigences d'un site Web dynamique. L'objectif est à mettre en cache autant du site Web de contenu possible, tout en même temps s'assurer que le contenu mis en cache est correct et non périmé ou hors de synchronisation avec les données sous-jacentes dans la base de données. Pour gérer tout cela, le cache Web doit éviter l'intégrité des données lors de l'accélération des performances et l'évolutivité à certaines fonctionnalités.
Une solution cache Web standard inclut les fonctionnalités suivantes.
Délais d'expiration
Fonctionnalité d'expiration permet de spécifier des informations sur les pages Web à mettre en cache et pour savoir comment les règles long. Et il vous permet à expirer les pages à l'heure absolue ou décalée de. Heure absolue signifie que vous souhaitez quelque chose à faire expirer un certain temps, qu'il s'agisse minuit aujourd'hui ou 10 minutes à partir de maintenant. Décalée temps dépend de si une certaine page utilise en permanence actuellement. Si une page n'est pas, s'il est en cours utilisé du tout, vous souhaiterez peut-être qu'il expire. Un délai d'inactivité serait expirer une page s'il n'est pas obtenir utilisé pour plus d'un certain laps de temps, par exemple, 10 ou 20 minutes.
Expiration absolue est probablement l'heure la plus importante d'expiration pour les pages Web. Produits de la mise en cache Web permettent de spécifier des règles et choisissez les modèles d'URL (appelé "URI") pour cache. Mise en cache Web vous permet de spécifier que certaines URL doit jamais être mis en cache. Il vous permet de spécifier certains types d'URL de cache pour un certains longueurs de temps.
Il doit également permettre de spécifier quand expiration différentes URL basée sur informations fournies dans les en-têtes HTTP qui accompagne la sortie d'URL. En-tête HTTP de chaque page peut contiennent les informations combien il peut être mis en cache, quand il expire et lorsque le était modifié pour la dernière fois. Ce sont les éléments Web cache peut vérifier pour contrôler si le contenu d'une page a été modifié et si elle doit télécharger un nouveau contenu dans le cache. Sans cette fonctionnalité, vous n'avez pas un permet d'invalider et de supprimer des données périmées.
Rechargement des pages sur les délais d'expiration
Une autre fonctionnalité importante est la possibilité de recharger automatiquement une page lorsqu'elle expire pour une raison quelconque, si d'expiration absolue ou temps d'inactivité. Par exemple, vous pouvez dire: «cette page est adaptée à 20 minutes suivant». Après 20 minutes, le cache Web re-fetches automatiquement cette page afin qu'il ait toujours la dernière copie.
De cette manière, vous n'est pas attendre la prochaine demande de l'utilisateur pour cette page. C'est parce que lorsque la demande provient, vous ne souhaitez que l'utilisateur de passer par le délai de l'extraction page depuis la batterie de serveurs Web. Étant donné que vous pouvez l'extraire en arrière-plan, peut prendre vous 5 à 10 secondes pour extraire à partir du serveur Web en exécutant tout d'abord. Mais qui est parfait, car au moment où que l'utilisateur obtient il, vous pourrez retour avec un temps de réponse sub-second, selon la loin l'utilisateur est.
Cache de page partielle
Certaines des pages qui apparaissent dans un navigateur contiennent plusieurs éléments qui ont chacun leur propre URL. Par conséquent, pour une page d'être restitué, le navigateur Web doit appeler plusieurs URL. Il réalise le même résultat qu'une page partielle, mais qu'elle est appelée pas «page partielle» car sur le côté serveur, chaque URL représente une page distincte et chaque page est mise en cache indépendamment et pour une durée différente, selon la nature de son contenu.
Dans d'autres situations, un site Web unique page est développé dans par son contenu est divisé sections. Certaines sections sont statiques et ne changent pas ; certaines parties sont dynamiques, avec chaque partie modification après un intervalle différent. En effet, sections page caches mise en cache de page partielle dépend de si elles sont statiques ou dynamiques et de durée qu'ils doivent être cache, plutôt que simplement mise en cache la page entière.
ASP.NET permet d'effectuer la mise en cache partielle-page de deux manières : contrôler la mise en cache et post-cache substitution. Les deux nécessitent que vous modifiez les pages ASP.NET particuliers où vous voulez faire cette mise en cache. Qui peut ne pas possible si vous n'avez pas vos propres ressources de développement et que vous n'avez pas développer cette application ASP.NET en interne. Néanmoins, une description de chaque type de page partielle mise en cache dans ASP.NET suit.
Vous pouvez effectuer la mise en page partielle cache dans ASP.NET en créant des contrôles utilisateur pour le contenu mis en cache et en marquant les contrôles utilisateur «pouvant être mis en cache.» Cela permet de pouvoir mettre en cache certaines parties de la page en tant que contrôles utilisateur afin que lorsque la page est réexécutée, ces parties soient simplement extraites du cache et pas réexécutées. Uniquement aux parties de la page qui ne sont pas désignés comme les contrôles utilisateur et ne sont pas marquées comme «pouvant être mis en cache sont réexécutée. "
Avec la substitution post-cache, la page est mise en cache, mais certaines parties ou les fragments qu'elle contient sont marqués «dynamique» ou «non mis en cache». Puis, lorsque cette page est réexécutée, seules les parties dynamiques ou non mis en cache sont réellement exécutées. Le reste de la page est obtenue à partir du cache et mis en cache et dynamiques est combinés pour retourner la sortie de la page.
Il est intéressant de noter que, mise en cache de page partielle ne peut être effectuée que sur le serveur Web. Pour cette raison, certains programmation est nécessaire. Dans le cas d'ASP.NET, mise en cache de page partielle est effectuée par programmation dans les pages ASP.NET afin de déterminer et quelle non — à mettre en cache. Mais cette mise en cache est effectuée sur le serveur Web lui-même et exécute toujours la page ASP.NET, au moins partiellement.
Dans ASP.NET, mise en cache de page partielle est implémenté en fonction de spécification de Microsoft, mais sur la plate-forme Java, une page partielle standard appelée Edge Service inclut (ESI) de mise en cache a émergé. ESI définit un langage de balisage simple basé sur XML qui définit les composants de page Web pouvant être mis en cache et non mis en cache qui peuvent être regroupées, assemblés et remis à la périphérie du réseau, que ce soit dans un réseau de livraison de contenu, navigateur de l'utilisateur final ou un serveur cache Web agissant comme un proxy inverse entre les navigateurs des utilisateurs et le serveur Web.
Ainsi, la mise en cache de page partielle est très spécifique à la plate-forme, et, bien sûr, pour ASP.NET, vous devez utiliser l'approche de Microsoft.
Dépendances de base de données
Une autre fonctionnalité clée est la dépendance de la base de données, ce qui permet une sortie à être invalidé à partir du cache lorsque correspondant de la page données dans la base de données changent. Sortie les pages de sont générée souvent en fonction des données dans la base de données. Les données qu'ils représentant proviennent d'une ou plusieurs lignes dans une ou plusieurs tables de base de données. Par conséquent, si les lignes modifier, ces pages doivent être supprimés du cache. Pour cette raison, la synchronisation de la base de données est une fonctionnalité importante. Cela signifie que lorsque les données changent dans la base de données, sortie ces pages de doit être rendus non valides et doit être supprimé du cache. Cette fonctionnalité permet de déterminer automatiquement lorsque certaines pages doivent être supprimés le cache.
Créer cette dépendance consiste en spécifiant une instruction «select» SQL (ou un appel de procédure stockée contenant une instruction select) qui correspond à la page en question, puis mapper certains des paramètres POST/GET page avec des paramètres dans l'instruction SQL. Au moment de l'exécution, les paramètres de page Web sont utilisés pour exécuter l'instruction SQL et un SqlCacheDependency est créé sur un SQL Server 2005/2008 ou Oracle 10 g R2 ou version ultérieure de base de données. Ainsi, lorsque la ligne correspondante dans la base de données les modifications, le serveur de base de données déclenche un événement .NET qui est capturé par le serveur cache Web. Puis est supprimé du cache de sortie de la page correspondante (voir figure 3 ).
La figure 3 page retiré du cache Web si base de données modifications de ligne.
Dépendances de fichier
Une autre fonctionnalité clée est la dépendance de fichier. Vous pouvez associer une sortie de page à un fichier dans le système avec les instructions de: "Si ce fichier est déjà mis à jour ou supprimé, Veuillez annuler cette page." Le cache Web contrôle ensuite ce fichier, qui est conservé dans un dossier partagé. Si ce fichier est déjà mis à jour ou supprimé, le cache Web annule automatiquement l'URL correspondante à partir du cache. Cela vous permet mettre à jour de fichiers à partir de n'importe où dans votre système, si elle implique une autre application ou même un déclencheur dans le serveur de base de données en fonction des lors certaines des modifications de données. Par exemple, si vos données sont stockées sur un ordinateur central plutôt que dans SQL 2005/2008 ou Oracle bases de données, vous pouvez utiliser une dépendance de fichier pour invalider une page de cache.
Tout cela vous avertir le cache permet de quand à invalider si certains événements se produisent dans votre magasin de données ou dans votre environnement, qui ne sont pas directement accessibles par le cache Web.
Contenu partiel PDF
De nombreuses personnes désormais accéder en ligne les fichiers PDF. Le modèle de l'utilisation courante est qu'ils lire une page à la fois, passer par le fichier PDF tout page par page. Peu de personnes télécharger un PDF ensemble et lire localement ; plus le lire dans leur navigateur. Lorsque les visualisez les informations de cette façon, qu'ils ne lisent généralement la totalité du document ; ils abandonner après avoir obtenu via une partie de celui-ci.
Donc desservant ce dernier ensemble est souvent une perte de ressources ; en fait peut-être le facteur de différenciation entre performances acceptables et inacceptables aux heures de pointe. Pour cette raison, gestion PDF de contenu partiel est une fonctionnalité importante dans un cache Web. Elle réduit la charge de la bande passante sur le serveur Web et améliore l'évolutivité globale.
Mise en cache de ViewState
Parmi les fonctionnalités les plus importantes de ASP.NET est la possibilité de déclarer des contrôles qui s'exécutent sur le serveur et post-back à la même page. Avant vers ASP.NET, dans l'ASP classique, vous avez terminé de créer plusieurs pages pour gérer les différentes opérations qui, logiquement, appartenaient à une page — par exemple, lors du chargement des données, l'enregistrement de données ou autres actions entreprises. Mais dans ASP.NET, vous avez plus à le faire. Champs de formulaire et d'autres contrôles peuvent maintenant être déclarés s'exécutent sur le serveur et le serveur publie simplement la page sur elle-même.
Pour gérer ces post-backs, un ViewState est créée qui mémorise l'identité des contrôles et les informations dynamiques affectées à ces contrôles. Par essence, ViewState conserve l'état des contrôles d'une page dans plusieurs publications.
ViewState est importante pour les applications ASP.NET. Fondamentalement, ses informations envoyées par le serveur Web au navigateur pour que le navigateur puisse envoyer les mêmes informations sur le serveur de l'utilisateur de temps suivant effectue une publication de la même page.
Par exemple, vous pouvez charger un client sur la page customer.aspx. Ensuite, vous apportez des modifications dans les données client, puis cliquez sur «Enregistrer». Le bouton Enregistrer appelle à nouveau customer.aspx, mais envoie également le ViewState pour que le customer.aspx sache comment gérer cette publication. Le ViewState contient les informations que customer.aspx a envoyé au navigateur et la publication contient les nouvelles données l'utilisateur a peut-être modifié. Qui permet de customer.aspx déterminer ce qui a changé et comment procéder à son sujet. Il s'agit uniquement un exemple simple ; ViewState peut également contenir autres données créées dynamiquement pour chaque contrôle sur la page.
Bien que ViewState soit très utile dans ASP.NET, il comporte également le coût de transfert et la réception des données à partir d'un serveur Web et navigateur de l'utilisateur. Ce coût peut avoir un performances et un impact de l'évolutivité au cours des charges maximales de l'application et lorsque les utilisateurs sont loin du serveur Web et via une connexion Internet lente.
Mais le ViewState n'a souvent à se déplacer vers le navigateur si mis en cache dans le cache Web. Dans ce cas, seule une balise ou un ID unique peut être envoyé au navigateur afin que si le navigateur revient, le cache Web serait réinsérez un ViewState et permettent de remettre le serveur Web en fonction de l'ID unique. Tout un site Web serveur requiert est que la prochaine fois que le navigateur envoie la demande, il contient le ViewState à partir du moment précédent. Peu importe que le ViewState atteint le navigateur, car le navigateur utilise jamais ces informations — uniquement le serveur Web.
En termes techniques, un ViewState est utilisé pour publication, si vous faites jamais post-backs, vous devez un ViewState, et un cache Web peut mettre en cache un ViewState. Qui enregistre également la bande passante considérable, car un ViewState est seulement quelques kilo-octets en taille.
Compression gzip
De nos jours, la plupart des navigateurs peuvent décompresser le contenu compressé gzip. Mais pas tous les serveurs Web sont configurés pour compresser automatiquement la sortie de pages Web. Et même si la compression est activée, il consomme beaucoup de processeur inutile sur chaque serveur Web, qui est déjà en cours sollicité par un trafic important. Cependant, si la compression est effectuée par un serveur cache Web proxy intermédiaire, il devient plus évolutif.
Il est plus simple compresser des données statiques qui ne change jamais. Toutefois, la plupart des pages dans une application ASP.NET sont dynamiques et leur contenu doit être compressé uniquement si la sortie de page n'est pas de modification chaque fois. Dans le cas contraire, la compression mettriez une charge excessive sur le processeur, peut-être dwarfing les gains de l'utilisation de la bande passante. Mais, car un cache Web est déjà intelligemment de découvrir la sortie des pages dynamiques est mise en cache (c'est-à-dire qu'il ne change pas pendant au moins une courte période de temps), il est également capable de compresser automatiquement les pages du cache. Ensuite, ces pages mises en cache sont servies à plusieurs reprises aux clients sous forme compressée et réduit considérablement l'utilisation de la bande passante.
Une compression gzip standard réduit le contenu en presque 80 pour cent, à moins que le contenu est déjà compressé (par exemple, PDF, JPEG, TIFF, etc.). Un cache Web bon doit autoriser l'utilisateur de spécifier les URL pour compresser et à ignorer pour la compression.
Cluster de Cache Web évolutif et dynamique
Un cache Web est un serveur qui se trouve devant une batterie Web ASP.NET (presque comme un dispositif). Aujourd'hui, batteries de serveurs Web ASP.NET peuvent atteindre à partir de deux serveurs 100-plus serveurs avec un équilibreur de charge. Par conséquent, un seul serveur cache Web est incapable de gérer la charge d'une batterie croissante. Une règle empirique est que pour chaque cinq serveurs Web dans la batterie de serveurs, vous devez avoir un serveur cache Web.
Lorsque plusieurs serveurs de cache Web seulement améliore l'évolutivité, mais permet également le cache Web pour la réplication afin que si un serveur tombe en panne ou est arrêté, le cache n'est pas perdu et il n'y a aucune dégradation des performances (voir La figure 4 ).
La figure 4 cluster de cache Web dynamique (ajouter ou supprimer des serveurs à l'exécution).
Un serveur cache Web correct doit être en mesure de créer un cluster de serveurs de la mise en cache Web pour gérer la fiabilité grâce à la réplication et l'évolutivité par le biais de plusieurs serveurs. Toutefois, de la mise en cache-serveurs Web sont impliqués, il est toujours considéré comme un cache Web logique. Même s'il existe plusieurs copies du cache dans le cluster, ils sont toujours reste synchronisés. En bref, un cluster de serveurs de la mise en cache Web permet d'évoluer tout en conservant l'exactitude de la mémoire cache logique.
Lorsque vous avez un cluster de cache, un cache Web bon doit permettent de spécifier différentes options stocker en cache, également appelées mise en cache de topologies. Les topologies principales incluent cache répliqué, cache partitionné et cache client.
Répliquées cache signifie que le cache entier est copié sur chaque serveur de cache dans le cluster. Par conséquent, chaque serveur de cache possède le cache entier. Toutes les opérations «get» sont toujours locales à cette zone et, par conséquent, sont très rapides. Toutefois, les mises à jour sont effectuées sur plusieurs serveurs de cache, et s'il existe plus de deux des serveurs du cluster, le coût de mise à jour augmente.
D'autre part, cache partitionné sauts (ou partitions) du cache, stockage de chaque partition sur un serveur cache différent. Le nombre de partitions est égal au nombre de serveurs cache. Ainsi, vous pouvez augmenter la capacité de stockage du cache en ajoutant plusieurs serveurs cache, ce que vous ne pouvez pas faire dans le cache répliqué. Partition cache vous permet créer des sauvegardes de chaque partition sur un serveur de cache différent afin que si un de ces serveurs tombe en panne, vous ne perdez le cache. Le cache de partition est la topologie de mise en cache plus évolutive pour le stockage et transactions par seconde.
Enfin, le cache de client est une topologie qui est combinée avec partitionnées ou cache répliqué (surtout si le cache réel est hébergé sur un serveur autre que le serveur cache Web). Cache client conserve un petit sous-ensemble du cache dans le processus de client de sorte que les données fréquemment utilisées soient toujours disponibles fermez par. Qu'est conservé dans le cache client varie selon que ce client récemment extrait. Vous pouvez spécifier une taille maximale pour le client cache afin que lorsqu'il atteint cette taille, il commence à supprimer (ou supprimer) les anciens éléments pour libérer de l'espace pour les nouveaux. De cette façon, le cache client ne consomme plus de mémoire que vous avez déterminé est possible.
Si vous utilisez plusieurs serveurs de cache Web sans création d'un cluster de cache, vous obtenez plusieurs copies déconnectés de la mémoire cache. Ce résultat peut être acceptable si votre site Web est relativement statique, mais pour des sites Web dynamiques et des applications ASP.NET, qui peuvent provoquer des problèmes de l'intégrité des données. En outre, vous obtiendrez envoyer la demande utilisateur au serveur Web même si un autre serveur Cache Web est le résultat de cette page dans le cache, augmentant ainsi la charge de la batterie de serveurs Web ASP.NET.
Distribution de cache géographiques
De nombreux application ASP.NET sites aujourd'hui avoir les utilisateurs dans le monde entier même si le site Web proprement dit est hébergé dans un seul emplacement. Il est souvent impossible pour le site Web se trouvent dans plusieurs emplacements géographiques en raison de la complexité et le coût de son infrastructure. Par exemple, une batterie de serveurs ASP.NET a également disposer d'un serveur de base de données dans le même emplacement ; serveurs de base de données ne sont pas généralement idéales pour la distribution géographique lorsque elles impliquent des applications hautement transactionnelles. Par conséquent, les utilisateurs finaux rencontrer ralentissement des performances en raison de latence du réseau (WAN) étendu.
Pour résoudre ce problème consiste à placer les serveurs cache Web dans chaque emplacement géographique, puis d'acheminer le trafic de cette zone par le serveur cache Web le plus proche (voir figure 5 ). Si un serveur cache Web n'a pas une page déjà mise en cache, il directement envoie ensuite la requête au centre de données principale, où se trouve un autre ensemble de serveurs cache Web.
La figure 5 serveur cache Web distribué géographiquement environnement.
Pour un cache Web correct doit avoir la possibilité de créer une hiérarchie de serveurs pour que chaque cache Web sache où acheminer la demande, même si elle n'a pas la page mise en cache.
Rester rangement à partir de la base de données
Comme indiqué dans mon article de juin 2009, les données ne changent chaque fois ; il reste constante. Malheureusement, sans mise en cache distribuée, vous allez via inutiles de cycles pour reproduire maintes et maintes ces mêmes données. Mais vous n'avez pas accéder à la base de données de tout le temps. Les données de même, alors pourquoi faire ? Pourquoi ne pas le prendre à partir du cache ?
Voici un exemple pour mettre en évidence ce problème. Page web principale d'une compagnie aérienne n'est pas la modification de la plupart ; il peut être mis en cache pendant une longue période. Un client visite pour rechercher des vols. Les informations sont constamment décalage car comme sièges de livres autres utilisateurs, les informations changent sur le serveur principal.
Si le client recherche, par exemple, un vol à partir de New York à San Francisco, du siège disponibilité détermine les résultats. Disponibilité du siège est basée sur le nombre de personnes déjà enregistré avec des réservations qui se passe en permanence. Un vendeur surmené peut compliquer les choses par saisie des informations incorrectes ou d'effectuer plusieurs entrées afin de garantir une affectation de poste.
L'utilisateur reçoit les résultats indiquant qu'un vol particulier est disponible, avec ces informations modification dans le cache de toutes les cinq minutes. Mais une fois que le client souhaite réellement réserve un siège, une vérification en temps réel est effectuée dans la base de données. C'est parce que chaque 1 000 personnes vérifier sa disponibilité vol, probablement seulement environ 10 réellement effectuer une réservation. Il est bien de disponibilité de vol les visiteurs, même si les informations fournies ne peuvent pas être entièrement correctes. Dans ce cas, vous pouvez mettre en cache cette page même s'il est hautement dynamique.
Mais vous pouvez mettre elle cache avec l'idée qu'il est acceptable pour fournir des informations avec un risque que qu'il n'est pas complètement exacte. Toutefois, dans la page réservations de la base de données, il est essentiel pour garantir que toutes les informations sont précis et à jour. Le point ici est que chaque application possède des informations communes qui peuvent être mis en cache et un utilisateur de site Web ne doit pas être envoyé à base de données de la compagnie aérienne chaque fois.
L'étape plus simple consiste lorsque vous souhaitez mettre en cache toutes les images. Vous ne modifiez pas votre logo de société ou votre président image ou documents standard que vous avez disponibles pour les personnes à lire. Mais ensuite des autres parties qui sont plus dynamiques. Où vous pouvez spécifier des règles et Supposons, par exemple, «je veux mise en cache cette page pour cette longue."
Avec d'autres pages, vous pouvez par exemple, «je ne peut pas dire combien de temps il va être mis en cache, et vous souhaitez lier à la base de données. Si cette ligne dans cette table est modifiée, je que cette page être rendus non valides." Cela signifie que retirant du cache et recharger, créer une nouvelle copie. Chaque catégorie de page est différente. Tant qu'un cache Web permet de déterminer comment vous souhaitez pages du cache, vous créez une situation dans laquelle plus mettre en cache, moins vous accédez à la batterie de serveurs Web.
Instructions
Dans la plupart des cas, vous pouvez obtenir des avantages significatifs en déployant cache Web. Si vous avez seulement un serveur Web, il est probable qu'est qu'inutile suffisamment le trafic à rencontrer ces types de problèmes. Mais si vous avez au moins 1 000 utilisateurs, vous avez probablement déjà une batterie à charge équilibrée. Dans ce cas, vous êtes un candidat pour Explorer les façons d'optimiser les performances et évolutivité.
Planifiez. Ne pas attendre des problèmes à se produire car une fois que ce cas, vous serez en mode panic. Le meilleur moment est lorsque vous ne sont pas face à des problèmes majeurs, mais à ce stade, vous devez être capable de convaincre la direction supérieure sur pourquoi vous avez besoin de financement d'un tel projet. Un bon moyen de réaliser cet objectif : demander gestion quel qu'il peut coût votre entreprise si votre site Web fourni temps de réponse lent painfully pendant les heures creuses (hausse de 30 à 60 secondes par clic). Et que se passe-t-il si votre site Web est arrêtée de 30 à 60 minutes ? Étudié ces questions peut aider à convaincre la direction de votre organisation sur la nécessité d'un cache Web.
Comme indiqué précédemment, dans le commerce et libre options de la mise en cache Web sont disponibles. Avec la popularité croissante d'ASP .NET parmi les développeurs, commerciales options de mise en cache Web qui prennent en charge .NET sont maintenant émergentes. Toutefois, à cette écriture, la plupart des produits de la mise en cache Web en charge Java et PHP. La plupart est basée sur les logiciels, mais certaines options dispositif matériel sont ainsi disponibles.
Que vous envisagez de votre choix, restent concentrés sur votre organisation et le site Web. Dynamique est le site ? Combien d'utilisateurs disposez-vous ? Quelle mise en cache va vraiment vous aider ?
Envisagez les fonctionnalités de mise en cache vous avez besoin. Comme nous l'avons vu, la mise en cache permet des transactions blazingly rapides et évolutives. Mais il peut parfois donner aux utilisateurs des informations périmées. Pensez que le solde que vous envisagez des solutions différentes.
Iqbal KHAN est le président et développeur technique de Alachisoft. Alachisoft fournit NWebCache, qui est un cache Web ASP.NET à gauche pour augmenter les performances et l'évolutivité. Iqbal a reçu une maîtrise Diplôme d'informatique de Indiana University, Bloomington, en 1990. Vous pouvez le contacter au iqbal@Alachisoft.com.