Cinq boosters de performances ASP.NET

Webinaire enregistré
Par Ron Hussain et Nick Zulfiqar

Découvrez comment améliorer les performances et l'évolutivité d'ASP.NET avec un cache .NET distribué. Regardez ce webinaire pour découvrir les cinq façons d'améliorer les performances d'ASP.NET pour l'évolutivité dans les applications ASP.NET et comment utiliser un cache distribué en mémoire pour les résoudre efficacement.

Co-dirigé par notre architecte de solutions senior et notre directeur régional des ventes, veuillez nous rejoindre pour en savoir plus sur :

  • Mise en cache des données d'application ASP.NET
  • Mise en cache de l'état de la session ASP.NET
  • ASP.NET SignalR Backplane utilisation du cache distribué
  • ASP.NET View State Cache haute performance
  • Mise en cache de sortie ASP.NET

Aujourd'hui, nous allons parler de 5 façons d'améliorer les performances et l'évolutivité de votre application ASP.NET. C'est un sujet très brûlant, je dirais que c'est quelque chose qui est très demandé. Donc, nous sommes heureux de vous apporter ceci. Ron va en parler dans une minute et aussi, si vous avez des questions pendant cette présentation, n'hésitez pas à les saisir dans la vidéo et je pourrai les porter à l'attention de Ron.

Alors, Ron, par quoi commences-tu ? Merci, Nick. Salut tout le monde, je m'appelle Ron et je serai votre présentateur pour le webinaire d'aujourd'hui et comme Nick l'a suggéré, le sujet que nous avons choisi aujourd'hui est cinq boosters de performances ASP.NET. Nous allons donc passer en revue cinq fonctionnalités différentes. Au départ, je parlerai de cinq problèmes différents, ce que vous verriez généralement dans une application Web ASP.NET, ce sont des problèmes quotidiens qui ralentissent réellement vos applications, sa dégradation des performances, puis l'évolutivité est une autre avenue, un autre aspect où nous parlerons de ces goulots d'étranglement, puis je parlerai de différentes solutions à l'aide d'un système de mise en cache distribué. Comment résoudre ces problèmes dans vos applications ASP.NET ? Donc, c'est ce que nous avons prévu aujourd'hui, je couvrirai différentes fonctionnalités, j'aurai des exemples d'applications, je vous montrerai tout en action comment configurer et démarrer avec cela. Donc, ça va être un webinaire assez interactif et pratique et comme Nick l'a mentionné, s'il y a des questions, n'hésitez pas à intervenir et je serai très heureux de répondre à toutes ces questions pour vous. Bon en supposant que tout semble bon, je vais commencer par ça.

ASP.NET est populaire pour les applications Web à fort trafic

Donc, tout d'abord, je vais parler de la plate-forme ASP.NET en général. ASP.NET est une plate-forme très populaire pour les applications Web. Nous voyons beaucoup de déploiements Web et sa popularité augmente. La bonne chose à propos de la plate-forme ASP.NET est que, basée sur le modèle d'utilisation, c'est quelque chose qui évolue assez bien, vous pouvez gérer des milliers d'utilisateurs simultanés et leurs demandes associées sans avoir à changer quoi que ce soit à l'intérieur de l'architecture de l'application. Vous pouvez créer une ferme Web, vous pouvez créer un jardin Web, cela vous offre de nombreuses options d'évolutivité, vous pouvez mettre un équilibreur de charge devant, puis vous pouvez acheminer les demandes entre différents serveurs Web et vous pouvez obtenir une évolutivité linéaire, évolutivité horizontale hors de la batterie de serveurs Web ASP.NET.

Un équilibreur de charge peut avoir un équilibrage de charge persistant ou un équilibrage de charge égal selon votre architecture, en fonction de la nature avec état de vos serveurs Web ou serveurs d'applications, puis vous pouvez évoluer selon vos besoins.

déploiement de la ferme Web

Il s'agit donc d'un déploiement de ferme Web typique pour les applications ASP.NET, vous avez un nombre N de clients passant par l'équilibreur de charge pour configurer des serveurs Web dans une ferme Web, puis vous disposez d'un stockage de session ASP.NET, c'est un type de données que vous pouvez voir dans vos applications Web ASP.NET. Il s'agira alors de serveurs de bases de données, de bases de données relationnelles ou NoSQL databases vous pouvez traiter beaucoup de données dans les deux sens, puis il peut s'agir de n'importe quel autre système de fichiers central du système de données principal avec lequel vos applications interagissent. C'est donc assez populaire, assez évolutif, assez rapide et de nombreux déploiements actifs utilisent cette plate-forme.

Le problème : les goulots d'étranglement de l'évolutivité

Parlons donc du goulot d'étranglement de l'évolutivité au sein d'ASP.NET. Où est exactement le problème ? C'est quelque chose qui adapte très bien le problème d'évolutivité et définissons rapidement ce qu'est l'évolutivité ? L'évolutivité est une capacité au sein de l'architecture de l'application ou de l'environnement dans lequel votre application est déployée. C'est cette capacité qui vous permet d'augmenter le nombre de requêtes par seconde ou de requêtes données, de requêtes simultanées sans compromettre les performances. Si vous avez une certaine latence sous, disons, cinq utilisateurs. Et si vous mainteniez cette latence ? Vous ne dégradez pas les performances et il est normal de ne pas améliorer les performances, mais au moins vous maintenez les performances sous 5000 utilisateurs ou 500,000 XNUMX utilisateurs, cette capacité elle-même s'appelle l'évolutivité, où vous obtenez un débit maximal du système, de plus en plus de charges de demandes sont en cours géré, puis votre latence n'augmente pas à mesure que les charges d'utilisateurs augmentent. Il s'agit donc essentiellement de performances sous une charge extrême ou de performances extrêmes sous une charge extrême. Donc, cette capacité s'appelle l'évolutivité.

Maintenant, généralement les applications ASP.NET, bien que la batterie de serveurs Web soit très évolutive, elles vous poseraient désormais des problèmes d'évolutivité au sein de la batterie de serveurs Web, mais elles peuvent entraîner une lenteur lors des pics de charge, principalement en raison des sources de données principales. Ainsi, si votre application ralentit, elle s'étouffe à cause d'une charge énorme, alors que cette application est candidate à l'évolutivité, elle doit avoir une architecture évolutive en elle-même. Pourquoi l'application sentirait votre monde ou vous verriez des situations comme celle-ci où les applications ralentissent sous une charge de pointe, il pourrait y avoir différents goulots d'étranglement de stockage de données ou certains goulots d'étranglement au sein de l'application. Donc, à partir de maintenant, nous parlerons de cinq goulots d'étranglement différents au sein d'une application ASP.NET qui limitent votre capacité d'évolutivité, ce qui vous limite à évoluer.

Deux goulots d'étranglement du stockage de données

Très bien. Donc, tout d'abord, nous avons deux goulots d'étranglement de stockage de données.

La base de données ne peut pas évoluer

