Camp de code d'Orlando 2019

Optimiser l'ASP.NET Core Performances avec cache distribué

Par Iqbal Khan
Président et évangéliste de la technologie

ASP.NET Core devient rapidement populaire pour le développement d'applications Web à fort trafic. Apprenez à optimiser l'ASP.NET Core performances pour gérer des charges de transaction extrêmes sans ralentir en utilisant un cache distribué .NET Open Source. Cette conversation porte sur :

Aperçu rapide de l'ASP.NET Core goulets d'étranglement de performance
Présentation de la mise en cache distribuée et de la manière dont elle résout les problèmes de performances
Où pouvez-vous utiliser la mise en cache distribuée dans vos applications
Quelques fonctionnalités importantes du cache distribué
Exemples pratiques utilisant Open Source NCache en tant que cache distribué

Je vais passer en revue ce sujet sur la façon dont vous pouvez optimiser ASP.NET core performances et je vais utiliser la mise en cache distribuée comme technique pour apporter ces améliorations et je vais utiliser NCache comme exemple dans ce cas.

ASP.NET Core Populaires (applications à fort trafic)

Nous savons tous que l'ASP.NET core est le nouveau .NET core, l'architecture propre et légère, la multiplateforme et l'open source et cela devient une raison majeure pour laquelle de plus en plus de personnes se tournent vers ASP.NET core.

En outre, il existe une énorme base d'utilisateurs ASP.NET héritée, en particulier si vous êtes une application ASP.NET MVC, puis passez à ASP..NET core est assez simple. Si vous n'êtes pas un MVC, alors, bien sûr, vous avez beaucoup de code à écrire. Donc, toutes ces raisons sont les raisons pour lesquelles je suis sûr que vous êtes également ici parce que ASP.NET core est le premier choix .NET pour faire des applications Web.

ASP.NET Core Nécessite une évolutivité

Ainsi, lorsque vous avez ASP.NET core est de plus en plus utilisé dans les situations de trafic intense. Un trafic élevé signifie généralement que vous avez une application orientée client. Vous pouvez être une entreprise en ligne, vous pouvez être une entreprise de vente au détail. Il y a une foule d'industries, de soins de santé, d'e-gouvernement, de médias sociaux, de paris en ligne, de jeux d'argent, tout ce à quoi vous pouvez penser. Tout le monde est en ligne ces jours-ci. Alors, n'importe qui ! Quand il y a une application web ASP.NET core est utilisé, cela signifie ASP.NET core doit être évolutif.

Qu'est-ce que l'évolutivité?

Qu'est-ce que cela signifie? Permettez-moi de définir cela, je suis sûr que vous en savez beaucoup, mais juste pour être complet, je vais juste définir la terminologie.

Ainsi, l'évolutivité signifie que si vous avez une application avec cinq utilisateurs, vous avez un très bon temps de réponse, vous cliquez dessus et en une seconde ou deux, la page revient. Ensuite, si vous pouvez obtenir le même temps de réponse avec cinq mille, cinquante mille ou cinq cent mille utilisateurs, votre application est évolutive. Si vous ne pouvez pas, vous n'êtes pas évolutif. Si vous n'avez pas de performances élevées avec cinq utilisateurs, vous devez passer à d'autres discussions sur la façon dont vous avez écrit votre code. Mais, je suppose que votre application est développée avec de bons algorithmes, avec une bonne approche et qu'il s'agit d'une application performante avec cinq utilisateurs. Alors, comment faire en sorte qu'il soit performant sous des charges de pointe ?

Qu'est-ce que l'évolutivité linéaire ?

Donc, si vous pouvez passer de cinq à cinq mille à cinquante mille, cela s'appelle l'évolutivité linéaire.

Et, la façon dont vous y parvenez, comme vous le savez dans un environnement à charge équilibrée, vous déployez ASP.NET core application avec un équilibreur de charge et vous ajoutez de plus en plus de serveurs. Ainsi, au fur et à mesure que vous ajoutez plus de serveurs, ici, que votre capacité de transaction, votre capacité en nombre de requêtes par seconde augmente de manière linéaire. Si vous pouvez y parvenir, vous pourrez atteindre les mêmes performances. Et c'est l'objectif de la discussion d'aujourd'hui que nous voulons être en mesure d'atteindre ces hautes performances sous des charges de pointe. Donc, si vous n'avez pas une haute performance sous charge de pointe, si vous n'avez pas une application linéaire, cela signifie que vous avez des goulots d'étranglement, quelque part. Ainsi, dès que vous dépassez un certain seuil, cela n'a pas d'importance si vous ajoutez d'autres cases. En fait, cela va probablement ralentir les choses parce qu'il y a un goulot d'étranglement quelque part qui empêche votre candidature. Donc, vous ne voulez certainement pas être une évolutivité non linéaire.

