Infrastructure Web
Fournir l'évolutivité pour les applications ASP.NET
Iqbal Khan
À une vue d'ensemble :
- Goulots d'étranglement de l'évolutivité dans les applications ASP.NET
- Options de stockage état de session
- Topologies de mise en cache disponibles
- Fonctionnalités de cache distribuées nécessaires
Contenu
Où sont les problèmes
Pourquoi ces problèmes existe
Quelle est la réponse ?
Topologies de mise en cache
Différents choix
Le monde réel
La popularité d'ASP.NET, l'infrastructure d'application Web de Microsoft, continue de croître par des limites dans le développeur, Entreprise et les rangs informatique et leaps. Il est une zone de difficulté, toutefois : échelle des applications ASP.NET hors de la zone simplement n'est pas possible.
L'évolutivité a deux significations dans ce contexte. Tout d'abord, vous devez pouvoir gérer efficacement les charges d'utilisateurs maximal parce que chaque application parcourt pics et creux en termes du nombre d'utilisateurs connectés à tout moment dans le temps. Lorsque vous concevez l'infrastructure, que vous souhaitez concevoir l'application afin qu'il peut gérer les charges maximales en tant que charge aussi rapidement et efficacement que nonpeak.
Ensuite, vous devez pouvoir augmenter la capacité totale de votre système. Aujourd'hui, vous devrez uniquement 5 000 utilisateurs. Six mois, une année le déplacement, vous pouvez ont 10 000 15,000 ou 20 000 et d'en quelques années vous pouvez fin avec 100 000 utilisateurs. Pouvoir agrandir avec le nombre d'utilisateurs sans essouffler l'application à un arrêt est quel évolutivité concerne toutes les. Cela signifie que vous pouvez ajouter plusieurs utilisateurs sans impact négatif sur les performances en aucune manière notable ou si il y a des pertes, elle doit être dans une plage acceptable.
Une application ASP.NET classique est déployée sur un ou plusieurs serveurs Web sont liées dans une batterie de serveurs Web, avec un équilibreur de charge qui distribue le trafic vers tous les serveurs Web. En théorie, les serveurs Web plus vous ajoutez, les demandes de plus vous devez pouvoir traiter par seconde. L'architecture d'une batterie de serveurs Web est conçue pour donner une évolutivité à ASP.NET. C'est la théorie ; la réalité est un peu différent.
Le problème pour les applications ASP.NET est que technologie Web fournit une architecture élégante de batteries de serveurs Web et équilibreurs de charge, les technologies de stockage de données ont conservé pas des. Certainement que pouvez échelle arrière dans une application Web en ajoutant plus de serveurs ou en augmentant la puissance de serveurs individuels avec plus de mémoire et de puissance du processeur.
Mais comme vous le faites que, stockage de données n'est pas en mesure de échelle dans les mêmes proportions. Il redimensionner, mais pas autant que la couche d'application Web. Par conséquent, tout élément de votre application ASP.NET associée stockage de données ou un accès aux données est un goulot d'étranglement l'évolutivité potentielle. Plus vers le point, un serveur de base de données ne pas échelle pour les données des sessions ou des applications.
Où sont les problèmes
Voyons les actions différentes accès ou un stockage qui se dans une application ASP.NET, commençant par le stockage de session. Pour chaque demande utilisateur, une session est lu à partir de l'emplacement de stockage au début et écrites sur le stockage à la fin de la réponse. Au début de la requête utilisateur, la page doit exécuter et, pour cela, il doit les données de session. Les données de toute session, appelées « objet de session », sont chargées afin que la page, tandis que s'exécute, pouvez référencer ces données. La page lit des données de l'objet de session. Il insère des données plus dans l'objet de session. Tout se produit dans le processus ASP.NET et aucun aller-retour de stockage de session n'est reliés.
Fait de la page en cours d'exécution, certains résultant doit être renvoyé à l'utilisateur. La session est probablement mis à jour pendant ce temps afin que maintenant la session doit être enregistré à l'emplacement de stockage. Il sera conservé stockée jusqu'à ce que la requête suivante de l'utilisateur de la même session et le même processus répète lui-même.
Du point de vue d'un utilisateur, vous cliquez sur un lien ; au moment où que l'utilisateur voit la page qui provient de ce lien, une session a été lu et une session a été écrit sur le stockage une seule fois. Ainsi, il existe deux aller-retour vers un stockage de session que l'application ASP.NET a apportées.
Maintenant vous effectuer le calcul. Si vous avez 10 000 utilisateurs toutes les pages de l'accès en même temps, vous aurez peut-être 1 000 demandes par seconde. Cliquer chaque utilisateur va être sur quelque chose chaque quelques secondes, ainsi, toutes les secondes que vous vous avez au moins 1 000 et probablement plus demande va de la batterie de serveurs Web.
Supposons que 1 000 ou plusieurs demandes allez la batterie de serveurs Web et chaque requête va les résultats de serveur Web en deux aller-retour vers le stockage de session. Du point de vue du Web, cela signifie 2 000 aller-retour vers le stockage de session. Vous pouvez voir rapidement la charge peut augmenter. Voici un seul endroit qu'un goulot d'étranglement de l'évolutivité peut se produire.
Goulots d'étranglement de l'évolutivité peuvent également se produire pendant une page est en cours d'exécution et à lire ou écrire des données application. Nous allons utiliser compagnie aérienne vol disponibilité comme exemple. L'utilisateur clique sur une page pour rechercher des vols d'un emplacement à un autre, qui peuvent la suite de plusieurs voyages lecture dans la base de données d'application. Ensuite, bien entendu, l'utilisateur souhaite effectuer une réservation vol qui nécessite des données être placé dans la base de données. Ces données sont appelées « données application » et elle est stockée dans la base de données, ce opération d'enregistrement peut rendre plusieurs voyages de base de données pour stocker plusieurs éléments de données.
Par conséquent, vous pouvez, au final, nécessaires avec le nombre d'aller-retour de base de données étant 5, 10, 15 ou 20 fois plus le nombre réel de demandes des utilisateurs. Ainsi, les contraintes sur la base de données sont qui beaucoup plus, et ce peut être un goulot d'étranglement principal.
Un troisième goulot d'étranglement de l'évolutivité est fourni sur Si vous utilisez un environnement SOA (architecture orientée service) et que votre application effectue des appels à une autre couche de service, qui peut être dans le centre de données ou dans un centre de données différents.
L'architecture de couche serveur généralement implique une batterie de serveurs et est donc évolutive de la même manière architecture d'application Web est. Mais la couche de service a les même goulots d'étranglement l'évolutivité de l'application car il repose sur sa propre base de données.
Ainsi, votre application a dépendances sur d'autres services qui ont des dépendances sur leurs bases de données, qui à son tour ont goulots d'étranglement de l'évolutivité, et la chaîne n'est qu'aussi forte que son lien plus faible. Si un service de ne pas redimensionner en raison de sa base de données, votre application ne peut pas échelle (voir figure 1 ).
La figure 1 la base de données devient un goulet d'étranglement qu'augmente de la batterie de serveurs Web.
Très peu si la base de données est un macroordinateur ou une base de données relationnelle. Le accès aux données ou le stockage de données simplement ne peut pas mettre à l'échelle et il ne peut pas conservez s'adapter avec l'évolutivité de la technologie Web. Et ces goulots d'étranglement dans le stockage de données empêche les applications ASP.NET de mise à l'échelle.
Pourquoi ces problèmes existe
Pourquoi ne peut pas stocker les données échelle ? Nous allons tout d'abord résoudre trois options de stockage de l'état de session Microsoft fournit : InProc, StateServer et SqlServer. InProc a ses limites. Il a été conçu pour être utilisé dans un environnement à serveur unique, processus unique, et il ne fonctionne pas dans un environnement ASP.NET multiserveur ou multi-process. La session n'est pas conservée.
Voici ce qui se passe. L'utilisateur commence à un serveur, et la session est créée. Si l'équilibrage de charge envoie ensuite l'utilisateur vers un autre serveur, l'application ne trouvera pas cette session ; il est pense que l'utilisateur est début nouvelle et demander à son pour vous connecter à nouveau. Chaque fois qu'un utilisateur clique sur quoi que ce soit, elle vous devez être connecté donc elle va être en mesure de continuer. L'application ne fonctionne pas.
Un moyen vous pouvez résoudre cela est d'utiliser la fonctionnalité « sessions pense-bête », qui vous permet toujours gamme de la demande utilisateur sauvegarder sur le même serveur pour l'application va trouver cette session sur le serveur.
Vous pouvez également gérer InProc limitations en créant ne pas un jardin Web sur le serveur. Un jardin Web est lorsque votre application comporte plusieurs processus de travail ASP.NET s'exécutant sur le même serveur. Si vous éviter l'aide d'un jardin Web, il y a qu'un seul processus et qui permet au moins InProc être utilisée dans une batterie de serveurs Web.
Ces contournements deux sont loin d'être idéal, cependant. Sessions pense-bête peuvent entraîner un goulet d'étranglement évolutivité principale car la charge sur certains serveurs augmente plus que d'autres personnes, car la durée d'une session utilisateur n'est pas uniforme. Certains utilisateurs se connecter pour uniquement une minute, d'autres personnes de 20 minutes. Certains serveurs obtiendrez beaucoup de sessions, mais ceux va être presque vide ou libre ou inactif. Même si vous ajoutez plusieurs zones, vous ne sont pas nécessairement Amélioration du débit de.
En outre, InProc a des limitations de mémoire. Chaque session dans le processus ASP.NET nécessite de mémoire. Lorsque vous augmentez le nombre de sessions, les besoins de mémoire de votre processus de travail s'agrandit considérablement. Dans une plate-forme 32 bits, toutefois, il est une limite de mémoire 1 Go pour un processus de travail et qui est un problème. Vous ne pouvez pas agrandir des données de session au-delà de ce qu'ajustée à une mémoire de processus de travail un gigaoctet, avec autre code de données et d'applications. Ainsi, InProc provoque des goulots d'étranglement. Et les utilisateurs de plus, plus vous rencontrerez ces problèmes.
StateServer stocke l'état de session dans un processus qui est distinct du processus de traitement ASP.NET, mais il présente également les limitations. Vous pouvez configurer afin que chaque serveur Web contient son propre StateServer ou vous pouvez dédier une zone distincte et maintenir l'état complètement dans cette zone de.
La première option, le problème est que vous devez toujours utiliser les sessions du pense-bête. Chaque fois que la session a été créée, c'est où avoir toujours revenir à elle. Cette première option atténue uniquement la limitation de jardin InProc Web. Il n'est pas résoudre le problème du pense-bête sessions qui peut laisser des boîtes supplémentaires qui n'est pas obtenir utilisés alors que d'autres sont bouchées. L'effet visuel à l'utilisateur est que son temps session et la réponse devenir très lent.
L'autre inconvénient de cette option de configuration est que si n'importe quel serveur Web tombe en panne, le StateServer sur que zone de serveur Web également ralentit, donc vous perdez toutes les sessions. Cette propriété a la valeur True, vous ne perdez toutes les sessions d'un site Web, mais vous perdez les sessions stockées dans cette zone, et qui n'est pas acceptable. Idéalement, vous ne souhaitez perdre les sessions.
Si vous choisissez l'autre configuration offre StateServer, une zone StateServer dédiée, vous devez plus utiliser une session du pense-bête puisque chaque serveur Web s'affiche dans la même zone dédiée. Toutefois, maintenant vous avoir un problème plus grand : si cette zone jamais tombe en panne, la batterie de serveurs Web entier est vers le bas car chaque serveur Web tente d'obtenir la session à partir de cette zone.
Ce n'est pas tout. Cette zone StateServer dédiée obtient envahie que plusieurs serveurs Web sont ajoutés et promouvoir de transactions par seconde. Par conséquent, il devient rapidement un goulot d'étranglement de l'évolutivité. Ainsi, le problème de l'évolutivité est résolu pas avec StateServer, pas avec quelle que soit la configuration.
À présent nous à SqlServer, qui stocke l'état de session dans une base de données SQL Server et peut être considérés comme un StateServer dédié. Il s'agit de base de données premier serveur de Microsoft destinée aux environnements haute transaction. Il est plus évolutif qu'un StateServer car vous pouvez créer un cluster de serveurs de base de données.
Dans configuration SqlServer, tous les serveurs Web relier en fait à une zone de SqlServer dédiée où toutes les sessions sont stockées. C'est comme si chacun des serveurs Web ont été liée à une zone StateServer dédiée. Le concept derrière cette est que SqlServer sera plus évolutif qu'un StateServer. Mais SqlServer n'est pas aussi rapide comme un serveur d'état, car un StateServer est une banque de données en mémoire et a en conséquence, les performances acceptables. D'autre part, SqlServer n'est pas une banque de données en mémoire. Il est un magasin de données basée sur disque. Toutes les bases de données sont conservées sur disque, car ils agrandiront ainsi que la mémoire insuffisante contenir l'intégralité de la base de données. Par conséquent, une base de données enregistre ses données sur le stockage persistant, qui est un disque. En raison de stockage sur disque, performance SqlServer n'est pas aussi rapide, ce qui entraîne un dépôt de performances.
SqlServer peut provenir dans plusieurs configurations. Dans une configuration autonome, qui est le plus souvent, il existe seul serveur de base de données de communiquer avec tous les serveurs Web, et lorsque vous augmenter la taille de la batterie de serveurs Web et ajoutez plusieurs serveurs Web, vous placez charge plus et plus sur la base de données (voir figure 2 ).
La figure 2 sessions ASP.NET toujours un goulot d'étranglement et fullyscalable également pas de base de données
De plus, vous devez un problème de performances car SqlServer n'est pas basé sur la mémoire, et vous avez un problème d'évolutivité car il n'est pas en mesure de évoluer autant. Peut évoluer en effectuant le matériel plus puissants en ajoutant des processeurs à cette zone, mais vous ne pouvez pas ajoutez plus zones de serveur de base de données comme la croissance de la batterie de serveurs Web. Vous pouvez peut-être passer d'une à deux ou les deux à trois serveurs afin que SqlServer fournit une base de données clusters capacité, Échelle à plusieurs un StateServer, mais il a également ses limites.
Le autre problème SqlServer a de stockage est que toutes les sessions sont conservées dans une table unique. La contention de verrouillage pour l'accès simultané et mises à jour simultanées des données de session devient évidente dès que vous évoluer. Que vous disposiez plus et plus transactions par seconde, vous devez délais de verrouillage plus et plus car tout ce qu'est conservé dans une table.
Ainsi, tandis que SqlServer échelles plusieurs état Server, il vous envoie un problème de performances et n'est pas suffisamment échelle. En outre, il ne pas échelle façon linéaire. Vous sont censés pour être en mesure de s'agrandir une batterie de Web à partir d'un 5-à 50 à 100-batterie de serveurs et la batterie Web proprement dit est supposé pour augmenter très facilement ; toutefois, l'accès aux données ne croître pas diminué en conséquence. Comme je L'AI indiqué précédemment, une base de données est un de ces accès de stockage de données qui ne pas s'afin stockage sessions dans une base de données n'est pas prendre toute amélioration majeure. Il est uniquement une amélioration sur un environnement de serveur de l'état. En outre, un SqlServer devient un goulet d'étranglement données d'application ainsi que pour les sessions de données. Par conséquent, un serveur de base de données ne pas échelle pour les données des sessions ou des applications.
Quelle est la réponse ?
La solution est un mécanisme de stockage en mémoire, donc il peut être extrêmement rapide, aussi rapide qu'une StateServer. Toutefois, il doit être pratiquement linéairement évolutif. L'évolutivité linéaire signifie que lorsque vous ajoutez plus de serveurs, vous êtes presque multipliant la capacité. Par exemple, si vous pourriez gérer 10 000 transactions par seconde avec une zone, ajouter une deuxième boîte permettre doit à vous proche de transactions 20 000 par seconde total. Notez que « pratiquement linéaire » ne signifie exactement 20 000, il peut s'agir 19,000 ; il n'est pas, être toutefois, de 12,000 ou 15,000. Et c'est ce dont nous avons besoin : stockage peut devenir pratiquement linéairement et il doivent également être dans la mémoire.
En raison de ces deux besoins, nous pas parlons stockage persistant, qui a autres exigences et est destiné à long terme. Une base de données est conçu pour stockage à long terme, tandis que stockage en mémoire est toujours temporaire et temporaires. Mais nos besoins sont temporaires. Nous devons stocker des données de ce stockage temporaire pendant une session utilisateur ou peut-être pour la durée d'une application, quelques heures à quelques jours ou peut-être quelques semaines à la plupart. Ensuite ces données peuvent disparaissent car il est toujours permanent stockage principal, qui est la base de données où nous peut charger les données de nouveau.
Donc, tous de ce ESPRIT, nous pouvez considérer un mécanisme de stockage appelé un « distribué cache, » un concept est devenu populaire parce qu'elle offre les avantages citées ci-dessus, en tant que La figure 3 Affiche.
La figure 3 cache distribué qui pression sur le serveur de base de données
Un cache distribué est en mémoire, afin qu'il est rapide et elle vise à distribuer croissance façon relativement linéaire, en particulier si vous avez le mécanisme de distribution droite (également appelé topologie de mise en cache).
Un cache distribué doit fournir performances et évolutivité linéaire et car il existe en mémoire, il doit fournir la réplication afin que si n'importe quel ordinateur tombe en panne (la mémoire de cet ordinateur devient disponible), un autre ordinateur a les données et vous ne perdez les. La réplication fournit plusieurs copies des mêmes données dans des emplacements différents sur des zones différentes et en procédant, atteindre 100 % temps pour la durée de votre stockage de données.
Un cache distribué stocke un objet .NET ou un objet Java ou, pour ce problème, d'autres données comme un document XML. Il stocke des données dans un format prêt. Il n'a pas le concept de tables et de lignes et clés primaires et étrangères ayant une base de données. Pour les programmeurs, un distribué cache est essentiellement une HACHAGE table, où il est une clé et chaque clé contient une valeur et qui valeur est un objet. Vous devez connaître la clé et en fonction de la clé, vous pouvez extraire l'objet souhaité. Ceci est un cache logique qui peut s'étendent sur plusieurs serveurs. Vous pouvez ajouter simultanément pour agrandir la taille du cache de cluster de serveurs, et vous pouvez supprimer zones en même temps pour réduire le cluster cache sans arrêter tout.
Topologies de mise en cache
Les différentes topologies un cache efficace doit fournir sont répliqués, partitionné, un hybride des répliquée et partitionnées et client ou un cache local. L'idée est pour différentes topologies de mise en cache pour différents types d'utilisation, rendre le cache très flexible. Une topologie répliquée réplique le cache autant de fois, dont selon la autant de fois vous avez besoin (voir figure 4 ). Il est destiné le cas où vous disposez d'une utilisation avec beaucoup de lecture du cache, mais pas beaucoup de mises à jour.
La figure 4 le cache répliqué est idéal pour utilisation avec beaucoup de lecture
Un cache de partition est la topologie hautement évolutive pour les données mise à jour-sollicite ou transactionnelles qui doivent être mis en cache. Cela peut être des données de session ASP.NET, ce qui sont très transactionnelles. Comme mentionné précédemment, pour chaque demande Web, la session est lu une fois et mis à jour une seule fois, afin qu'il a un nombre égal de lectures et écritures.
Une topologie partitionnée (voir figure 5 ) est idéal pour les environnements où mises à jour doivent être effectués au moins autant de fois que vous effectuez des lectures, ou plutôt près de qui. Dans cette topologie, le cache est divisé. Lorsque vous ajoutez des serveurs cache plus et plus, le cache est plu partitionnée de telle sorte que nième presque un (N signifie le nombre de nœuds) du cache est stocké sur chaque serveur du cache.
La figure 5 cache partitionné est idéal pour utilisation sollicite en écriture.
Une topologie troisième est un hybride des versions partitionnées et répliquées. Vous pouvez partitionner le cache et, en même temps, chaque partition peut être répliquée. Par conséquent, vous obtenir le meilleur des deux mondes. Vous pourrez partitionner et de croissance, plus vous pouvez répliquer pour la disponibilité pour vous assurer qu'aucune donnée n'est perdue (voir figure 6 ).
La figure 6 caches de réplicas de partition sont idéales pour l'écriture-intensiveusage avec fiabilité.
À l'aide des topologies hybride partitionnées et partitionnées-réplication, vous pouvez devenir votre cache de façon linéaire les valeurs en termes d'évolutivité.
Un client ou un cache local est la quatrième topologie très utile qui se trouve sur le serveur d'applications. Ce type de cache est très proche de l'application et peut même être InProc. Il est généralement un petit sous-ensemble du cache distribué grand réel et repose sur ce que l'application à ce moment donné a été demande. Que les demandes des applications, une copie est conservée dans le cache client. La prochaine fois qu'application veut les mêmes données, il est automatiquement trouver dans le cache du client. Il ne devez atteindre cache distribué, pour que même enregistrer sous un voyage, car le cache distribué est souvent sur le réseau sur un serveur mise en cache distinct ou un cluster de serveurs cache. Un cache client vous donne une augmentation de performances et l'évolutivité supplémentaire.
Les données un cache client doivent rester synchronisées avec le cache distribué. Si ces mêmes données sont modifiées dans le cache distribué, le cache distribué comporte synchroniser ces modifications avec le cache du client. Ceci est un aspect important, vous ne souhaitez pas posséder uniquement un cache local est totalement déconnecté. C'est juste l'équivalent d'un cache InProc, qui est inacceptable car vous avez des problèmes d'intégrité de données. Vous avez plusieurs copies des mêmes données qui obtient désynchronisées.
Différents choix
Il existe plusieurs fonctionnalités de mise en cache distribuées disponibles... Et, comme dans la plupart des situations, solutions libres fournir un ensemble de fonctionnalités plus limité bien que celles commerciales offrent beaucoup plus les options et fonctionnalités.
En dehors de hautes performances, l'évolutivité et haute disponibilité, un cache distribué efficace doit inclure diverses fonctions clées permettant de vous permet de conserver le cache de nouvelles et synchronisé avec la source de données maître, si la base de données ou macroordinateurs une introduction. Le cache devez une option d'expiration afin de pouvoir en déterminer pour effectuer d'expiration automatique, qui peut être une heure absolue ou qu'agit heure glissante. En fait, qui est temps d'inactivité ; si personne n'utilise les données, il est automatiquement expiré.
Un cache doit également être en mesure de gérer les relations entre les différents types de données. La plupart des données sont relationnel. Par exemple, si vous avez un client, vous devez commandes de ce client et il est une relation entre données client et les données de commande. Si vous mettre en cache client et commande de données et que vous supprimez par inadvertance les données de client à partir du cache, il est judicieux que la commande s'être supprimée automatiquement. Dans ce cas, vous ne savez pas si vous avez supprimé les données relatives aux clients à partir du cache ou si vous avez définitivement supprimé. Dans le cas où vous l'avez définitivement supprimée, la commande est également valide maintenant car la commande doit être d'un client valide.
Il existe des autres types similaires de relations qui doivent être gérées dans le cache. Si le cache n'est pas cela, l'application a conserver le suivi et est très délicat. Un objet de cache de Microsoft dans ASP.NET est très utile est appelé un « cache dépendance concept. » Un élément de mise en cache dépend d'un autre. Si que tout autre élément mis en cache est déjà supprimé du cache ou même mise à jour, le premier élément de cache est ainsi supprimé. Cela est un concept de dépendance cache puissant qui doit être disponible dans tous les caches mettre en cache les données relationnelles.
La synchronisation avec la base de données est une autre possibilité d'importante pour le cache. Une base de données est généralement partagé par plusieurs applications. Si une application utilise le cache est la seule mise à jour de la base de données, vous probablement inutile la fonctionnalité de synchronisation de la base de données. Mais mise à très souvent, autres applications, parfois, les applications tierces, sont jour des données dans la base de données parce que la base de données est une banque partagée, courants et les applications n'utilisent pas votre cache. Ils peuvent ne pas être même applications .NET. Ils peuvent être des applications tierces vous ne contrôlez, mais ils sont mis à jour de la base de données. Ainsi, vous devez autoriser pour les situations où la base de données peut être mise à jour en dehors de votre application, mais des ces données qui a été mis à jour de la base de données a été mise en également cache. Par conséquent, le cache doit pouvoir synchroniser. Il a pour pouvoir savoir chaque fois que les données que sont plus identique dans la base de données. Elle doit supprimer les données du cache et peut-être même recharger la dernière copie de la base de données. Synchronisation de la base de données peut être effectuée via les événements déclenchés par le serveur de base de données ou par le cache d'interrogation de la base de données. Les événements sont de cours plus en temps réel et interrogation a un léger retard. Mais interrogation peut être plus efficace si un grand nombre de données change.
Notification d'événement fait partie des fonctionnalités les plus importantes qu'un cache distribué efficace doit avoir. Un cache est généralement partagé entre plusieurs applications et même dans une application parmi plusieurs utilisateurs. Par conséquent, le cache doit avoir un mécanisme de notification d'événement au cas où, par exemple, un objet mis en cache est mis à jour ou supprimé. Si votre application utilise ces mêmes données, vous souhaiterez peut-être être averti afin de vous pouvez recharger soit à partir la base de données ou une nouvelle copie à partir du cache lui-même. Un mécanisme de notification améliore la collaboration entre plusieurs utilisateurs ou plusieurs applications via le cache.
Le monde réel
Gestion informatique faces tous les problèmes de performances associés bases de données et dans le cas des goulots d'étranglement, si vous êtes chance pouvoir enregistrer les développeurs, ils peuvent tenter les résoudre. N'est malheureusement, développement pas toujours en interne. Vous êtes souvent vivant avec et gérer une application tierce.
En tout cas, la meilleure placez pour démarrer l'implémentation de mise en cache distribués pour ouvrir des goulots d'étranglement et turbo-charge vos applications est avec stockage de session ASP.NET, car vous n'avez pas besoin de varient selon les développeurs. Il n'y a aucune programmation n'impliqués. C'est une question simple de remplacement de stockage de session existante avec un cache en mémoire distribué. En outre, l'implémentation d'un cache distribué de stockage de session ASP.NET fournit la possibilité de voir les avantages d'allocation pour les performances et évolutivité et ensuite vous pouvez décider d'effectuer la même opération sur vos données d'application.
Permet d'aborder l'amélioration de l'évolutivité, vous que devez soit exécuter distribué mettre en cache stockage de production ou vous avez simuler la qui charge dans votre environnement de test. Vous pouvez accéder à assurance qualité, qui permet d'effectuer un test de stress dans un environnement de test pour simuler une charge importante avant de mettre un cache distribué en production. La plupart des responsables INFORMATIQUES serait probablement pas à l'aise pour placer un cache distribué dans production, sauf si elles avaient testé il tout d'abord dans leur environnement d'assurance qualité, même si elles n'a pas pu simuler la même quantité de charge. Si c'est un bon point de départ.
Une fois vous haut et en cours d'exécution avec un cache distribué et reaping ses avantages, vous pouvez partager vos nouveaux session ASP.NET performances et l'évolutivité résultats avec votre équipe de développement fournisseur tiers ou en interne. Avec la preuve dur dans main, vous pouvez demander à l'équipe de développement pour analyser les zones mettre où ils peuvent application données en cache dans ce cache distribué ainsi.
Mise en cache des données d'application fournit une optimisation supplémentaire et souvent beaucoup plus renforcent que simplement un cache distribué de stockage de session ASP.NET. Les développeurs pourra identifier tous les éléments de données sont lues plus fréquemment qu'ils sont mis à jour. Données même transactionnelles (telles que clients, commandes, etc.) sont un bon candidat pour la mise en cache, même si elle reste dans le cache pendant quelques minutes avant expiration. Cela est car pendant cette période courte, les données peuvent relire autant de fois et si relire cette dernière est à partir du cache et non de la base de données, il relieves votre base de données d'un lot de la charge en lecture.
Cependant, pour les développeurs aux données d'application du cache, ils devront faire un peu de programmation en effectuant des appels API dans le cache distribué. L'idée est très simple. Chaque fois que leur application tente d'extraire des données à partir de la base de données, il doit rechercher tout d'abord dans le cache. Si le cache a ces données, les données sont tirées du cache. Dans le cas contraire, l'application extrait les données à partir de la base de données, il met en cache et lui donne à l'utilisateur. Ainsi, les données sont trouvent dans le cache de la prochaine fois qu'il est lu. De même, lorsque les données sont modifiées dans la base de données, il doit également être mis à jour dans le cache. Et, si le cache habite sur plusieurs serveurs, il doit donc être synchronisé automatiquement pour vous assurer que si votre application s'exécute dans une batterie de serveurs Web, les mêmes données cache soient accessibles à partir de tous les serveurs de la batterie de serveurs. Pour plus d'informations sur le sujet de développer une application qui utilise un cache distribué pour une meilleure évolutivité, consultez mon article dans le numéro de juillet à venir de MSDN Magazine.
Iqbal KHAN est le président et technologie marketing de Alachisoft, la société qui fournit NCache, le secteur de début cache distribuées .NET pour augmenter les performances et l'évolutivité dans les applications d'entreprise. Iqbal a reçu une commande dans Computer Science Indiana Université, Bloomington, en 1990. Vous pouvez le contacter à iqbal@alachisoft.com.