Nous avons une base de données d'applications qui ne peut généralement pas évoluer, vous auriez une base de données relationnelle sous la forme de SQL Server, d'Oracle ou de toute autre source de données relationnelle populaire. C'est très bon pour le stockage, mais ce n'est pas très bon quand il s'agit de gérer une énorme quantité de charge de transaction. Il a tendance à s'étouffer et, dans certains cas, il vous donne en fait des erreurs de temporisation. Donc, ou du moins cela ralentit réellement vos performances, vous ne pouvez pas ajouter plus de serveurs de base de données à la volée, donc ce sera une source unique. C'est aussi un point de défaillance unique dans certains cas si vous n'avez pas de réplication, puis le plus important, le problème urgent ici est que ce n'est pas très rapide, c'est lent dans un scénario normal, puis sous une charge de pointe et cela aggrave en fait la situation où il n'est pas en mesure de s'adapter à l'augmentation de la charge et cela ralentit encore les choses. Donc, c'est notre premier goulot d'étranglement.

Stockage d'état de session ASP.NET

Le deuxième goulot d'étranglement concerne le stockage de l'état de session ASP.NET, maintenant l'état de session est un type de données très important. C'est quelque chose qui contient des informations sur l'utilisateur, par exemple, il peut y avoir une application de commerce électronique qui conserve les informations sur l'utilisateur ou le panier d'achat, il peut s'agir d'un système de réservation, d'un système de billetterie, de votre système financier. Ainsi, il pourrait s'agir de n'importe quel type de système frontal où les utilisateurs se connectent et ils ont leurs données très importantes dans cet objet de session.

Maintenant, ce sont les trois modes offerts par la plate-forme ASP.NET, nous avons InProc où tout est stocké dans le processus de travail. Ainsi, tout se trouve à l'intérieur du processus d'application afin que vos processus de travail ne soient pas sans état, le protocole HTTP lui-même est sans état, mais dans ce cas, vos processus de travail hébergeraient eux-mêmes toutes les données utilisateur. Ensuite, nous avons StateServer cette deuxième option, puis nous avons SQL Server. Parlons donc de ces options de stockage d'état de session conventionnelles et parlons de leurs goulots d'étranglement.

Tout d'abord, InProc c'est rapide car c'est en mémoire, il n'y a pas de désérialisation de sérialisation mais en revanche, tout d'abord, vous ne pouvez pas gérer un scénario de jardin Web. Sur un serveur Web, vous n'auriez qu'un seul processus de travail pour une application donnée, car c'est là que vos données de session existent maintenant si la prochaine demande va à un autre processus de travail, vous n'avez plus ces données de session, il doit s'agir du même processus de travail et c'est pourquoi cela vous limite, techniquement, il n'est pas possible d'exécuter un jardin Web avec la gestion de session InProc, c'est donc un facteur limitant ici.

Deuxièmement, vous avez besoin que le bit de session persistant soit activé sur l'équilibreur de charge. Donc, tout d'abord, vous avez limité vos performances ou votre évolutivité ou vos ressources sur le serveur Web et en n'ayant qu'un seul processus pour une application. Deuxièmement, vos serveurs Web sur lesquels la demande initiale a été servie, les demandes suivantes iraient toujours vers ce même serveur. C'est tout ce que l'équilibrage de charge de session collante fonctionne, il fait le travail, mais le principal problème avec cela est qu'il se peut qu'un serveur Web ait beaucoup d'utilisateurs actifs mais que d'autres serveurs Web soient inactifs parce que ces utilisateurs ont déjà été déconnectés et puisque les utilisateurs vont être de nature collante, ils n'iraient jamais sur ce serveur gratuit, ils iraient toujours sur le même serveur où ils doivent aller avec les données existantes. Donc, c'est un autre problème que vous devez avoir un équilibrage de charge de session persistant avec InProc, et surtout, si votre processus de travail est recyclé et que nous avons vu, sur la base de notre expérience, que les processus de travail ASP.NET sont recyclés beaucoup, vous perdriez tout le droit des données, s'il s'agit d'une tâche liée à la maintenance, si le serveur doit tomber en panne, vous devez arrêter un serveur Web, mettre un autre serveur Web en place, vous perdez toutes les données à la suite de cela. Donc, cela résume tous les problèmes, tous les goulots d'étranglement que vous verriez avec la gestion de session InProc avec un ASP.NET. Donc, ce n'est clairement pas une option et ce n'est pas non plus très évolutif, vous avez un serveur sur lequel vous atteignez la capacité de ce serveur et avec sticky est un équilibrage de charge, cela n'aide pas vraiment.

La deuxième option est StateServer, c'est légèrement mieux qu'InProc car il extrait les données de votre processus d'application à l'intérieur d'un service d'état, il peut s'agir d'un boîtier distant ou de l'un de vos serveurs Web, cela dépend entièrement de vous mais le problème avec cela est que ce n'est pas évolutif, il s'agit d'une source unique, vous pouvez augmenter la taille de ce serveur, mais la mise à l'échelle n'est pas une option. Il s'agira toujours d'un serveur unique, d'un service hébergeant toutes vos données de session et qui gérera également la charge de toutes les demandes. Si votre charge de demandes augmente, il n'y a pas d'options pour ajouter plus de ressources. Donc, cela ne va pas évoluer en comparaison, éventuellement votre service d'état peut s'étouffer, par exemple, si vous avez des centaines et des milliers d'utilisateurs et que leur demande associée en fait des millions de demandes par seconde ou par jour demandeur ou dans des millions, c'est une charge assez lourde . Ainsi, sur la base de cela, StateServer ne serait pas évolutif et il ne serait pas en mesure de faire face à une charge croissante, et il s'agirait alors également d'un seul point de défaillance. Si StateServer lui-même tombe en panne, vous perdez toutes vos données de session et les données de session sont un type de données très important que vous ne voudriez pas perdre vos sessions pendant que votre utilisateur est sur le point d'acheter quelque chose ou qu'il est sur le point de prendre une décision et cela aura un impact l'entreprise en retour.

La troisième option est SQL Server. SQL Server est à nouveau une gestion de session hors processus, mais encore une fois, c'est lent, ce n'est pas évolutif, vous ne pouvez pas ajouter plus de serveurs SQL et ce n'est pas destiné à gérer les données transactionnelles seules, vous finissez donc par avoir le même problème que nous avons discuté dans le cadre de notre base de données d'application, ce problème reste le même pour la mise en cache des données ainsi que pour la mise en cache des sessions. Ainsi, l'état de session n'est pas quelque chose qui va être optimisé avec les options par défaut que la plate-forme ASP.NET présente et c'est principalement à cause des sources de données qu'elle offre InProc, StateServer et SQL Server.

J'espère que cela a construit quelques détails de base autour des goulots d'étranglement et bien sûr nous parlerons de la solution, nous parlerons de la mise en cache distribuée et de ses fonctionnalités en comparaison et nous parlerons de la façon de prendre soin de ces problèmes un par un , donc je veux d'abord énumérer tous les problèmes, puis nous parlerons des solutions une par une. Ce diagramme illustre la même chose.

deux-goulots-d'étranglement-de-stockage-de-données

Nous avons une base de données de goulot d'étranglement de stockage de données, puis nous avons un stockage de session ASP.NET ou InProc ou des bases de données en tant que gestionnaire de session et cela crée également clairement un goulot d'étranglement, où nous avons des sources uniques dans la plupart des cas, elles ne sont pas évolutives, elles ne le sont pas très fiable et puis y'a de la lenteur en général.

ASP.NET View State Goulot