Quelles applications ont besoin d'évolutivité ?

Pour récapituler, quels types d'applications doivent être évolutives ?

Evidemment, ASP.NET core c'est de cela dont nous parlons. Vous pouvez également avoir des services Web, ce qui signifie que les applications ASP.NET sont les applications Web, ce qui signifie que leurs utilisateurs sont des humains. Les services Web sont à nouveau des applications Web. Leurs utilisateurs sont d'autres applications. Les microservices sont un concept relativement nouveau qui concerne également les applications côté serveur. Bien sûr, cela implique de ré-architecturer l'ensemble de votre application. Je ne vais pas entrer dans la façon dont vous faites cela. Je ne fais que mentionner l'application des types afin que vous puissiez cartographier tout ce que vous faites ou que votre entreprise fait ou non. Et enfin, beaucoup d'applications serveur générales. Ces applications serveur peuvent effectuer un traitement par lots. Par exemple, si vous êtes une grande entreprise, disons, si vous êtes une banque, vous devrez peut-être traiter beaucoup de choses en arrière-plan en mode batch, en mode workflow et ce sont les applications serveur.

Le problème et la solution de l'évolutivité

Ainsi, tous ces différents types d'applications doivent être capables de gérer l'évolutivité, ce qui signifie qu'elles doivent être capables de traiter toutes ces charges de transactions croissantes sans ralentir. Donc, il y a évidemment un problème d'évolutivité, sinon nous n'aurions pas cette conversation. Si tout allait bien, la bonne nouvelle est que votre niveau d'application n'est pas le problème, votre ASP.NET core l'application n'est pas le problème, c'est le stockage des données. Quelles que soient les données que vous touchez, peu importe, cela n'a pas d'importance, cela provoque un goulot d'étranglement des performances. Et, ce sont vos bases de données relationnelles, vos données héritées du mainframe et un tas d'autres données. De façon intéressante, NoSQL databases ne sont pas toujours la réponse parce que dans beaucoup de situations vous n'êtes pas capable de… parce que NoSQL database vous demande d'abandonner votre base de données relationnelle et de passer à une nouvelle base de données SQL ou NoSQL database ce que vous n'êtes pas en mesure de faire pour diverses raisons techniques et non techniques. Et, si vous n'êtes pas en mesure de déménager dans un NoSQL database, à quoi bon ? À droite?

Donc, mon objectif est que vous devez résoudre ce problème avec la base de données relationnelle dans l'image parce que c'est la base de données que vous allez devoir utiliser pour, comme je l'ai dit, diverses raisons. Et, si vous n'êtes pas capable de vous en éloigner, alors NoSQL databases ne sont pas la réponse dans de nombreuses situations.

Déploiement de cache distribué

Vous devez donc continuer à utiliser une base de données relationnelle et déployer à la place un cache distribué dans votre application.

Voici à quoi cela ressemble. Donc, si vous voyez que vous avez le même niveau d'application, vous pouvez y ajouter de plus en plus de serveurs à mesure que votre charge de transaction augmente. Dans le cas de beaucoup d'entre eux, disons des applications Web et des services Web, il s'agit généralement d'un équilibreur de charge au-dessus qui s'assure que chaque serveur Web reçoit une charge égale de la part des utilisateurs. Dans le cas d'applications serveur, il se peut qu'il n'y ait pas beaucoup d'équilibreur, cela dépend de la nature de l'application. Mais le fait est que vous pouvez ajouter de plus en plus de serveurs et qu'il n'y a qu'une seule base de données ici. Et, comme je l'ai dit, il peut y avoir des NoSQL database pour certaines données spécialisées plus petites, mais la majorité des données sont toujours relationnelles. Ainsi, l'objectif est de mettre un niveau de mise en cache entre les deux et un cache distribué est essentiellement un cluster de deux serveurs ou plus et ces serveurs sont des serveurs à faible coût. Ce ne sont pas des serveurs de type base de données haut de gamme et tout est stocké en mémoire.

Pourquoi en mémoire ? Parce que la mémoire est tellement plus rapide que le disque dur. Si votre application doit être de plus en plus performante, vous devez être absolument clair à ce sujet. Le disque dur, qu'il s'agisse d'un SSD ou de son disque dur, va vous tuer. Il faut aller en mémoire. Tout doit être stocké en mémoire, sinon vous n'obtiendrez pas les performances souhaitées. Et, c'est indépendamment du fait que vous alliez ou non dans un cache distribué, mais en mémoire, c'est le stockage. Ainsi, un cache distribué a deux serveurs ou plus. Il forme un cluster et le mot cluster signifie que chaque serveur connaît l'autre serveur du cluster, ils ont mis en commun les ressources, la mémoire, le processeur et la carte réseau. Ce sont donc les trois ressources qu'il rassemble en une seule capacité logique.