Maintenant, le troisième goulot d'étranglement important est ASP.NET view state. Pour les fermes Web ASP.NET, il existe un état d'affichage, maintenant ceux d'entre vous qui veulent savoir ce qu'est l'état d'affichage ? Je suis presque sûr que tout le monde le sait, mais l'état d'affichage est une gestion d'état côté client, c'est un paquet, c'est un état de vos widgets de contrôle que vous avez sur vos fermes Web, il est construit côté serveur et fait partie de votre Le paquet de réponse retourne au navigateur où il est stocké, il n'est jamais vraiment utilisé du côté du navigateur et il est ramené au serveur lorsque vous publiez sur cette page dans le cadre du paquet de requête dispersé. Ainsi, il est regroupé avec les paquets de requête et de réponse, il retourne au navigateur, il n'y est jamais vraiment utilisé et un problème urgent avec l'état d'affichage est qu'il est généralement très lourd. Il a une taille de centaines de kilo-octets et pensez au scénario, où vous avez une énorme quantité de charge de transaction, nous avons des millions de transactions, puis chaque transaction a un paquet de paquets d'état d'affichage ou un paquet de réponse de demande pour l'application Web ASP.NET a l'état d'affichage en fait partie et si vous avez des centaines de kilo-octets d'état d'affichage par demande et que vous avez des millions de transactions, cela va consommer beaucoup de bande passante et cela ralentirait en général les réponses de votre page parce que vous avez affaire à beaucoup de données dans les deux sens et ces données sont également volumineuses.

Donc, c'est un autre goulot d'étranglement qui consomme votre bande passante, votre cause augmente considérablement, puis cela ralentit les temps de réponse de votre page car l'état d'affichage est généralement lourd, vous avez affaire à une charge utile plus lourde pour les demandes en réponse. Il s'agit donc d'un autre type de goulot d'étranglement qui fait partie des fermes Web ASP.NET. Si vous avez une application de fermes Web ASP.NET, vous ne pouvez pas échapper à ce problème. Par défaut, vous auriez à gérer beaucoup d'états d'affichage et ce diagramme le couvre où l'état d'affichage revient au navigateur, c'est une gestion d'état côté client qui est construite côté serveur et retourne au navigateur et apportez-le retour sur le serveur sur vos dos de poste. Désormais, les paquets de requêtes et de réponses sont lourds, ils consomment beaucoup de bande passante, une charge utile importante ralentit également les choses.

viewstate-goulot d'étranglement

Goulot d'étranglement d'exécution de page supplémentaire

Maintenant, quatrième goulot d'étranglement et c'est l'avant-dernier, nous avons un autre goulot d'étranglement après c'est le goulot d'étranglement d'exécution de page supplémentaire. Maintenant, cela est vrai pour les fermes Web ASP.NET ainsi que pour les applications Web ASP.NET MVC. Il existe des scénarios dans lesquels la sortie de la page entière est identique ou des parties d'une page dynamique sont identiques, vous avez donc très fréquemment affaire à du contenu statique dans l'application. Ainsi, la sortie de la page ne change pas très fréquemment, mais vous exécutez toujours ces requêtes. Il peut y avoir une demande et cela implique des bases de données back-end qui sont rendues, puis vous récupérez des données à partir des sources de données back-end, vous lisez ces données, les rendez significatives, appliquez une couche de logique métier quotidienne, une couche d'accès aux données tout le bonnes choses et après cela, vous rendez une réponse et la réponse est renvoyée à l'utilisateur final dans le navigateur. Maintenant, quel que soit le même cycle qui doit recommencer et que le contenu ne change pas, vous devrez répéter le même cycle encore et encore et encore. Cette page s'exécute indépendamment du fait qu'elle change ou non, par défaut, vous avez affaire à beaucoup de contenu statique et bien que le contenu ne change pas, vous exécutez toujours la même requête. Maintenant, cela augmente le coût de votre infrastructure, le CPU supplémentaire, la mémoire supplémentaire, les ressources de base de données supplémentaires, il peut atteindre la capacité sur le serveur Web, il peut également atteindre la capacité sur le site de la base de données en général, c'est quelque chose qui gaspillerait beaucoup de CPU et de ressources coûteuses pour exécuter quelque chose qui a déjà été exécuté. Donc, c'est un autre goulot d'étranglement et nous parlerons d'une solution à l'aide de la mise en cache de sortie de page, comment s'en occuper également. Donc, cela couvre notre quatrième goulot d'étranglement et le cinquième et d'ailleurs ce diagramme implique l'exécution de pages sur une sortie statique et fait plus de bases de données que nous traitons beaucoup de demandes.

goulot d'étranglement d'exécution de pages supplémentaires

ASP.NET SignalR Backplane Goulot

Et le cinquième goulot d'étranglement est SignalR backplane. Maintenant, c'est un cas d'utilisation très spécifique que vous pouvez ou non avoir SignalR mais pour ceux d'entre vous qui connaissent SignalR et si vous avez configuré un fond de panier, un fond de panier est un bus de messages commun et votre serveur Web envoie tous leurs messages au lieu d'envoyer la fonctionnalité push sur les navigateurs clients. Il pourrait y avoir un scénario où peu de demandes de clients sont traitées avec d'autres serveurs Web. Ainsi, nous sommes simplement diffusés sur le fond de panier et le fond de panier diffuse à son tour des messages, des messages SignalR sur tous les serveurs Web et ils sont à leur tour diffusés sur tous leurs clients connectés. Ainsi, avec WebSockets ASP.NET SignalR backplane est une configuration assez courante, si vous avez une ferme Web.

Maintenant SignalR Backplane NCache ou tout autre produit de mise en cache distribué peut être branché. Il peut également s'agir d'une base de données ou d'un bus de messages, mais l'idée ici est que le fond de panier ne devrait pas avoir de problèmes de performances ou de débit. Il devrait très bien fonctionner, il devrait vous donner une faible latence, il vous donne un débit élevé et en même temps, il devrait être très fiable s'il tombe en panne et que vous perdez tous les messages SignalR qui auraient également un impact sur l'entreprise.

Les bases de données sont lentes, elles ne sont pas très évolutives, leurs performances sont lentes, Redis est une option, ce n'est pas .NET natif, vous avez donc besoin de quelque chose de très évolutif, de très rapide et de très fiable. C'est donc un autre problème dans une application ASP.NET si vous utilisez SignalR backplane à la suite de cela. Donc, cela complète nos cinq goulots d'étranglement, je sais que c'est beaucoup d'informations mais principalement sa base de données étant lente, n'étant pas très évolutive, l'état de session ASP.NET n'a pas d'options très évolutives ou rapides ou fiables par défaut. View State pour la ferme Web ASP.NET est également un goulot d'étranglement, sa source de conflit, la surutilisation de la bande passante, les pages statiques de l'application vont être exécutées, que le contenu de votre application change ou non. Il va être exécuté et ensuite nous avons SignalR Backplane ce qui est généralement lent et ce n'est pas très fiable, ce n'est pas très évolutif et vous avez besoin de quelque chose qui est très évolutif et très fiable en comparaison.

Donc, cela complète nos cinq goulots d'étranglement, sur les prochaines diapositives, je parlerai de la solution, puis nous passerons en revue tous ces goulots d'étranglement un par un et je présenterai différentes solutions. N'hésitez pas à me faire part de vos questions et je serai très heureux d'y répondre pour vous dès maintenant. J'ai quelques exemples d'applications alignées ici, donc je les utiliserai bien. Donc, je pense qu'à ce stade, il n'y a pas de questions. Donc, je vais rapidement commencer avec la solution car nous avons beaucoup à couvrir dans notre prochain segment.

La solution : cache distribué en mémoire

Nous avons la mise en cache distribuée en mémoire comme solution et j'utiliserai NCache à titre d'exemple de produit. NCache est le principal produit de mise en cache distribuée, un cache distribué basé sur .NET, il est écrit pour .NET et est principalement destiné aux applications .NET et c'est l'un de nos principaux produits. je vais utiliser NCache comme exemple de produit et nous parlerons de cinq fonctionnalités différentes dans NCache cela s'occupera de cela et vous verrez un booster de performances dans votre application ASP.NET. Cela améliorerait considérablement les performances ainsi que l'évolutivité et ce ne sont que des fonctionnalités spécifiques à ASP.NET, il existe d'autres fonctionnalités côté serveur que vous pouvez régler, il y a un webinaire séparé sur comment améliorer NCache performant, qui amènera les choses à un tout autre niveau, qui améliorera encore les performances, mais dans ce webinaire, je parlerai de cinq goulots d'étranglement différents, puis de cinq solutions différentes à ces goulots d'étranglement.

Qu'est-ce qu'un cache distribué en mémoire ?

Alors, qu'est-ce qu'un cache distribué en mémoire et en quoi est-il plus rapide et plus évolutif et, dans certains cas, plus fiable en comparaison ? Ainsi, le cache distribué est un cluster de plusieurs serveurs de cache peu coûteux qui sont regroupés dans une capacité logique pour leur mémoire, leur processeur ainsi que leurs ressources réseau. Donc, si vous avez une équipe de serveurs et que ces équipes de serveurs sont réunies dans un cluster, c'est une capacité logique pour les applications, mais c'est un ensemble physique de serveurs ou de machines virtuelles, donc derrière nous, il y a plusieurs ressources et vous avez la possibilité de ajouter plus de serveurs à la volée. Ainsi, des serveurs de cache peu coûteux, se regroupent, se regroupent et mutualisent leurs ressources et c'est ce qui constitue la base d'un cache distribué.

Ensuite, nous avons synchronisé les mises à jour du cache entre les serveurs de cache, c'est très cohérent en termes de données car il y a plusieurs serveurs, plusieurs applications clientes s'y connectent, donc toute mise à jour effectuée sur un serveur de cache doit être visible sur d'autres serveurs de cache Web et aussi aux clients qui y sont connectés et j'ai utilisé le terme visible, ce qui signifie qu'il doit être cohérent. Je n'ai pas utilisé la réplication comme terme ici, la réplication est un autre concept. Ainsi, toutes les mises à jour sont appliquées de manière synchronisée ou cohérente sur tous les serveurs de mise en cache, vous avez donc la même vue des données pour toutes vos applications clientes.

Ensuite, il doit évoluer pour la transaction ainsi que pour la capacité de mémoire et également pour d'autres ressources. Si vous ajoutez plus de serveurs, cela devrait simplement augmenter la capacité, si vous avez deux serveurs et que vous apportez le troisième serveur, auparavant vous traitiez disons 10,000 15,000 requêtes avec un troisième serveur, cela devrait le porter à 20,000 XNUMX avec deux autres serveurs doublant la capacité, il devrait traiter XNUMX XNUMX requêtes par seconde et c'est notre expérience. Cela augmente en fait la capacité et la capacité globale de traitement des demandes augmente à mesure que vous ajoutez un nombre de serveurs et je vais vous montrer quelques chiffres de référence pour soutenir cela. Il s'agit de l'architecture de déploiement d'un cache distribué typique.

cache distribué en mémoire

Vous disposez d'une équipe de serveurs de cache, tous les environnements Windows sont supportés 2008, 2012 et toutes vos applications s'y connectent dans un modèle client-serveur et ils utilisent cette source rapide, évolutive et fiable en plus de notre base de données relationnelle. Un jour, ils donneront que cela existe dans la base de données relationnelle, vous pouvez apporter tout ou partie de vos données dans le cache. L'état de la session devient votre magasin principal, l'état de la vue, le cache de sortie, SignalR backplane cela devient votre principal fournisseur pour cela.

NCache Benchmarks de Performance

Permettez-moi de vous montrer quelques chiffres de référence pour prouver qu'il est très évolutif. Sur notre site Web, ces chiffres sont publiés. Donc, ce sont les détails du test, puis si vous regardez les performances, cela augmente pour les lectures pas si linéaires pour les écritures, mais c'est la topologie que nous utiliserons dans le webinaire d'aujourd'hui, les lectures et les écritures augmentent de manière linéaire et cela a les lectures et les écritures augmentent de manière linéaire ainsi que les sauvegardes. Donc, cela vient également avec la prise en charge de la sauvegarde, c'est pourquoi les performances ou la capacité d'écriture sont légèrement inférieures à la partition qui n'a pas de sauvegarde, ce qui entraîne également une surcharge de sauvegarde. Il s'agit donc de notre topologie la plus populaire pour les lectures et les écritures et, à mesure que vous ajoutez des serveurs, la capacité augmente également.

Démonstration pratique

Laissez-moi vous emmener dans notre environnement de démonstration, configurer un cache distribué, puis commencer avec ces fonctionnalités une par une et les gars, s'il vous plaît, s'il y a des questions ?

Je vais utiliser, j'ai déjà téléchargé installé NCache, la portée de ce webinaire n'est pas là NCache configurations ou configuration. Donc, je vais passer quelques détails ici, mais juste pour vous faire savoir, j'ai téléchargés NCache à partir de notre site Web, un essai entièrement fonctionnel, puis je l'ai installé sur deux de mes boîtes de serveur de cache et une machine de mon côté va être utilisée comme client. Vous pouvez installer NCache sur le client également ou vous pouvez utiliser les packages NuGet selon vos besoins.

Créer un cache

Je vais juste créer un cache, nommons-le aspnetcache parce que c'est ce sur quoi nous nous concentrons aujourd'hui.

engendrent

Je choisirai le cache de réplique de partition et tous ces paramètres sont discutés en détail dans notre article régulier. NCache architecture webinaires.

réplique partitionnée

Option de réplication asynchrone et ici, je spécifie les serveurs qui vont initialement faire partie de mon cluster de cache.

spécifier-serveurs

Gardez tout pareil pour le port TCP/IP. NCache est une communication basée sur TCP/IP, la communication serveur-serveur et client-serveur est gérée via TCP/IP, puis la taille du cache sur chaque serveur, je vais tout garder par défaut, garder les évictions par défaut et choisir terminer et c'est tout.

finition

C'est aussi simple que cela de configurer le cache. Dans le volet de droite, nous avons tous les paramètres liés à ce cache. En passant, vous pouvez également configurer des lignes de commande ainsi que des outils PowerShell, puis vous pouvez tout gérer à partir de la ligne de commande ou de PowerShell. J'ajouterai ma boîte à partir de laquelle je prévois d'exécuter des applications. Donc, que nous ayons mis à jour les configurations côté client et que je puisse me connecter à ce cache, je vais démarrer et tester ce cluster de cache et c'est tout. La configuration de mon site serveur est terminée à ce stade. Les gars, s'il vous plaît faites le moi savoir, y a-t-il des questions? Bon, ça a commencé. Je clique avec le bouton droit de la souris et je sélectionne les statistiques.