Mémoire, parce que chaque serveur a de la RAM, donc une configuration typique que nous avons vue utiliser par nos clients se situe entre 16 et 32 Go de RAM et chaque serveur de cache. son minimum de 16 nous le préconisons, entre 16 à 32. Et puis, au lieu d'aller au dessus de 32 à, disons 64 ou 128 go de RAM, dans chaque boitier ce qui oblige alors à augmenter la capacité CPU car plus on a de mémoire plus de collecte des ordures que vous avez à faire. Parce que .NET utilise GC, plus le ramasse-miettes signifie plus de CPU, sinon le ramasse-miettes devient le goulot d'étranglement. Donc, il vaut mieux avoir une gamme de 16 à 32 et pas plus grande et juste avoir plus de boîtes que d'avoir 128 Go de deux boîtes. Donc, c'est pour la mémoire.

Le processeur est évidemment la deuxième chose. Encore une fois, la configuration typique est d'environ 8 cœurs. Certains des déploiements haut de gamme utiliseraient environ 16 cœurs, mais 8 cœurs suffisent par boîte. Comme je l'ai dit, des serveurs low cost. Et la carte réseau, bien sûr, car toutes les données envoyées d'ici à ici sont envoyées via les cartes réseau. Maintenant, au niveau des applications, vous avez évidemment plus de serveurs d'applications que de serveurs de cache. Et encore une fois, nous recommandons généralement un ratio d'environ quatre pour un ou cinq pour un. Cinq serveurs d'applications sur un serveur cache avec un minimum de deux serveurs cache. Donc, si vous avez cinq serveurs d'applications ici, ils ont cinq cartes réseau, ils envoient des données à cinq pour un ratio de cartes réseau.

Donc, la carte réseau, vous devez avoir au moins une carte réseau gigabit ou 10 gigabits dans les serveurs de cache. En dehors de cela, il vous suffit de les rassembler et disons que vous commencez avec deux au minimum et lorsque vous avez atteint le maximum de deux, ce qui va se passer, c'est que vous le souscrivez, vous exécuterez votre application. Tout va fonctionner très rapidement ou peut-être que vous faites des tests de charge. Tout va fonctionner très vite et la charge accrue. Soudain, le côté serveur commencera à voir un processeur plus élevé, une consommation de mémoire plus élevée et le temps de réponse commencera à ralentir. Maintenant, c'est ce qui va se passer avec la base de données relationnelle, sauf ici, vous pouvez ajouter une troisième boîte et tout à coup vous obtenez un autre gros soulagement et maintenant vous recommencerez avec un débit plus élevé et maintenant vous pouvez ajouter de plus en plus de transactions, ça va commencer à culminer et puis vous ajoutez une quatrième boîte, vous savez.

Donc, c'est comme ça que cette image continue d'augmenter et cela ne devient jamais un goulot d'étranglement ceci, et ne jamais dire jamais, mais presque jamais, cela devient un goulot d'étranglement car vous pouvez ajouter de plus en plus de serveurs. Et, au fur et à mesure que vous ajoutez plus de serveurs ici, vous en ajoutez simplement plus dans ce cache ici, ce que vous ne pouvez pas faire avec la base de données. Maintenant, je mets 8020 load. En réalité, c'est plus comme si 90 % du trafic allait vers le cache et 10 % vers la base de données, car de plus en plus de données que vous allez simplement lire à partir du cache. Je vais passer en revue certains autres aspects qu'un cache doit gérer, mais il s'agit essentiellement d'une image, c'est la raison pour laquelle vous avez besoin d'un cache distribué.

Utilisation du cache distribué

D'accord! Alors, passons à autre chose. Maintenant que je vous ai convaincu, je l'espère, que vous devez incorporer un cache distribué dans votre candidature que la première question qui vous vient à l'esprit est, eh bien, qu'est-ce que j'en fais ? Comment l'utiliser ? Ainsi, il existe trois catégories principales dans lesquelles vous pouvez utiliser un cache distribué.

Il y en a d'autres, mais pour la plupart des discussions, les trois sont vraiment de haut niveau.

Mise en cache des données d'application