Ron, j'ai une question ici très rapide NCache flux pour prendre en charge les applications Java pour les sessions JSP une mise en cache de session ou s'agit-il uniquement d'applications ASP.NET ? d'accord c'est une très bonne question principalement ce webinaire était axé sur ASP.NET donc, je me suis concentré davantage sur le site ASP.NET mais oui pour répondre à cette question NCache prend entièrement en charge les applications Java, nous avons un client Java, puis pour les applications Java, si vous avez des sessions Web Java ou des sessions JSP, vous pouvez très bien utiliser NCache. Ainsi, notre fournisseur reste exactement le même, c'est une option sans changement de code et nous avons un exemple d'application qui est installé avec NCache aussi bien. Il vous suffit donc d'installer NCache sur l'environnement Windows ou vous pouvez également utiliser des conteneurs, puis l'application peut être sur Windows ou sur l'environnement Linux UNIX également, elle prend entièrement en charge les applications Java.

Surveiller les statistiques du cache

J'ai ouvert les statistiques juste pour voir certains aspects de la surveillance, j'ai également ouvert un outil de surveillance qui est installé avec NCache. Je vais rapidement exécuter une application d'outil de test de stress pour vérifier que mon cache est bien configuré et ensuite je vais commencer avec les exemples d'applications, un client est connecté, vous devriez voir une activité ici, voilà et nous avons des compteurs montrant la valeur des requêtes par seconde des deux serveurs et nous avons déjà des graphiques remplis.

connecté au client
services

Donc, cela garantit que tout est correctement configuré, puis nous pouvons commencer avec nos exemples d'applications.

Ainsi, le premier exemple d'application est qu'il s'agit de cinq optimisations différentes. Je parlerai de ces applications une par une, puis je vous montrerai des exemples d'applications. Tout d'abord, vous pouvez utiliser NCache pour la mise en cache des données, nous avons notre API détaillée pour les goulots d'étranglement de la base de données. Vous pouvez utiliser un cache distribué en mémoire rapide, c'est plus rapide parce qu'il est en mémoire, c'est plus évolutif parce que vous pouvez ajouter plus de serveurs, puis vous augmentez la capacité au moment de l'exécution en ajoutant plus de serveurs. Vous pouvez l'utiliser pour l'état de la session, il s'agit d'une option sans changement de code, les sessions sont très fiables dans NCache comme ceux-ci sont répliqués, les sessions sont également gérées dans un référentiel rapide et évolutif en comparaison et vous n'avez pas besoin d'un équilibrage de charge de session persistant. Je parlerai de plus d'avantages une fois que nous aurons montré ces exemples d'applications, mais laissez-vous savoir que ce sont quelques-uns des avantages que vous tirez de NCache dès que vous branchez NCache pour ces.

Pour les fermes Web, vous pouvez utiliser l'état d'affichage, vous pouvez stocker l'état d'affichage côté serveur, vous n'avez pas besoin d'envoyer l'état d'affichage et cela réduit également la taille de la charge utile de votre état d'affichage, vous pouvez alors utiliser NCache en SignalR Backplane, c'est notre quatrième option et vous pouvez également utiliser NCache pour la mise en cache de sortie ainsi que pour le contenu statique et cela est également vrai pour ASP.NET core. Vous pouvez l'utiliser pour l'état de session dans ASP.NET core et vous pouvez également l'utiliser pour la mise en cache des réponses dans ASP.NET core applications.

Exemple de mise en cache de session ASP.NET

Commençons donc avec le stockage d'état de session ASP.NET. C'est le plus simple de tous, vous pouvez le configurer en cinq minutes et vous pouvez le tester rapidement. En fait, je vais vous montrer comment le configurer et ensuite commencer avec.

Donc, c'est notre premier exemple d'application, ce que j'ai fait, c'est qu'il est installé avec NCache ainsi mais je l'ai légèrement modifié. Pour la mise en cache de session, tout ce que vous avez à faire est d'ajouter une balise d'assemblage, ces deux assemblages sont redondants, ce sont pour un autre cas d'utilisation pour la mise en cache d'objets mais vous n'avez besoin que Alachisoft.NCacheAssemblage .SessionStoreProvider. La version 4.9 est la dernière version et vous avez également besoin d'une culture et d'un jeton public pour cet assembly. Il s'agit donc d'une référence typique à cet assemblage d'état de session, après cela, vous devez remplacer votre balise d'état de session existante par NCache. Si vous avez déjà une balise d'état de session, vous devez la remplacer, si vous n'en avez pas, c'était InProc, dans ce cas, vous pouvez la remplacer, vous pouvez l'ajouter en tant que nouvelle. Ici, le mode est personnalisé et le fournisseur est NCacheSessionsProvider, la valeur du délai d'attente est si un objet de session dans NCache reste inactif pendant plus de vingt minutes, il expirerait automatiquement supprimer du cache.

Ensuite, il y a certains paramètres tels que les exceptions à activer. Donc, cela peut être utilisé comme exemple de balise, vous pouvez le copier à partir d'ici et le coller dans l'application, puis le plus important est le nom du cache, il vous suffit de spécifier le nom du cache aspnetcache. Je pense que j'utilise le même nom aspnetcache et cela résoudrait les configurations pour cet exemple car vous ne spécifiez que le nom. Ainsi, il se contentera de lire les configurations de ce cache à partir du client.ncconf aspnetcache ou ce fichier peut également faire partie du projet. Si vous avez un package NuGet, vous pouvez également intégrer ce fichier à votre projet et c'est tout. Vous avez juste besoin de sauvegarder ceci et laissez-moi simplement en faire une page principale parce que nous utilisions deux pages ici et je vais l'exécuter et cela lancerait les sessions de jeu invité pour le fournisseur et il se connecterait à NCache pour les données de session.

Donc, je m'attends à créer un objet de session dans le cache, puis je relirai certaines données de la session et je vous montrerai également l'objet de session en cours de création. Il s'agit d'une application de jeu de devinettes, elle vous permet de deviner un nombre entre un et cent, puis elle imprime en fait l'invité précédent à partir de l'objet de session. Donc, il a deviné que le nombre est compris entre 0 et 23. Donc, je vais juste deviner 12, le nombre est entre 12 et 23. Donc, il a également lu le dernier nombre. Supposons que le nombre se situe entre 13 et 23. Alors, devinons une fois de plus. Je ne suis pas en mesure de deviner, j'espère que j'y arriverai, mais juste pour vous faire savoir qu'un objet de session doit avoir été créé côté serveur.

Permettez-moi de vous montrer cela à l'aide d'un outil et voilà, NCache test est un mot-clé que je lui joins avec cet exemple d'application. Si je le change, c'est pour faire la distinction entre les sessions de différentes applications, il pourrait y avoir un scénario où vous avez deux applications et vous utiliserez le même cache pour les deux applications. Ainsi, dans ce cas, vous pouvez ajouter un ID d'application à la variable de session, mais généralement, une application doit mettre en cache sa session dans un cache dédié. Donc, cela n'a pas vraiment d'importance, si vous le spécifiez même comme une chaîne vide mais que cela a été créé et qu'il s'agit de votre ID de session ASP.NET, la session ici est répliquée ici. Ainsi, si ce serveur tombe en panne, les données de session sont automatiquement mises à disposition.

Quelques autres avantages de NCache l'état de la session par rapport aux hits InProc hors processus, de sorte que votre processus Web soit complètement sans état. Donc, c'est ce que préfère le protocole HTTP, c'est plus évolutif, vous pouvez ajouter plus de ressources, c'est plus rapide car c'est en mémoire, c'est comparable à InProc et c'est très fiable. Si un serveur tombe en panne, vous n'avez plus à vous soucier de quoi que ce soit et, plus important encore, vous n'avez plus besoin d'utiliser des sessions persistantes ou d'équilibrer. Vous pouvez avoir un équilibrage de charge égal et la demande peut rebondir d'un serveur Web à un autre. Vous n'avez à vous soucier de rien car les serveurs Web ne stockent rien, les objets de session réels sont stockés dans NCache et ceci est un magasin de processus externe pour vos applications et comparaisons de StateServer. Ce n'est pas un point de défaillance unique, si un serveur tombe en panne ou si vous le réduisez pour maintenance, vous n'avez pas à vous soucier de quoi que ce soit, cela fonctionnerait simplement sans problème.

Deuxièmement, il est très évolutif, vous pouvez ajouter plus de serveurs à la volée. C'est très fiable, c'est très évolutif, c'est rapide en comparaison. Pour la base de données, ce n'est pas lent, c'est rapide et c'est très évolutif et dans certains cas, c'est encore mieux en termes de fiabilité là où vous n'avez pas de réplication pour les bases de données. Donc, cela couvre tout et une autre caractéristique importante dans NCache est notre support de session multi-site, c'est une autre fonctionnalité sessions multi-régions, où vous allez avoir des sessions de deux régions différentes stockées dans NCache et vous pouvez avoir des sessions entièrement synchronisées.

ncache-session-aspnet-multi-région

Si une demande de session rebondit d'un serveur à un autre ou d'une région à une autre, elle était automatiquement alimentée en session à travers la région et l'amenait ici et vice versa. Ainsi, si vous avez besoin de mettre le côté vers le bas, vous pouvez acheminer tout votre trafic vers l'autre côté en laissant le cache fonctionner pendant un certain temps. Donc, c'est une autre caractéristique. L'une de nos principales compagnies aériennes, cliente des compagnies aériennes, utilise actuellement cette fonctionnalité pour son affinité géographique. Donc, cela couvre notre état de session ASP.NET. Il s'agit d'un fournisseur sans changement de code, veuillez me faire savoir s'il y a des questions à ce sujet, j'ai déjà répondu à une question sur les sessions JSP, vous pouvez utiliser NCache également pour les sessions Web basées sur Java. En supposant qu'il n'y a pas de questions.

ASP.NET View State Exemple de mise en cache

Ensuite, je parlerai de l'état d'affichage, maintenant NCache a également un fournisseur d'état d'affichage, la façon dont cela fonctionne est que, fondamentalement, nous gardons l'état d'affichage côté serveur. C'est encore un fournisseur, tout ce que vous avez à faire est de configurer un groupe de section à droite, ce sont les paramètres de contenu, c'est ContentOptimization.Configurations.ContentSettings. Le nom du groupe de section est nContentOptimization et cela a quelques paramètres où vous prenez un nom de cache par exemple, j'utilise mycache en ce moment, la façon dont nous avons conçu notre ASP.NET view state fournisseur est que nous gardons l'état d'affichage sur le serveur à droite. Donc, tout d'abord, je vais exécuter sans mise en cache bien que le fournisseur précédent soit branché, mais j'ai configuré la mise en cache de l'état d'affichage sur faux et je vais l'exécuter et je vous montrerai l'état d'affichage réel qui revient au navigateur.

Donc, je vais vous montrer l'option par défaut, puis je vais vous montrer le NCache état d'affichage et nous comparerons la différence. Donc, il y a quelques pages de ferme Web et je vais vous montrer la source de la page de vue.

ferme Web

C'est l'état d'affichage par défaut, la partie valeur, laissez-moi l'amener ici et laissez-moi juste créer un document temporaire ici. Maintenant, c'est l'état d'affichage par défaut qui fait partie de mon paquet de réponse et quand je reviendrai sur cette page, cela fera également partie de mon paquet de requête. Il s'agit d'une demande individuelle et notez le nombre de caractères ajoutés aux en-têtes de demande et de réponse et il en va de même pour toutes les demandes que je ferai. Permettez-moi de vous montrer quelques requêtes supplémentaires et laissez-moi également vous montrer la source de la page de vue de celle-ci.

Donc, c'est presque similaire à ce que vous pouviez voir à l'écran. Maintenant avec NCache ce que nous avons fait, c'est que nous interceptons votre état de vue avec l'aide de notre fournisseur d'état de vue. Nous gardons l'état de la vue côté serveur, donc, cette partie valeur, nous créons une clé et une valeur pour une page donnée de la ferme Web, nous l'avons stockée côté serveur, maintenant elle est stockée côté serveur, nous envoyons donc un petit jeton retour au navigateur. Il s'agit donc d'un jeton de taille statique, qui est renvoyé au navigateur. Ça ne change jamais vraiment, ça va toujours être envoyé là-bas, puis ramené pour être réutilisé et quand vous postez, vous appelez en fait NCache et récupérez l'état d'affichage supplémentaire à partir de NCache puis utilisez-le sur votre ferme Web pour afficher l'état réel et c'est ce que nous faisons dans les coulisses.

Les avantages dont vous bénéficiez avec votre paquet d'état d'affichage deviennent plus petits, car il s'agit d'un jeton. Cela a donc un impact global sur la réduction de la taille de la charge utile pour les requêtes et les réponses. Donc, cela améliore vos performances et deuxièmement, si vous avez des centaines de kilo-octets d'état d'affichage qui vont et viennent pour des milliers de requêtes, cela consommera votre bande passante. S, cela n'arrivera pas avec NCache, NCache l'état d'affichage est un jeton statique et je vais vous montrer le jeton très rapidement.

Ron, laisse-moi juste intervenir pour la question, très vite fait NCache avez-vous des fonctionnalités de sécurité des factures telles que le cryptage des sessions et la mise en cache de l'état de la vue ? oui, ce sont des fonctionnalités que vous pouvez configurer explicitement, elles sont générales NCache fonctionnalités. Donc, tout l'état d'affichage est déjà une chaîne cryptée, mais si vous voulez crypter davantage et laissez-moi voir si c'est le cas, vous pouvez activer le cryptage sur le cache lui-même, vous devez l'arrêter, configurer le cryptage, nous avons des fournisseurs DES , nous avons des fournisseurs AES, nous avons un client FIPS, conforme FIPS, des fournisseurs DES AES. Donc, oui, vous pouvez simplement configurer cela et toute la charge utile des serveurs clients serait cryptée et décryptée ici et récupérée respectivement. Donc, c'est quelque chose que vous pouvez mettre en place à la demande et vous pouvez faire avancer les choses et par cette question, je tiens également à souligner que depuis NCache ne stocke pas c'est l'état d'affichage après NCache a branché a été branché en tant que fournisseur et notez la différence, ce sont ces nombreux caractères par rapport à ces nombreux caractères. Donc, c'est votre défaut, c'est avec NCache et voyez vous-même la différence, cela ralentit, réduit la taille de la charge utile sur toutes les augmentations de performances, les coûts de virtualisation de bande diminuent. Ainsi, vous voyez beaucoup d'améliorations dans l'architecture et, plus important encore, votre état d'affichage réel n'est plus vraiment renvoyé au navigateur. Il va être stocké côté serveur, c'est sécurisé en général.