Le premier est la mise en cache des données d'application. C'est ce dont j'ai parlé jusqu'à présent. Quelles que soient les données contenues dans la base de données, c'est ce que j'appelle les données d'application, vous les mettez en cache afin de ne pas accéder à la base de données. Maintenant, gardez à l'esprit, et avec chacun d'entre eux, avec une mise en cache des données d'application, la nature du problème est que les données existent à deux endroits ; le cache et la base de données. Et, chaque fois que des données existent à deux endroits, qu'est-ce qui pourrait mal tourner ? Désynchronisés! Ouais! Ainsi, les données pourraient se désynchroniser. Donc, si vos données et le cache n'étaient pas synchronisés avec la base de données, cela pourrait créer beaucoup de problèmes. Je pourrais retirer un million de dollars deux fois en supposant que je devais commencer, mais, disons que... C'est le premier problème qui me vient à l'esprit.

Tout cache, tout cache distribué qui n'est pas capable de gérer ce problème, signifie que vous êtes limité aux données en lecture seule. Mais, ce que nous appelons les données de référence. Et c'est ainsi que la mise en cache a commencé, c'est-à-dire mettre en cache les données en lecture seule de mes tables de recherche. La table de recherche représente environ 10 % de vos données. Dans certaines applications, ce n'est qu'une application moyenne. 90 % de vos données ne sont pas des données de recherche. Ce sont des données transactionnelles. Ce sont vos clients, vos activités, vos commandes, tout. Donc, si vous n'êtes pas en mesure de mettre tout cela en cache, alors l'avantage, disons 10% des données, peut-être que la recherche est vraiment plus que sa juste part. Donc, ces 10 % pourraient vous donner l'avantage de 30 %, mais vous avez toujours 70 % des données que vous devez accéder à la base de données. Mais, si vous pouviez mettre en cache toutes les données, ce que vous ne pourriez faire que si vous obteniez ce confort, alors vous en tireriez le véritable avantage.

ASP.NET Core Mise en cache spécifique

Le deuxième cas d'utilisation ou la deuxième façon d'utiliser est ce que j'appelle ASP.NET core mise en cache spécifique et il existe trois façons. L'une est la session qui est la plus communément comprise. ASP.NET les avait ASP.NET core les a. Ils sont là pour rester. Je ne pense pas que les sessions vont disparaître, même si certaines personnes soutiennent que nous ne devrions pas utiliser les sessions. Il n'y a pas de mal si vous les utilisez. Le seul problème avec eux est que vous les stockez où. Cela a toujours été le problème avec ASP.NET. Quelles que soient les options de stockage que Microsoft vous a proposées, toutes étaient pleines de problèmes. Ainsi, la seule option à l'époque était d'utiliser un cache distribué que vous pouviez heureusement brancher en tant qu'option personnalisée à l'époque d'ASP.NET. En ASP.NET core, Microsoft n'a pas de mémoire intégrée ou ils ont une image comme une mémoire autonome, mais ils vont immédiatement dans un IDistributedCache ou un fournisseur de session personnalisé que vous pouvez connecter à un cache distribué tiers comme NCache.

Les sessions sont la première, la seconde est la mise en cache des réponses. J'allais dire qui ne connaît pas la mise en cache des réponses, mais ce n'est pas une bonne façon de demander. La mise en cache des réponses ressemble à une version plus récente du cache de sortie, mais elle est davantage basée sur les normes. C'est la sortie de la page que vous pouvez mettre en cache et je vais y revenir, mais c'est aussi quelque chose que vous pouvez mettre en cache et brancher un cache distribué en tant que middleware pour cela.

Et, troisièmement, si vous avez un signal ou une application qui est l'application Web en direct. Les applications Web en direct sont celles où, disons, si vous avez une application de trading d'actions qui doit constamment propager tous les changements de prix des actions et qui a des centaines de milliers de clients. Ils sont tous connectés, ils resteront donc tous connectés à la mise en cache ou aux niveaux d'application. C'est différent du HTTP normal où, pour chaque requête Web, une nouvelle connexion socket est ouverte. Ici, la connexion socket reste ouverte et les événements sont propagés depuis le serveur. Ainsi, dans un SignalR, lorsque vous avez une transaction plus élevée, un grand nombre d'utilisateurs, vous devez avoir un formulaire Web à charge équilibrée, mais comme les sockets sont maintenus ouverts, chaque serveur va parler à son propre client, mais maintenant que tout le les clients ou tous les serveurs ont différents ensembles de clients, ils doivent donc partager des données. Donc, ces données sont partagées via un fond de panier et ce fond de panier devient... Donc, c'est là que vous branchez un cache distribué. Je ne vais pas revenir sur les détails de ce Spécifique. J'aborderai les deux premiers mais pas le troisième.