Donc, sur la base de cette question, merci d'avoir posé cette question NCache L'état d'affichage est par défaut plus sécurisé que l'option par défaut car nous le stockons sur le serveur là où il est réellement nécessaire. Donc, j'espère que cela aide. Je vais fermer ceci, toutes les questions concernant l'état de la vue, sinon je passerai à notre prochain segment.

Exemple de mise en cache des données d'application

Faisons-moi d'abord vous montrer l'objet mis en cache en raison de la contrainte de temps. Je pense que je devrais couvrir cela en premier. Pour les goulots d'étranglement de la base de données, tout ce qui stocke dans la base de données qui ralentit les choses, vous pouvez également utiliser un cache distribué comme NCache. C'est NCache API ici.

Connexion au cache
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();
Récupération des données

Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");
Écrire des données
cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

C'est ainsi que vous connectez le cache, c'est ainsi que vous disposez du handle vers la fin des opérations, tout est stocké dans une paire clé-valeur, c'est une valeur de clé de chaîne .NET objet autorisé sur lequel vous pouvez mapper vos tables de données sur vos objets de domaine et puis vous stockez vos objets de domaine, puis vous traitez les objets de domaine en stockant des objets individuels ou des collections ayant des relations, SQL recherche la liste, mais il s'agit d'une opération de base de création, lecture, mise à jour, suppression.

Je vais rapidement exécuter un exemple d'application et montrer comment vous utiliseriez réellement NCache pour la mise en cache d'objets. Vous avez besoin de ces deux références sommaires Alachisoft.NCache.Web et Alachisoft.NCache.Durée. Une fois que vous avez fait cela, permettez-moi d'en faire une page de démarrage et de vous montrer le code derrière cela. Il s'agit d'une ferme Web ASP.NET, mais si vous avez des contrôleurs MVC, vous pouvez également utiliser la même approche, puis j'ai cet espace de noms ici et dans cette application, j'initialise mycache, vous devez spécifier le nom du cache et vous pouvez également spécifier des serveurs ici, en utilisant InitParams right cache InitParams ici ou vous pouvez simplement spécifier le nom et résoudre le nom via client.ncconf que je vous ai montré plus tôt. Il y a un addObject, qui ajoute un client, le nom est David Jones, homme, numéro de contact, c'est l'adresse et ensuite j'appelle cache.Add.

De même, j'insère ceci en changeant la page ou je pourrais en fait également changer le nom juste pour m'assurer qu'il est mis à jour, puis j'appelle cache.Insert puis je récupère l'objet, récupère le compte de l'objet. Je supprime cet objet, je lance juste un test de charge. 100 articles vont être mis à jour encore et encore. Alors, exécutons l'exemple d'application, c'est à quel point il est intuitif de commencer avec et cela lancerait simplement l'application et je serai en mesure d'effectuer toutes ces opérations pour vous et avant de le faire, j'aimerais aussi pour vous montrer les états d'affichage qui ont été mis en cache dans NCache.

Vous pouvez voir les clés de l'état d'affichage pour trois pages vs et il s'agit de la clé réelle de l'objet, puis l'état d'affichage réel se trouve sur la partie valeur. J'ai oublié de mentionner cela maintenant en supposant que nous m'avons laissé effacer le contenu. Donc, comme nous ne traitons plus que des données de mise en cache d'objets, laissez-moi le faire depuis le gestionnaire, c'est pratique. Donc, je vais ajouter un objet, le client a ajouté que je vais récupérer cet objet. Donc, nous avons David Jones, 23 ans. Je vais le mettre à jour puis l'ajouter, le récupérer maintenant c'est David Jones 2 et ensuite nous avons 50 ans comme âge, récupérez-le, éléments dans le cache 1, je vais supprimer cet objet à nouveau éléments dans le cache 0 insérez-le une fois de plus, l'insertion est ajoutée et récupérez l'objet, puis je peux vous le montrer dans le cache. Donc, je traitais avec un objet à ce stade et la clé était client au nom du client qui lui était ajouté, puis je commencerai le chargement, testez maintenant. Vous verriez une certaine activité sur le cache, il y a des demandes qui arrivent et vous avez des demandes de clients traitant des données.

statistiques

Et si j'exécute simplement à nouveau ces clés de cache de vidage, cela me montrera simplement les cent clés vidées ensemble. Donc, ce sont les clés que j'ai ajoutées. Donc, c'est à quel point il est simple de commencer avec la mise en cache d'objets, toutes les données qui appartiennent à la base de données et ralentissent les choses, limitent votre évolutivité, vous pouvez l'amener à NCache en utilisant notre mise en cache d'objets. Il peut s'agir de tout objet de domaine, collections, ensembles de données, images, toutes sortes de données liées à l'application peuvent être mises en cache à l'aide du modèle de mise en cache d'objets. J'espère que cela vous aidera, permettez-moi de commencer avec cela, d'accord, cela couvre notre mise en cache de données, il y a ensuite SignalR Backplane.

ASP.NET SignalR Backplane Échantillon

Parlons de Signal R. Avec NCache nous avons un puissant messagerie pub/sub Plate-forme. Nous avons donc un exemple d'application et je vais également vous montrer les packages NuGet. NCache les bibliothèques sont installées avec l'installation ou vous pouvez utiliser nos packages NuGet. Ainsi, si vous accédez à notre référentiel NuGet en ligne et que vous recherchez NCache, vous verrez tous les packages NuGet. Alachisoft.NCache.SDK est pour la mise en cache d'objets, Linq pour la requête linq, nous avons un fournisseur d'état de session, puis nous avons également l'open source et la communauté.

Il s'agit du package NuGet que j'ai inclus dans cette application. Compilez-le simplement et voyons s'il fonctionne correctement, car un package NuGet devrait lui être ajouté. D'accord, pour SignalR Backplane tout ce que vous avez à faire est de vous assurer que le package SignalR NuGet est ajouté, je veux dire qu'il s'agit d'installer s'il n'est pas déjà installé, d'accord. Donc, vous avez ajouté un package NuGet et après cela, vous devez ajouter, il a ajouté des assemblages SignalR au besoin et des assemblages d'aide également et après cela, si vous allez sur le web.config, j'ai juste ajouté quelques paramètres là-dedans myname du cache est aspnetcache right suivi de la clé d'événement, qui est le nom du sujet que vous aimez pour cela. Donc, vous souhaitez réellement fournir un nom de sujet basé sur lequel vous souhaitez que les messages de chat SignalR ou les messages SignalR pour cette application de chat particulière soient transmis, puis tout ce que vous avez à faire est de changer une ligne de code à l'intérieur où vous spécifiez le le nom du cache et la clé d'événement et les mots de pointage NCache et exécutez l'exemple d'application. Il utiliserait automatiquement NCache pour le fond de plan SignalR, NCache devient votre backplan c'est comme il est simple à brancher NCache pour l'application SignalR.