Maintenant, la chose spécifique à propos d'ASP.NET core mise en cache spécifique est que les données n'existent que dans le cache. C'est ce que je disais, ne le mettez pas dans la base de données. Il n'y a pas besoin. Ce sont des données temporaires. Vous n'en avez besoin que pendant 20 minutes, 30 minutes, une heure, 2 heures, peu importe après quoi les données doivent disparaître. Donc, s'il est temporaire, il ne devrait exister que dans le cache et lorsque les données n'existent que dans le cache et qu'il s'agit d'un cache en mémoire, qu'est-ce qui pourrait mal tourner ? Vous pourriez perdre des données car tout est en mémoire. La mémoire est volatile. Donc, un bon cache distribué doit gérer cette situation, bien sûr, cela signifie que vous devez répliquer.

Messagerie Pub/Sub et événements

Le troisième cas d'utilisation est que de nombreuses applications doivent effectuer des opérations de type flux de travail. Microservice en est un très bon exemple. Ils doivent coordonner les activités, bien que les microservices ne soient pas le sujet, mais même ASP.NET core les applications ont parfois besoin de le faire. Alors, messagerie pub/sub est une autre façon parce que vous avez, encore une fois, gardez à l'esprit, vous avez une infrastructure en place où toutes ces boîtes sont connectées à cette infrastructure en mémoire redondante. Alors, pourquoi ne pas l'utiliser également pour la messagerie pub/sub ?

Donc, ce sont les trois cas d'utilisation courants. Donc, ce sont les trois façons que vous devriez utiliser NCache ou un cache distribué si vous voulez en profiter, si vous voulez maximiser le bénéfice.

Démonstration pratique

Donc, je vais rapidement, avant d'expliquer comment vous les utilisez réellement, je veux vous montrer à quoi ressemble un cache distribué. Je vais utiliser Azure comme environnement et je vais utiliser NCache. Et ce n'est qu'une rapide démonstration de…

Configuration d'un environnement

Je suis donc connecté à Azure. J'ai quatre machines virtuelles, encore une fois ce sont toutes .NET core.

J'ai donc quatre machines virtuelles dans Azure. Je vais en utiliser deux comme machines virtuelles de serveur de cache, ce sont essentiellement ces deux… Je vais avoir un client Windows et un client Linux. Donc, si vous avez parce que .NET core prend en charge Linux. Si tu as .NET core en tant qu'application, vous souhaiterez peut-être la déployer sur Linux. Maintenant, en cas de NCache, encore une fois, je ne fais pas de marketing NCache. Mais en cas de NCacheest assez proche de celle .NET core il peut donc fonctionner sous Windows ou Linux, à la fois les serveurs et les clients.

D'accord! Allons dans… Donc, je suis connecté à ce client, la boîte client Windows. Donc, je vais maintenant continuer et créer un cache pour moi-même.

Créer un cache en cluster

Donc, je vais utiliser cet outil appelé NCache, NCache manager ne vient en fait pas avec l'open source. Il y a un équivalent en ligne de commande mais je suis juste paresseux ici. Donc, je vais juste utiliser NCache gestionnaire, mais c'est la même fonctionnalité. La fonctionnalité ne change pas donc je viens de lancer NCache gestionnaire. Je vais dire créer un nouveau cache. Vous venez de nommer une cache. Toutes les caches sont nommées. Considérez cela comme une chaîne de connexion à la base de données, puis vous choisissez une topologie. Je ne vais pas entrer dans les topologies, mais j'y reviendrai vers la fin sur ce qu'un cache doit faire pour pouvoir gérer tous ces besoins. Donc, je vais juste utiliser la topologie du cache de réplique de partition. Réplication asynchrone. Je vais ajouter mon premier serveur de cache. 10.0.0.4 et le second 5. Donc, j'ai deux serveurs de cache. Je vais tout garder par défaut. Je vais aux expulsions et à tous les autres.

Et, je vais maintenant spécifier deux clients. 10.0.0.6 et 7. Je vais venir ici et je vais juste démarrer le cache. Alors, pensez-y comme une base de données, au lieu d'un serveur, vous avez plusieurs serveurs qui constituent le cluster et vous créez un cluster de serveurs de cache, puis vous affectez des clients. Vous n'avez pas à affecter les clients car vous pouvez simplement les exécuter, mais je le fais ici car cela vous donne plus de flexibilité.

Simuler le stress et surveiller les statistiques du cache

Ensuite, je veux aller tester le client. Donc, je suis le client. Je pense que je suis 10.0.0.6. laissez-moi juste m'assurer lequel je suis. Je pense que je suis 10.0.0.6 je pense. Allez! Donc, encore une fois, je fais tout dans le réseau virtuel Azure pour que le client soit en fait le serveur d'applications et que le cache soit tous ensemble maintenant. En cas de NCache vous auriez pu obtenir cela du azure marketplace. Ainsi, .6 est le client Windows. Donc, je vais lancer PowerShell et je vais m'assurer que je peux voir. D'accord! D'accord! Donc, vous verrez que ce client va parler au cache et maintenant je fais environ cinq six cents requêtes par seconde dans chacun des serveurs de cache. Permettez-moi d'ajouter un peu plus de charge. Je vais ouvrir un autre PowerShell et je mettrai l'accent sur une autre instance du client. Maintenant, vous verrez qu'il ira jusqu'à environ plus de mille à treize cents par serveur.

et maintenant faisons… Je vais en fait… Donc, j'ai ouvert une invite de commande ici. Permettez-moi de me connecter à la boîte Linux. Oups! Et désolé! Nous démarrons PowerShell là-bas. J'ai besoin d'importer les bibliothèques partielles du clone de NCache et je ferai le même cache de démonstration de stress, donc je vais… Avant de faire cela, comme vous pouvez le voir, je fais environ treize à quinze cents par serveur, ajoutez ceci en tant que client basé sur Linux parlant au cache et maintenant, tout à coup, j'ai presque deux mille cinq cents requêtes par serveur.

Donc, je fais environ cinq mille requêtes par seconde sur deux serveurs. Comme je l'ai dit, vous pouvez ajouter de plus en plus de charge et au fur et à mesure que vous maximisez ces deux boîtes, vous en ajoutez une troisième, puis vous en ajoutez une quatrième. Donc, c'est aussi simple que ça et encore une fois c'est une simulation. C'est une chose réelle comme un outil de test de stress. Donc, c'est ce que vous devez garder à l'esprit. Je vais continuer avec le cache réel maintenant. C'est un programme de tests de résistance. Il met juste comme un tableau d'octets. Je pense qu'il met en 1k de données. Il ajoute, il met à jour, il obtient. Donc, il simule quelle que soit votre application réelle et il a des paramètres que vous pouvez modifier pour voir quel est le rapport lecture / écriture dont nous parlions. Et, c'est un outil que nous donnons avec NCache, afin que vous puissiez réellement le tester dans votre propre environnement. Alors, pour voir comment NCache s'exécute réellement avant que vous ne passiez beaucoup de temps à migrer votre application vers celle-ci. Permettez-moi de passer rapidement. Je pense que je dirige ça.

ASP.NET Core Stockage de session

Donc, maintenant que nous avons vu à quoi ressemble un cache, comment vous pouvez ajouter plus de clients et comment vous pouvez ajouter plus de charge dessus, c'est très simple. Ainsi, la façon la plus simple d'utiliser un cache est d'y mettre des sessions. Et, pour les sessions, il y a deux choses que vous pouvez faire.

Soit vous pouvez simplement utiliser un fournisseur IDistributedCache. Disons NCache en a un. Dès que vous précisez NCache comme IDistributeCache, ASP.NET core commence à l'utiliser pour le stockage des sessions. Et, laissez-moi vous en montrer une partie. J'ai cet ASP.NET core application. Comme vous pouvez le voir ici. Dans mes services de configuration, je spécifie Ceci, je dis make NCache mon fournisseur de cache distribué. Donc, dès que je fais cela, cela commence à puis j'utilise des sessions standard et ces sessions standard utiliseront IDistributedCache qui utilise maintenant NCache. Donc, quel que soit le fournisseur de cache distribué dont vous disposez, c'est tout ce que vous avez à faire. Comme vous pouvez le voir, très peu de changement de code et toute votre application est automatiquement, toutes les sessions seront immédiatement mises dans un cache distribué.

public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
	// Add framework services.
	services.AddMvc();
	//Add NCache as your IDistributedCache so Sessions can use it for their storage
	services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
	
	//Add regular ASP.NET Core sessions
	services.AddSession();	
}

Et, l'une des choses que nous avons vues, c'est que lorsque beaucoup de nos clients, lorsqu'ils stockent des sessions dans la base de données et qu'ils ont des problèmes, pour eux de brancher quelque chose comme NCache est instantané et le bénéfice qu'ils voient, l'amélioration remarquable est instantanée. Le moindre effort le gain maximum est là. Parce que, bien sûr, la mise en cache directe de l'application est là aussi.