Avantages que vous obtenez son .NET natif contrairement Redis il est rapide, évolutif, fiable par rapport aux bases de données ainsi qu'aux bus de messages, puis nous avons un modèle pub/sub entièrement fonctionnel et entièrement pris en charge, qui le sauvegarde. Ainsi, vous pouvez également utiliser la messagerie pub/sub directement, mais une extension de ce cas d'utilisation de la messagerie pub/sub est notre SignalR Backplane et c'est assez facile à mettre en place aussi.

Donc, cette application a commencé. Il devrait y avoir une clé ici, je pense qu'il est difficile de trouver la clé mais juste pour vous montrer le chat NCache, cela fonctionne et je vais le transmettre à un autre navigateur en signant un autre utilisateur, disons Nick. Si je ramène cela, vous pouvez voir qu'il a également diffusé le message à l'autre client connecté. C'est aussi simple que cela. Permettez-moi de demander une fois de plus, puis de vérifier si cela fonctionne comme prévu, alors voilà. Donc, cela est conduit à travers NCache et c'est très facile à configurer et c'est ainsi que vous configurez et la dernière fonctionnalité dans NCache, le cinquième booster est la mise en cache de sortie.

Ron, j'ai une question concernant SignalR, nos messages SignalR stockés en tant qu'objet visuel dans NCache ou fait NCache utiliser la notification pour cela ? NCache utilise la notification pub/sub pour cela. Donc, nous avons une plate-forme de messagerie pub/sub qui est en arrière-plan, dans le cache lui-même, vous ne verrez qu'un seul objet ou vous ne verrez même pas d'objet car c'est un sujet. Donc, il y a un sujet qui est créé, c'est un tunnel logique où plusieurs processus de travail sont connectés et ils diffusent réellement NCache, tous les messages SignalR à ce sujet. Donc, c'est un cadre de notification si vous demandez, si vous voyez beaucoup de messages ajoutés dans le cache, non vous ne le feriez pas, vous ne verriez qu'un sujet, puis il y aurait des messages dans le sujet. Il y a quelques statistiques dans les rencontres popper que vous pouvez visualiser pour voir combien de messages il y a dans le sujet, mais en ce qui concerne les objets individuels, vous ne verrez pas ces objets, vous ne verrez qu'un objet comme sujet. J'espère que cela aide.

Exemple de mise en cache de sortie ASP.NET

Dernière caractéristique de cela, je pense que nous manquons également de temps, je vais rapidement passer en revue cela. C'est notre mise en cache de sortie, il vous suffit de configurer la section de mise en cache de sortie, vous avez besoin d'une référence à NCache dll du fournisseur de cache de sortie. C'est ici, vous avez besoin de ces références Ncache.Adapters, web, runtime in cache et après cela, vous vous référez simplement au fournisseur de cache de sortie N, puis vous configurez le nom du cache sur aspnetcache, la version doit être la plus récente. La façon dont cela fonctionne est qu'il met en cache la sortie des pages statiques, vous l'exécutez simplement, puis il mettra simplement en cache la sortie d'une page statique. Si c'est la page entière ou des parties de la page qui sont statiques et que vous décorez votre partie de pages statiques avec ce cache de sortie de directive, spécifiez une durée, un emplacement et VaryByParam. Si ces paramètres ne changent pas, cela signifie automatiquement qu'il s'agit de la même sortie.

Ainsi, la sortie mise en cache est présentée à vos utilisateurs finaux, vous n'avez pas besoin d'exécuter les pages, vous n'avez pas besoin d'impliquer des bases de données, d'alléger la charge des processus de travail, de la base de données, d'économiser des ressources CPU et machine coûteuses et obtenez une sortie de page prête à l'emploi mise à la disposition de vos clients finaux. Ainsi, cela améliore globalement vos performances, ASP.NET le fournit en tant que fonctionnalité et NCache l'amène à un niveau distribué où nous avons une sortie de page très évolutive, très rapide et très fiable stockée dans NCache sans aucun changement de code et cela est vrai pour ASP.NET core ainsi, vous pouvez utiliser par la façon dont vous pouvez utiliser NCache au sein de l'ASP.NET core applications web également. Nous avons fait un webinaire séparé à ce sujet et si nous avons un cache idistributed, nous avons un stockage de session, puis nous avons également ASP.NET core la mise en cache des réponses ainsi que la mise en cache du noyau EF.

Voici donc quelques-unes des fonctionnalités que je voulais mettre en évidence, cela complète nos cinq boosters de performances. J'espère que vous l'avez aimé, n'hésitez pas à me faire savoir s'il y a d'autres questions, je pense que nous manquons également de temps. Donc, s'il y a d'autres questions maintenant, il est temps de les poser, alors faites-le moi savoir.

De manière générale, je voudrais également mentionner que NCache est un cluster de cache dynamique entièrement élastique à cent pour cent de disponibilité, sans point de défaillance unique. Nous avons de nombreuses topologies et fonctionnalités telles que le cryptage, la sécurité, la compression, les alertes par e-mail, la synchronisation de bases de données, les recherches de type SQL, les requêtes continues, le modèle pub/sub, les données relationnelles dans NCache, ceux-ci sont tous couverts dans le cadre de différentes fonctionnalités. Donc, s'il y a des questions spécifiques à ce sujet, n'hésitez pas à les poser également, sinon, je vais simplement conclure et passer la parole à Nick.

Merci beaucoup Ron une dernière question ici est-il possible de configurer un fournisseur personnalisé pour la mise en cache de session dans NCache? NCache est déjà un fournisseur personnalisé. NCache se trouve sous un fournisseur personnalisé, les modes par défaut sont InProc, State Server ou SQL Server, puis le quatrième mode d'ASP.NET est personnalisé. Alors, NCache provider lui-même est un fournisseur personnalisé. Je suis un peu confus sur la question s'il y a des exigences spécifiques à ce sujet, veuillez me le faire savoir autrement NCache lui-même est un fournisseur personnalisé pour ASP.NET.

D'accord, merci beaucoup Ron, s'il n'y a plus de questions, j'aimerais remercier tout le monde d'être venu nous rejoindre aujourd'hui et merci encore Ron pour votre précieux aperçu de cela et les gars si vous avez des questions, vous pouvez toujours nous joindre en nous envoyant des e-mails à support@alachisoft.com. Vous entrez en contact avec notre équipe commerciale en nous envoyant un email à sales@alachisoft.com et quelqu'un de l'équipe de vente se fera un plaisir de travailler avec vous et de s'assurer que toutes vos questions reçoivent une réponse, de fournir toutes les informations dont vous avez besoin et avec cela, je suggérerais également que vous puissiez télécharger une version d'essai à partir de notre site Web de NCache, est livré avec un essai de 30 jours. Nous avons également une médiation qui a une option de support payant ainsi qu'une édition open source gratuite, treize ans avec beaucoup de contenu. Merci à tous de vous être joints à nous et à la prochaine, merci.

Que faire ensuite?

 
© Copyright Alachisoft 2002 - . Tous droits réservés. NCache est une marque déposée de Diyatech Corp.