Je vais en sauter quelques-unes parce que je pense… Donc, il existe plusieurs façons de spécifier des sessions. L'un était le IDistributedCache, le second est que vous pouvez réellement utiliser un fournisseur de session personnalisé qui NCache a également et encore une fois, tous ces éléments sont open source. Ensuite, pour la mise en cache des réponses, encore une fois, vous faites la même chose. Vous spécifiez NCache comme cache distribué et il devient automatiquement le cache pour la mise en cache des réponses. Je ne vais pas entrer dans plus de détails.

ASP.NET Core Mise en cache des données d'application

Je veux que vous touchiez la base sur ce sujet un peu plus. Ainsi, lorsque vous effectuez la mise en cache des données d'application, contrairement aux sessions, vous devez désormais faire de la programmation d'API. Sauf si vous faites le noyau du framework d'entité.

Ainsi, par exemple, en cas de NCache, encore une fois open source, il existe un fournisseur de base EF. Nous avons donc implémenté des méthodes d'extension pour le noyau EF. Ainsi, vous pouvez réellement brancher NCache open source et utilisez vos requêtes de base EF habituelles et à la fin, vous pouvez dire à partir du cache ou de la base de données, quelque chose, c'est juste une méthode d'extension qui commence automatiquement à mettre en cache des éléments. Il vous donne un contrôle total sur ce que vous voulez mettre en cache, ce que vous ne voulez pas mettre en cache. Jetez-y un œil. C'est un moyen vraiment puissant.

Si vous faites du noyau EF, c'est ce que je vous recommande de faire. Je pense que pour tout ASP.NET core application, toute la programmation de la base de données doit être effectuée via le noyau EF, d'autant plus que le noyau EF est une architecture beaucoup plus agréable que l'ancien EF. Donc, c'est une façon de le faire.

L'autre est que vous pouvez réellement les fabriquer. Vous pouvez utiliser l'API IDistributedCache ou l'interface qui vous donne la flexibilité de ne pas être enfermé dans une solution de mise en cache, mais cela a un coût. C'est très basique. Il n'y a qu'une entrée get et c'est fondamentalement, eh bien, il y a aussi une suppression. C'est à peu près ça. Et, toutes les choses dont nous avons parlé, si vous ne pouvez pas garder le cache synchronisé avec la base de données, toutes ces choses, vous perdez tout cela. Donc, si vous souhaitez bénéficier de toutes ces fonctionnalités, vous devez accéder à l'API qui les prend en charge. Et encore une fois, parce que vous allez vous engager dans un cache open source, c'est généralement plus facile à faire, mais euh la mise en cache directe de l'application, l'API est très simple, il y a une clé et il y a une valeur. La valeur est votre objet.

Garder le cache à jour

Maintenant, permettez-moi d'aborder ce sujet de ce qui vous permet de garder le cache à jour. L'information vraiment précieuse, non? Que fais-tu?

Eh bien, la première chose que font presque tous les caches distribués, c'est l'expiration ! Vous faites une expression absolue. Quoi que vous mettiez dans le cache, vous dites de le retirer du cache dans cinq minutes. Donc, il est prudent de le garder en cinq minutes, je pense que dans cinq minutes, je suis le seul à le mettre à jour après que d'autres personnes pourraient le faire. Alors, NCache l'a, tout le monde l'a aussi. Transitoire… il y a une expression glissante pour les données transitoires comme les sessions et d'autres qui, une fois que vous avez fini de les utiliser, si elles ne sont pas touchées pendant un certain temps, disons des sessions, lorsque l'utilisateur se déconnecte après 20 minutes d'inactivité, la session expire. Donc, la même chose se produit. Les expirations, à peu près tout le monde en a.

Vient ensuite le cache synchronisé avec la base de données. Il s'agit d'une fonctionnalité qui vous permet de faire en sorte que le cache surveille votre base de données. Ainsi, vous pouvez en fait… lorsque vous ajoutez des éléments à NCache, disons, vous pouvez avoir une dépendance SQL qui permet NCache surveiller. La dépendance SQL est une fonctionnalité ADO.NET du serveur SQL que nous utilisons. La dépendance SQL vous permet de spécifier une instruction SQL ou une procédure de stockage qui permet NCache pour surveiller votre base de données SQL Server, cet ensemble de données spécifique. Et, si des changements se produisent dans cet ensemble de données, le serveur SQL notifie NCache et tout cache supprime ces données du cache ou si vous combinez cette synchronisation avec une fonction de lecture, il les recharge. Donc, disons que vous avez un objet client qui a été mis en cache et qu'il s'agit d'une dépendance SQL et que ce client a été modifié dans la base de données, à savoir les données transactionnelles des clients, il va donc changer fréquemment. Vous pouvez utiliser la lecture et recharger automatiquement sur l'expression ou synchronisation de la base de données.

Alors maintenant, tout à coup, votre cache est responsable de la surveillance des données. Il y a trois façons de le faire, il y a la dépendance SQL, la dépendance DB et le sceau sont des procédures stockées CLR. Je ne vais pas entrer dans les détails. Vous pouvez aller sur notre site Web et le lire. Mais encore une fois, la chose la plus importante est que si vous n'avez pas la synchronisation du cache avec la base de données en tant que fonctionnalité, vous êtes limité à ces données en lecture seule et statiques. Et, ensuite, cela limite le tout et encore une fois, vous pouvez également synchroniser ce cache avec la source de données non relationnelle.

Et, la troisième chose est que vous pouvez avoir un relationnel… la plupart du temps, vous allez mettre en cache des données relationnelles, qui ont des relations un-à-plusieurs un-à-un. Donc, disons qu'un client a plusieurs commandes. Si vous supprimez le client, les commandes ne doivent pas non plus rester dans le cache car vous l'avez peut-être supprimé de la base de données. Donc, si vous ne le faites pas, votre application doit faire tout cela, mais il y a un objet de cache ASP.NET qui a cette fonctionnalité appelée fonctionnalité de dépendance de clé. NCache l'a implémenté qui vous permet d'avoir une relation un à plusieurs ou un à un entre plusieurs éléments de cache et que si une chose est mise à jour ou supprimée, l'autre est automatiquement supprimée. Ainsi, ces quatre éléments combinés vous permettent de vous assurer que votre cache reste à jour et cohérent avec la base de données. Et, c'est ce qui vous permet ensuite de commencer à mettre en cache les données. Donc, c'est le premier avantage.

Lecture et écriture

La seconde est que si vous pouvez utiliser la lecture et l'écriture immédiates, cela simplifie votre application.

Lecture, comme je l'ai dit, vous pouvez combiner la lecture pour le rechargement automatique, ce que votre application ne pourrait pas faire si vous n'aviez pas de lecture. Et, encore une fois, vous pouvez mettre à jour le cache et le cache peut mettre à jour la base de données, surtout si vous avez un droit derrière, alors, encore une fois, nous parlons de performances, n'est-ce pas ? Ainsi, toutes les mises à jour doivent être apportées à la base de données. Eh bien, et les mises à jour vont être lentes par rapport aux lectures du cache. Alors, et si vous pouviez déléguer les mises à jour au cache et dire que je vais mettre à jour le cache, pourquoi ne pas mettre à jour la base de données pour moi. Je sais que c'est sûr parce que et nous allons travailler sur le modèle de cohérence éventuelle qui est ce que sont les systèmes distribués que vous sacrifiez ou vous devenez plus indulgent sur la cohérence et vous optez pour le modèle de cohérence éventuelle. Ce qui signifie que même si à ce stade, ce n'est pas cohérent, parce que le cache est mis à jour, la base de données ne l'est pas, en quelques millisecondes, elle sera mise à jour. Et, certaines données que vous ne pouvez pas vous permettre de faire, mais beaucoup de données que vous pouvez.

Ainsi, en faisant juste derrière, du coup vos mises à jour sont également ultra-rapides, votre application n'a pas à supporter le coût de la mise à jour de la base de données. Le cache le fait parce qu'il s'agit d'un cache distribué et qu'il peut absorber cela en tant que lot et il y en a d'autres. Donc, une fois que vous commencez à faire cela, cela signifie que vous pouvez maintenant mettre en cache beaucoup de données.

Regroupement de données

Une fois que vous avez mis en cache des données, de plus en plus de données, votre cache devient presque aussi riche qu'une base de données, ce qui signifie que vous mettez en cache presque toutes les données.

Lorsque vous mettez en cache presque toutes les données, la valeur de la clé n'est pas suffisante pour trouver des choses. Vous devez être capable de rechercher des choses. AppFabric utilisé pour avoir des groupes et des sous-groupes, des balises nommées balises, soit dit en passant, NCache open source a AppFabric papier d'emballage. Alors, ceux d'entre vous qui ont AppFabric peut se déplacer vers NCache comme une chose gratuite. Ainsi, le regroupement vous permet de récupérer facilement des données.

Trouver des données

La recherche SQL vous permet de trouver des choses comme, donnez-moi tous mes clients où la ville est New York. Donc, maintenant, vous effectuez des requêtes de type base de données dans le cache. Pourquoi? Parce que votre cache ne contient pas beaucoup de données.

Tout le paradigme est en train de changer parce que vous utilisez de plus en plus de mémoire. Encore une fois, la base de données est le maître. Ainsi, le cache ne l'a toujours que pour une période temporaire.