Camp de code d'Orlando
Mise à l'échelle des applications .NET avec la mise en cache distribuée
Par Iqbal Khan
Président et évangéliste de la technologie
Vos applications .NET peuvent rencontrer des goulots d'étranglement de base de données ou de stockage en raison de la croissance de la charge des transactions. Découvrez comment supprimer les goulots d'étranglement et faire évoluer vos applications .NET à l'aide de la mise en cache distribuée. Cette conversation porte sur :
- Aperçu rapide des goulots d'étranglement d'évolutivité dans les applications .NET
- Description de la mise en cache distribuée et comment 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 dans un cache distribué
- Exemples pratiques utilisant un cache distribué
La discussion d'aujourd'hui ne porte pas sur NCache, il s'agit de mise en cache distribuée. je me référerai à NCache à titre d'exemple mais les concepts sont globaux, ils s'appliquent donc à tous les caches.
Qu'est-ce que l'évolutivité
D'accord! Éliminons d'abord quelques définitions. La première définition est l'évolutivité. L'évolutivité n'est pas la performance des applications. Si vous avez cinq utilisateurs et que votre application fonctionne très rapidement, votre application n'est pas évolutive tant qu'elle ne peut pas avoir les mêmes bonnes performances avec cinq mille utilisateurs, cinquante mille ou cinq cent mille. Ainsi, l'évolutivité concerne les performances élevées sous les charges de pointe. Les gens confondent parfois performance et évolutivité. Votre application peut ne pas avoir de bonnes performances avec cinq utilisateurs, auquel cas la mise en cache ne vous aidera pas, vous avez d'autres problèmes à résoudre.
Évolutivité linéaire
L'évolutivité linéaire est, si votre application est conçue de telle manière que vous pouvez ajouter plus de serveurs et en ajoutant plus de serveurs, vous pouvez augmenter la capacité de transaction. Encore une fois, l'évolutivité que nous définissons en termes de capacité de transaction en termes de nombre d'utilisateurs et de nombre de transactions par seconde que votre application peut gérer. Donc, si votre application peut gérer plus de transactions de manière plus linéaire à mesure que vous ajoutez plus de serveurs, alors votre évolutivité linéaire et notre objectif est d'être une échelle linéaire pour avoir une évolutivité linéaire dans notre application.
Évolutivité non linéaire
Et, nous ne voulons certainement pas d'évolutivité non linéaire, c'est-à-dire que votre application est architecturée de telle manière qu'après un certain point, cela n'a pas vraiment d'importance si vous ajoutez plus de serveurs, votre application ne va pas augmenter en fait, elle va probablement laissez tomber. Cela signifie qu'il y a des goulots d'étranglement quelque part qui n'ont pas été résolus.
Quelles applications ont besoin d'évolutivité ?
Alors, pourquoi voulons-nous l'évolutivité et quelles applications ont besoin d'évolutivité ?
Habituellement, ce sont des applications qui sont des applications côté serveur. Ce sont ASP.NET maintenant ASP.NET core, Services Web, backends IOT, traitement de données volumineuses. Bien que le traitement de données volumineuses ne soit pas courant du côté .NET, il s'agit davantage de phénomènes Java, mais il devrait être possible de le faire également avec .NET, mais les applications de traitement de données volumineuses ont également besoin d'évolutivité et de toute autre application serveur. Par exemple, vous pouvez être une banque et vous avez des millions de clients et ils appellent et changent d'adresse ou peut-être émettent ou demandent une nouvelle carte ou peut-être transfèrent-ils des fonds et vous devez traiter toutes ces demandes en mode batch à nuit et il y a des exigences de conformité que vous devez remplir avant le jour ouvrable suivant. Ainsi, à mesure que vous en obtenez de plus en plus, même vos autres applications de traitement par lots doivent être évolutives. Il n'y a donc pas que ces applications. Toutes les autres applications qui ont juste besoin de traiter un grand nombre de transactions dans un temps compressé et ce temps compressé dans ces cas sont des transactions par seconde et ce temps compressé dans ce cas pourrait être dans cette exigence de conformité. Donc, si vous avez l'une de ces applications qui génèrent un trafic élevé ou des transactions élevées, vous êtes au bon endroit.
Problème d'évolutivité
Alors, où est le problème d'évolutivité ? Pourquoi avons-nous même cette conversation? Ce n'est certainement pas dans le niveau d'application que votre niveau d'application évolue très bien, vous avez un équilibreur de charge et vous pouvez ajouter de plus en plus de serveurs. Tout a l'air très bien. Le problème est vraiment dans votre base de données, votre stockage de données. Et j'entends par là les bases de données relationnelles ou les données héritées du mainframe. Et, vous ne pouvez pas les mettre à l'échelle de la même manière que vous pouvez mettre à l'échelle le niveau d'application. La raison en est que les données qu'il contient ne sont pas distribuées. La nature de la base de données est qu'elle doit être entièrement assemblée. Et, il en va de même avec le mainframe. Ainsi, la base de données peut être très rapide. Il se peut que cela se fasse en mémoire cache côté serveur, mais ce n'est pas évolutif et NoSQL databases.
Bien que l'une des raisons pour lesquelles les gens utilisent NoSQL est pour l'évolutivité des transactions, l'autre est pour l'évolutivité des données en termes, disons, vous avez des téraoctets et des téraoctets de données qui NoSQL est beaucoup plus adapté à cela. Et, cette troisième raison pour laquelle les gens l'utilisent parce que les documents JSON donnent cette flexibilité de schéma. Mais, NoSQL databases ne sont pas toujours en mesure de vous aider et la raison en est qu'ils vous obligent à déplacer les données des bases de données relationnelles vers un NoSQL database. Et si vous n'êtes pas en mesure de le faire pour diverses raisons, à la fois techniques et commerciales. Certaines des données doivent rester dans vos bases de données relationnelles et dans vos données mainframe héritées. Bien que, NoSQL databases sont super et nous avons un NoSQL database que nous avons lancé nous-mêmes l'année dernière NosDB, comme je l'ai mentionné, mais ils ne résoudront pas votre problème à moins que vous ne puissiez y mettre des données. Donc, si vous devez travailler avec des bases de données relationnelles, vous devez résoudre le problème d'évolutivité qu'elles posent et c'est là qu'un cache distribué entre vraiment en jeu.
Déploiement de cache distribué
Un cache distribué est essentiellement un magasin distribué en mémoire.
Logiquement parlant, c'est juste entre le niveau application et le niveau données. Physiquement, cela pourrait être un tas de machines virtuelles distinctes ou cela pourrait se trouver sur la même boîte que l'application ou certaines d'entre elles pourraient être ici certaines d'entre elles pourraient être ici et ce sont les choses dont nous parlerons. Mais logiquement, il se situe entre le niveau application et le niveau base de données. Et, l'argument fondamental est que si vous cachez des données, vous n'allez pas aussi souvent dans la base de données. Parce que vous n'allez pas à la base de données, elle ne reçoit pas toute cette charge, donc elle ne devient pas un goulot d'étranglement. Si 80 % du temps, vous pouvez accéder au niveau de mise en cache et que le niveau de mise en cache n'a pas le goulot d'étranglement d'une base de données, car il est également distribué comme un NoSQL database un niveau de mise en cache distribue également. C'est une clé/valeur. En fait, un autre mot pour un cache distribué est un cache en mémoire NoSQL magasin de valeur de clé parce que tout ce que vous mettez dans le cache de distribution, il y a une clé et il y a une valeur qui est votre objet. Donc, en faisant cela 80 % du temps, vous allez ici 20 % du temps, vous allez à la base de données. Ces 20% sont principalement des mises à jour.
Il y a bien sûr quelques lectures et ces mises à jour sont également plus rapides car il n'y a pas de concurrence avec les transactions de lecture et ce n'est plus un goulot d'étranglement. Pourquoi? Parce qu'un cache distribué formera un cluster de deux serveurs ou plus. Ce ne sont pas des boîtes chères, ce ne sont pas des boîtes de type serveur de base de données. Il s'agit d'une configuration de serveur Web typique, tout comme une boîte à quatre ou huit cœurs, avec beaucoup de mémoire. Beaucoup signifie 16 à 32 concerts, c'est ce que nous recommandons à nos clients. Certains de nos clients vont plus de 32 mais nous ne recommandons presque jamais d'aller plus de 64. Il vaut mieux ajouter une autre boîte que d'en avoir plus ici. Parce que si vous ajoutez plus de mémoire, la puissance de traitement doit être mise à niveau. Pourquoi? Parce qu'une application .NET a ce truc appelé ramasse-miettes et plus vous devez collecter de mémoire, plus le ramasse-miettes ou le GC doit fonctionner et le CPU devient un goulot d'étranglement dans ce cas et votre application commence à avoir des problèmes. Ainsi, le point idéal est de 16 à 32 Go de mémoire dans ces machines virtuelles ou boîtier physique et la plupart de nos clients utilisent des machines virtuelles ici. Et, environ 8 cœurs comme configuration matérielle et généralement deux cartes réseau, une carte réseau est pour le clustering et une pour que les clients lui parlent. Le mot client signifie votre serveur d'application, ce n'est donc pas vos clients. C'est votre serveur d'application qui est le client du cache.
Donc, un minimum de deux serveurs de cache, puis un rapport de quatre pour un ou de cinq pour un entre le niveau application et le niveau cache. Et, ce ratio est principalement basé sur ce que nous avons vu au fil des ans et nous sommes dans cet espace depuis plus de dix ans, que si vous ajoutez plus de serveurs ici pour ajouter plus d'activité, alors au-dessus de nos quatre à un ou un ratio de cinq pour un vous donnera une très bonne capacité. Et bien sûr, vous ajoutez plus de serveurs pour l'une des trois raisons. Soit vous avez besoin de plus de stockage parce que vous avez des besoins en mémoire comme nous venons de le dire, soit vous avez besoin de plus de capacité de transaction parce que vous aviez deux serveurs pour commencer et vous avez continué à ajouter des boîtes ici jusqu'à ce que le rejet soit au maximum. Dans une base de données relationnelle, si cela se produit, vous êtes bloqué. Vous êtes arrosé. Dans ce cas, tout ce que vous faites est d'ajouter une troisième boîte jusqu'à ce que la capacité de la troisième boîte atteigne son maximum, puis vous en ajoutez une quatrième et ainsi de suite. Ainsi, vous pouvez avoir autant de cases ici que vous le souhaitez. Nous avons des clients qui ont en moyenne environ cinq à dix boîtes ici et certains de nos clients ont 40 à 50 boîtes ici dans le niveau d'application, puis ils en ont en conséquence. Ainsi, pour une boîte à dix ou pour un niveau d'application à dix serveurs, vous auriez environ trois serveurs dans le niveau de mise en cache. Donc, c'est comme ça que vous faites votre planification.
Ainsi, l'objectif de la discussion jusqu'à présent est de vous convaincre qu'en ayant un niveau de mise en cache, vous n'aurez plus de goulot d'étranglement d'évolutivité. Ainsi, quel que soit le produit ou la solution de mise en cache que vous utilisez, vous devez incorporer un niveau de mise en cache dans votre application. Donc, vous devez concevoir votre application pour avoir un cache dans votre image et ainsi vous n'aurez jamais les goulots d'étranglement.
Cas d'utilisation du cache distribué
Donc, maintenant que nous sommes convaincus que vous devriez utiliser le cache en tant que développeur .NET, la prochaine question qui vous vient à l'esprit est où devez-vous l'utiliser ? Comment devriez-vous l'utiliser?
Et, le premier cas d'utilisation est la mise en cache des données d'application dont j'ai parlé jusqu'à présent, c'est-à-dire que vous avez des données d'application dans une base de données et que vous les cachez ici, vous n'avez donc pas besoin d'aller dans la base de données, la même chose .
Mise en cache des données d'application
La seule chose à garder à l'esprit à propos de ce cas d'utilisation est que les données existent maintenant à deux endroits, l'un est le maître qui est la base de données et l'autre est le cache qui n'est pas qui est l'autre endroit. Donc, si vos données existent à deux endroits, qu'est-ce qui ne va pas ? Si vous en avez deux copies, la plus grande préoccupation est de savoir si le cache sera frais, le cache aura-t-il la même version de données que la base de données, car si le cache n'aura pas la même version de données, alors vous sera obligé de mettre en cache les données en lecture seule. Et les données en lecture seule représentent environ 10 à 15 % de vos données totales. Donc, vous n'en profitez pas vraiment. Vous en bénéficiez, mais vous n'en bénéficiez pas autant que vous le devriez pour vraiment rendre votre application évolutive.
Donc, en fait, c'est tellement vrai que si vous demandez à une personne moyenne à quoi sert une cache. Ils diraient bien, je vais juste y mettre mes données en lecture seule. Tout le monde a peur de mettre en cache les données transactionnelles. Vos données clients, vos comptes ou vos activités qui changent toutes les 30 secondes, toutes les minutes, toutes les cinq minutes ou de manière imprévisible. Donc, les gens ont peur de mettre cela en cache pour cette raison parce qu'il y en a deux copies et que se passe-t-il si le cache ne sait pas que vous l'avez changé dans la base de données. Alors, gardons cela à l'esprit alors que nous continuons plus loin.
Mise en cache spécifique à ASP.NET
Le deuxième cas d'utilisation est, si vous avez une application ASP.NET, le plus connu est le état de la session. Et c'est aussi, le tout dans celui-ci, le premier exemple est l'état de session. Les sessions sont quelque chose qui, par défaut, vous avez deux options de stockage. L'un est InProc, l'autre est SQL, fourni par Microsoft. Sur site, il existe également un serveur d'état, mais les trois options présentent des problèmes d'évolutivité. Le serveur SQL a des problèmes de performances. La même raison pour laquelle nous n'aurons pas de mise en cache pour commencer. Lorsque vous stockez des sessions dans SQL, elles sont stockées sous forme de blobs. La relation est SQL comme toutes les bases de données relationnelles n'a pas été conçue pour le stockage de blob, c'est pour les données structurées. Donc, il ne fonctionne pas. Il y a beaucoup de problèmes. La plupart de nos clients lorsqu'ils se rendent à NCache, le premier cas d'utilisation est l'état de session. Cela parce que cela leur profite immédiatement. Et, ce qui est vraiment bien avec l'état de session, c'est qu'il n'y a pas de programmation car il y a un framework fourni par Microsoft qui permet un cache tiers comme NCache à brancher et tout ici est stocké dans le cache.
L'autre aspect d'ASP.NET est que si vous n'avez pas le framework MVC, si vous êtes dans le framework pré MVC que beaucoup d'applications ASP.NET sont encore, alors il y a une chose appelée état d'affichage. Et, pour ceux d'entre vous qui ne savent pas ce qu'est l'état d'affichage, il s'agit d'une chaîne cryptée qui est envoyée par votre serveur Web au navigateur uniquement pour être renvoyée lors d'une publication. Ainsi, il pourrait s'agir de centaines de kilo-octets de force cryptée qui vont et viennent. Et, lorsque vous multipliez cela par des millions de transactions que votre application va traiter, cela représente au minimum beaucoup de bande passante. Et, la bande passante n'est pas gratuite d'ailleurs c'est assez cher.
Et, deuxième bien sûr, mais lorsque vous devez envoyer une telle charge utile à vos performances, votre temps de réponse est plus lent. Donc, ce serait tellement plus agréable si vous pouviez simplement mettre en cache l'état d'affichage sur le serveur et envoyer une petite clé, donc lorsque la publication se produit, la clé revient et l'état d'affichage est extrait du cache et présenté à la page. Donc, c'est le deuxième cas d'utilisation. Encore une fois, de la même manière, il n'y a pas de programmation impliquée, il vous suffit de brancher un cache tiers comme NCache.
Le troisième cas d'utilisation est le Cache de sortie ASP.NET. Ce cache est la sortie de la page. Si la sortie de la page ne change pas, Microsoft dispose déjà d'une infrastructure qui la met en cache dans un InProc autonome local. Il est préférable de mettre un troisième cache distribué à sa place, de sorte que dans une batterie de serveurs Web, la première fois qu'une sortie de page est mise en cache, elle soit disponible pour l'ensemble de la batterie de serveurs Web au lieu que chaque serveur Web mette en cache sa propre copie.
Ce sont donc les trois cas d'utilisation des applications ASP.NET en plus de la mise en cache des données d'application.
Maintenant, la nature du problème ici est complètement différente ici. Dans celui-ci, vous aviez deux copies des données. Ici, le cache est le magasin principal. Ainsi, vous ne stockez plus les sessions dans la base de données. Vous ne stockez plus l'état d'affichage nulle part ailleurs. Ainsi, le cache est le magasin principal et c'est un magasin en mémoire. Ainsi, lorsqu'un magasin en mémoire est un magasin principal, qu'est-ce qui pourrait mal tourner ? la mémoire est volatile ! Ouais. Donc, il n'y a pas de persistance. Ainsi, un bon cache distribué doit répliquer les données sur plusieurs serveurs pour assurer la fiabilité des données, afin que vous ne perdiez pas cette session. Parce que, vous êtes peut-être une compagnie aérienne et que vous avez fait cette promotion spéciale du week-end pour Hawaï et que vous avez deux ou trois fois plus de trafic sur votre site Web et ce sont des gens qui ont fait toutes sortes de recherches et ils sont sur le point de appuyez sur le bouton Soumettre et ils perdent leur session. Vous risquez de perdre ce client avec des milliers de dollars de ventes pour chaque client. Donc, vous ne voulez certainement pas perdre la session. Donc, ne mettez pas de sessions dans un cache à moins qu'il ne fasse de la réplication.
Partage de données d'exécution
Le troisième cas d'utilisation est un partage de données d'exécution. C'est quelque chose que beaucoup de gens ne savaient pas depuis longtemps. Les gens utilisent des files d'attente de messages pour partager les événements entre plusieurs applications. Mais, un cache distribué vous offre un mécanisme d'événement très simple et puissant axé sur les données où, pensez à cela maintenant comme à un bus de service ou à un bus de messages, alors ce sont vos applications qui peuvent se parler à travers cela. Ainsi, au lieu d'utiliser MSMQ ou RabbitMQ, qui ont leurs propres avantages, un cache n'est pas là pour les remplacer. Mais, si votre besoin concerne davantage les données ou si votre besoin de messagerie concerne davantage les données et au sein du même centre de données, un cache distribué vous offre une interface plus simple, mais surtout plus évolutive. Donc, si vous avez une application de transaction plus élevée et encore une fois, toute cette discussion porte sur l'évolutivité.
Donc, bien que vous puissiez faire tout cela avec ces files d'attente de messages régulières. Lorsque vous entrez dans un environnement très transactionnel, ils ne sont pas distribués de la même manière qu'un cache distribué. Ainsi, un cache distribué vous permettra de faire tout cela. Disons que le type Pub/Sub d'un partage de données, il y a des notifications d'événements, il y a une fonctionnalité de requête continue qui NCache a que les caches Java ont aussi, que Redis ne le fait pas, avec lequel vous pouvez simplement partager des données entre les applications de manière très transparente. Et, ici aussi, le problème est similaire à l'application de la mise en cache spécifique à ASP.NET car bien que ces données existent probablement dans une base de données mais pas sous la forme que vous partagez.
Donc, vous l'avez probablement transformé en une partie du formulaire avant d'essayer de le partager afin que le formulaire transformé soit conservé dans le cache. Donc, vous ne voulez pas perdre ces données, donc un cache doit répliquer les données. En fait, même pour la mise en cache des données d'application, bien que techniquement, vous le puissiez, si vous perdez des données parce qu'un serveur de cache tombe en panne et que vous n'avez pas répliqué. Vous pouvez techniquement recharger ces données à partir de la base de données. Il n'y a pas de problème sauf qu'il y a un impact sur les performances car, quoi qu'il en soit, si vous avez perdu 16 Go de données, vous devez maintenant passer par 16 Go d'accès à la base de données, ce que vous ne voulez pas faire. Ainsi, la plupart de nos clients, même pour la mise en cache des données d'application, choisissent de répliquer car la mémoire est si bon marché. Ils ne veulent même pas prendre ce coup de performance. Avec ces deux-là, bien sûr, vous devez l'avoir, mais dans celui-ci, c'est en quelque sorte bon à avoir.
Démonstration pratique
D'accord, avant d'avancer sur la façon de procéder, je veux d'abord vous montrer à quoi ressemble une cache. je vais utiliser NCache comme exemple ici.
Configurer un environnement
Donc, j'ai dans l'azur j'ai trois VM demo1, demo2 et demo-client. demo1 et 2 vont être mes machines virtuelles de serveur de cache et demo-client est ma machine virtuelle de serveur d'applications. Dans votre cas, disons que vous aurez deux machines virtuelles de cache, puis un rapport de quatre à cinq, quatre à un ou cinq à un des machines virtuelles clientes.
Donc, je suis connecté au client de démonstration et je vais utiliser cet outil qui NCache a appelé NCache gestionnaire. Donc, je l'ai commencé ici. Je vais venir ici et dire créer un nouveau cache en cluster.
Créer un cache en cluster
Toutes les caches dans NCache sont nommés, donc je vais juste l'appeler democache, je ne vais pas entrer dans les détails de ce que chacun d'eux signifie, j'en parlerai un peu mais je choisirai un topologie de réplique partitionnée. En cas de NCache, une topologie signifie comment les données sont stockées et répliquées ? Une topologie de réplique partitionnée est quelque chose qui... si je revenais si je venais ici, considérez cela comme un cluster de cache à deux nœuds qui mettrait sur le point de se créer.
S'il s'agit d'une réplique partitionnée, chaque serveur aura une partition. Donc, il y aura un total de deux partitions. En cas de NCache, l'ensemble du cache contient environ un millier de compartiments, donc environ la moitié d'entre eux iront à la partition un, l'autre moitié ira à la partition deux.
Chaque partition est sauvegardée sur un serveur différent appelé réplique. La réplique en cas de NCache est passif, ce qui signifie qu'aucun client ne parle aux répliques, seule la partition parle aux répliques. Et, la réplique devient active uniquement lorsque sa partition principale ou lorsque la partition tombe en panne.
Ce qui signifie, disons, si ce serveur devait disparaître, disons, si nous avions un cluster à trois nœuds et une partition, disons que le serveur trois tombait en panne, la partition trois est en panne maintenant. Ainsi, la réplique trois deviendra automatiquement la partition trois, afin que vous ne perdiez aucune donnée. Ainsi, les répliques partitionnées vous offrent ces stratégies de stockage et de réplication. Il vous indique essentiellement que les données doivent être répliquées. Il existe également une réplication synchrone et asynchrone. Donc, de toute façon, je reviendrai là-dessus, mais je voulais juste vous montrer ce que cela signifie. Donc, je vais choisir une réplication asynchrone entre la partition et les répliques. Ensuite, je spécifierai mon serveur de cache, donc le premier est demo1, le second est demo2. Maintenant, tout ce que je dis en cas de NCache, vous pouvez le scripter complètement, afin que cela puisse être automatisé. Je vais laisser tous les paramètres par défaut. C'est le port TCP sur lequel les clusters de cache se sont formés. Je vais spécifier la quantité de mémoire que je veux que le cache utilise sur ce serveur et le cache n'utilisera pas plus que cette mémoire. Donc, tout ce que je spécifie ici est cette fois deux parce que. Il y a une partition et il y a une réplique.
Donc, c'est la taille d'une partition. Donc, dans votre cas, ce sera bien plus que cela, bien sûr, car si vous avez 16 Go dans un serveur de cache, vous devez laisser environ 2 à 2.5 Go pour le système d'exploitation et d'autres processus et allouer le reste. Donc, disons qu'à partir d'un concert de 16, il vous reste 13 concerts et demi, mais 13 et demi divisé par 2 serait une taille de partition, puis NCache s'assurera qu'il n'utilise pas plus que cette mémoire. Ainsi, lorsque cette quantité de mémoire est consommée, le cache est considéré comme plein en cas de NCache. Et puis NCache a l'une des deux options. Un, vous pouvez dire NCache rejettera tout nouvel ajout de données jusqu'à ce que certaines données expirent automatiquement ou vous pouvez faire ce que cette chose a appelé l'expulsion. Alors, NCache vous donne trois algorithmes d'éviction LRU, LFU et FIFO prioritaire. Donc, vous pouvez dire dans ce cas, évincez 5% du cache.
Alors maintenant, je veux en parler un peu dans le contexte de, disons que vous stockez dans chacun des cas d'utilisation ici. Si vous effectuez une mise en cache des données d'application, l'éviction est parfaitement acceptable. Il n'y a aucun problème. Vous venez d'épuiser la mémoire que vous aviez expulsée de certaines des moins récemment utilisées, puis faites de la place pour de nouvelles données. Ainsi, cela devient comme une fenêtre mobile, n'est-ce pas ? Ainsi, à mesure que vous utilisez de plus en plus de données, l'ancienne est supprimée et la nouvelle. Donc, c'est le plus couramment utilisé. Et si c'était une session ? Si le cache est utilisé pour stocker des sessions, vous ne voulez pas d'expulsions. Pourquoi ne veux-tu pas son expulsion ? Parce que la session peut encore être active. Il n'a peut-être pas passé ces 20 minutes ou quel que soit votre délai d'attente. Si tel est le cas et que vous supprimez toujours la session, vous forcez le même problème dont nous venons de parler, c'est-à-dire qu'un utilisateur ne s'est pas déconnecté mais que vous vous déconnectez. Donc, ce que vous devez faire, c'est planifier votre capacité. En cas de NCache, vous pouvez le faire très facilement, vous pouvez voir la quantité de mémoire consommée par une session moyenne, puis planifier votre capacité. Extrapolez la quantité de mémoire qui va être utilisée. Faites en sorte que cet autre stockage de session ne soit jamais expulsé. Le stockage des données d'application ou le cache des données d'application peuvent être supprimés sans problème. Mais, le cache de session ne doit pas être vidé. Il ne doit expirer que lorsque l'utilisateur n'utilise plus la session.
Donc, je vais juste dire terminer et j'ai un cluster de cache à deux nœuds. Je viendrai ici et j'ajouterai un nœud client. Dans mon cas, je n'ai qu'un seul nœud client comme je l'ai dit. Je pense que je n'ai probablement pas le cache alors nous avons commencé. J'ai besoin de ce service donc le NCache le gestionnaire peut parler à cela et faire la configuration. D'accord! Maintenant que j'ai fait cela, je vais venir ici et dire démarrer le cache. Alors maintenant en démarrant le cache, NCache est la construction d'un cluster entre ces deux boîtes, à ce TCP.
Simuler le stress et surveiller les statistiques du cache
Ainsi, vous n'entrez pas dans les détails de quelles boîtes contiennent quelles données et si le cluster. Vous savez juste qu'il y a une démocache. Chaque fois que vous vous connectez à ce cache, votre application se connecte automatiquement à tous les serveurs en cas de répliques partitionnées. Alors, NCache s'occupe de tous les détails et je vais venir ici et dire afficher les statistiques et voici quelques compteurs PerfMon pour que vous puissiez voir ce que NCache fera l'affaire mais une fois que vous commencerez à l'utiliser. Je vais également démarrer cet outil appelé NCache moniteur. Et c'est comme un outil de style tableau de bord. Et, en cas de NCache, vous avez la possibilité d'utiliser un outil de stress test qui vous permet de simuler très rapidement l'utilisation de votre application sans aucune programmation.
Donc, par exemple, je vais dire démocache de l'outil de test de stress, donc ça va en faire un, en mettre un et des trucs comme ça. Et soudain, vous verrez maintenant que cet outil parle aux deux serveurs de cache et qu'il fait environ 700 requêtes par seconde sur chaque boîte, environ 7 à 800 voire jusqu'à un millier. Disons que je veux augmenter la charge. Donc, je veux lancer un autre outil de test de résistance.
C'est comme vous le feriez avec votre application. Je veux dire, quand vous voulez vous tester, vous allez avec votre application, vous exécuterez votre application avec un outil de test de stress et ensuite vous continuerez à ajouter de plus en plus de stress et ensuite vous voudrez voir si l'ensemble du système fonctionne. Donc, pour le moment, vous testez simplement le composant de cache de celui-ci. La plupart de nos clients ce qu'ils font lorsqu'ils évaluent NCache, ils font ce benchmarking. Donc, une fois qu'ils ont tout configuré dans leur environnement, même si nous avons publié nos benchmarks, ils ne le font pas. Je veux dire qu'ils vérifient tout dans leur propre environnement. Ainsi, à mesure que vous en ajoutez de plus en plus, vous verrez que cette charge vient de doubler.
Permettez-moi d'aller encore un outil de test de stress. Vous verrez que ça continue d'augmenter. Juste là, tu vois ! Ainsi, je peux continuer à ajouter de plus en plus d'outils de test de stress, jusqu'à ce que je puisse maximiser mon CPU client. Donc, je suis passé à environ 50 % sur mon serveur d'applications. Donc, je peux certainement ajouter plus d'outils de tests de résistance. Une fois que j'aurai atteint le maximum de ce client, j'ajouterai un autre client. Alors, c'est comme ça que je peux. Ainsi, même en ce moment, par exemple, nous effectuons environ 5,000 XNUMX requêtes par seconde avec seulement trois outils de test de résistance. Donc, avec ceci et ensuite, vous pouvez également surveiller par exemple ici tout cela. Ainsi, avec cela, vous pouvez réellement voir à quoi ressemble un cache. Et maintenant, allons plus loin du point de vue du développement.
Mise en cache spécifique à ASP.NET
Donc, maintenant que vous savez à quoi ressemble un cache, voyons comment utiliser ce cache dans votre application. Donc, pour ASP.NET, comme je l'ai dit, la première chose à faire est d'utiliser le cache pour les sessions. Pourquoi? Parce que c'est le plus simple. Il n'y a pas de programmation, il n'y a aucun effort pour le faire. Je viens de vous montrer à quelle vitesse vous pouvez configurer un cache avec intérêt de NCache, disons que si je venais ici et que j'entrais dans certains des exemples de code, ils auraient déjà dû les ouvrir, mais je ne le fais pas. Alors, voici une application ASP.NET que vous pouvez utiliser NCache avec ASP.NET pour les sessions. Vous devez simplement aller modifier web.config. Donc, j'ai le web.config. La première chose que vous devez faire est d'ajouter cette ligne d'assemblage à l'assemblage. NCache, ce fournisseur de magasin de sessions est NCache assembly qui a implémenté l'interface du fournisseur de magasin de sessions ASP.NET. C'est donc ce qui permet NCache à brancher. Ainsi, vous pouvez simplement copier la ligne ici, puis vous arrivez à la balise d'état de session, qui se trouve ici. En cas de NCache, il vous suffit de copier cette balise. Assurez-vous que ce mode est personnalisé car c'est ce qui permet à ce cache tiers de se connecter. Le délai d'attente est ce que vous voulez qu'il soit et ensuite la seule chose dont vous avez besoin en cas de NCache est de s'assurer que le nom du cache est spécifié.
Ainsi, une fois que vous avez installé NCache puis sur les serveurs de cache vous installez la partie serveur, sur le serveur d'application vous installez la partie client de NCache, vous créez le cache comme nous venons de le faire et vous le mettez à jour et c'est tout. C'est tout l'effort dont vous avez besoin pour commencer à utiliser NCache puis chaque session est un objet dans le cache. Lorsque vous faites cela dans ce compteur PerfMon, vous verrez combien de sessions vous voyez. Ce qui se passe généralement, nos clients créent trois caches. Donc, nous venons de créer une cache ici, n'est-ce pas ? Ainsi, nos clients fabriqueront trois caches. L'un des caches est destiné aux sessions. Ainsi, ils ont un cache séparé pour les sessions. L'un des caches et les deux caches sont destinés aux données d'application. L'un est ce qu'ils appellent les données de référence. L'autre est les données transactionnelles. Les données transactionnelles sont quelque chose qui change très fréquemment. Et la raison pour laquelle ils le font est à cause de certaines des autres fonctionnalités que je vais aborder. Mais, sur les mêmes machines virtuelles, vous pouvez créer plusieurs caches. Donc, c'est tout ce que vous avez à faire pour le stockage de l'état de la session, c'est très simple, aucune programmation n'est nécessaire et vous êtes prêt à partir.
Mise en cache des données d'application
Mais, si vous souhaitez mettre en cache les données d'application, malheureusement, dans l'espace .NET, le noyau EF fournit enfin une architecture dans laquelle vous pouvez brancher un cache tiers.
NCache le supporte également. Mais, jusqu'à EF6, y compris EF6, l'architecture ne prenait pas vraiment en charge le branchement d'un cache tiers. NHibernate a longtemps soutenu cette architecture. Donc, pour NHibernate NCache peut se brancher sans aucune programmation. Ainsi, même la mise en cache des données d'application avec des fonctionnalités minimales, vous pouvez simplement vous passer d'appels d'API. Mais, pour la plupart, vous devez être préparé mentalement là-bas pour la mise en cache des données d'application, vous devrez faire de la programmation. Mais c'est une API très simple. Cette API ressemble beaucoup à un objet de cache ASP.NET. Vous vous connectez au cache avec un nom de cache.
Permettez-moi de vous montrer rapidement à quoi cela ressemble. Permettez-moi d'ouvrir… J'ai rencontré des problèmes de machine virtuelle Azure. Je commence cet autre truc autre à ce tout ouvert. Alors, disons que j'ai cette application console vraiment basique. La première chose que vous devez faire est de lier deux des NCache assemblées, on est NCache.Runtime, l'autre est NCache.La toile. NCache.Web est l'API réelle que vous appelez. Ensuite, vous liez ces deux ou vous utilisez à nouveau ces deux espaces de noms NCache.Runtime puis .Web.Caching. Au début de votre application, vous vous connectez au cache en fonction d'un nom et vous obtenez un handle de cache comme pour la base de données. Bien sûr, dans une application ASP.NET, vous le ferez probablement dans le global.ASAX au démarrage de l'application ou dans la méthode InIt. Ensuite, vous créez simplement votre objet et vous faites Cache.Add. Le Cache.Add utilisera une clé, une sorte de chaîne. Ce n'est pas une bonne clé, votre clé doit être beaucoup plus précise, puis voici votre objet et c'est tout. Vous passez cet appel et dans les coulisses maintenant, ça se passe. Disons que si vous aviez cette topologie de réplique partitionnée, ce qui va se passer, c'est que votre application est connectée. Ainsi, chaque box est connectée à tous les serveurs de cache. Donc, vous venez de faire un Cache.Add, n'est-ce pas ? Ainsi, Cache.Add ira voir la carte de distribution qui ressemble à la carte de compartiment. Chaque compartiment a une plage de valeurs de clé en termes de plage de valeurs de clé de hachage en termes de clés pouvant entrer dans ce compartiment. Donc, il va utiliser cette carte de compartiment pour savoir à quel serveur il doit aller parler car il est connecté à tous, n'est-ce pas ?
Et, ça va aller et disons que vous ajoutiez le point numéro trois ici. Il va ajouter l'élément numéro trois ici et si vous aviez activé la réplication asynchrone, l'application reviendra et l'application sera terminée. Le cache va maintenant, cette partition sait qu'elle doit le répliquer ici. Ainsi, il répliquera ceci de manière asynchrone, dans une opération en masse, dans l'autre boîte et vous aurez immédiatement cet élément à deux endroits. C'est donc ce que Cache.Add a fait sous les couvertures.
D'accord, je fais des allers-retours parce que je voulais en quelque sorte vous donner un aperçu, mais à quoi ressemble un cache, comment le créer, à quoi ressemble une API.
Fonctionnalités de mise en cache des données d'application
Voyons maintenant quels sont les problèmes que vous devez résoudre lors de l'utilisation du cache pour la mise en cache des données d'application.
Gardez le cache frais
Nous avons parlé de garder le cache frais, n'est-ce pas? Alors, comment gardez-vous le cache à jour ? Comment s'assurer qu'un cache est frais ?
Le plus courant et celui que tout le monde soutient, y compris Redis est l'expiration. L'expiration absolue. Ainsi, lorsque vous ajoutez quelque chose au cache, disons, même ici, vous spécifiez une expiration ici, c'est-à-dire que vous dites expirer cela après une minute. Quand tu dis ça en cas de NCache, NCache créera des index sur le serveur et nous surveillerons ces données et les expirerons après une minute. Donc, en fait, c'est ça, il va en fait spécifier une valeur de date et d'heure absolue qui était dans une minute à partir de maintenant. NCache sait que ce jour-là, il doit faire expirer cet élément. C'est ainsi que le cache s'occupe automatiquement de s'assurer que les données sont supprimées. Et, qu'est-ce que cela signifie vraiment? Cela signifie que vous dites au cache que je ne me sens vraiment pas à l'aise de conserver ces données plus d'une minute ou plus de cinq minutes parce que je pense que quelqu'un va les modifier dans la base de données. Donc, il est seulement sûr de le garder dans le cache aussi longtemps. Il existe une autre expiration appelée expiration coulissante qui ressemble à la même chose mais dont le but est totalement différent. L'expiration glissante est principalement utilisée pour le nettoyage. Donc, si vous avez des sessions, vous utilisez l'expiration glissante pour nettoyer après que personne n'utilise cette session. Ainsi, lorsque quelqu'un se déconnecte après 20 minutes d'inactivité, la session sera considérée comme expirée. Ainsi, il sera automatiquement supprimé.
Utilisation des dépendances de base de donnéesMais cela n'a rien à voir avec la mise à jour du cache. L'expiration absolue est celle qui maintient le cache à jour. Mais, il y a un gros problème avec l'expiration absolue. Et, le problème est que vous faites une supposition qu'il est sûr de conserver les données pour cela dans le cache aussi longtemps et cette supposition n'est pas toujours exacte. Alors, que faites-vous dans ce cas ? Ensuite, dans ce cas, vous devez avoir la possibilité pour le cache de se synchroniser. S'il remarque un changement dans la base de données, cela signifie que le cache doit savoir quelle est votre base de données. Cela signifie que le cache doit avoir une relation entre l'élément mis en cache et quelque chose au niveau de certaines données de la base de données que vous devez indiquer au cache et c'est là qu'il y a cette chose appelée dépendance au cache SQL dans ADO.NET qui NCache utilise, qui est une dépendance SQL, également appelée dépendance Oracle, qui fonctionne en fait de manière très simple. Mais, c'est une fonctionnalité vraiment puissante. Et, nous venons ici. Je vais juste utiliser la dépendance SQL. Ainsi, lorsque vous ajoutez quelque chose au cache, vous faites la même chose Cache.Add, n'est-ce pas ? Vous avez une clé de cache. Maintenant, au lieu de la valeur, vous spécifiez l'élément de cache qui est NCachede la propre structure de données et là-dedans, il contient la valeur, mais il contient également cette chose appelée dépendance au cache SQL.
Cette dépendance au cache SQL est NCachemais il correspond à la dépendance de cache SQL ADO.NET. Remarquez qu'il a une chaîne de connexion ici, puis une instruction SQL. Ainsi, l'instruction SQL dans ce cas correspond à une ligne de la table product. Alors, que se passe-t-il vraiment ici ? Je veux dire, vous exécutez réellement ce code ici. Votre base de données est ici, vous demandez donc au cluster de cache de se connecter maintenant à la base de données en fonction de cette chaîne de connexion que vous venez de lui transmettre, en fonction de cette chaîne de connexion et vous passez dans le serveur SQL et vous dites s'il vous plaît connecter avec ma base de données SQL Server. Et, surveillez le serveur SQL pour vous avertir, vous étant le serveur de cache, si des modifications sont apportées à cet ensemble de données. Cela signifie si cette ligne est mise à jour ou supprimée. Si cela se produit, le serveur SQL envoie une notification de base de données au client qui est dans ce cas le serveur de cache. Un de ceux-là. Et alors que fait le serveur de cache ? Le serveur de cache supprime cet élément du cache. La suppression signifie que, puisqu'elle n'est plus dans le cache, votre application est obligée d'aller la chercher dans la base de données qui a maintenant la dernière copie. Ainsi, bien que l'expiration soit une supposition éclairée, ce n'est pas une supposition. Il s'agit d'une véritable synchronisation prévisible, où elle s'assure que le cache est toujours cohérent avec la base de données.
Maintenant, en cas de NCache, vous pouvez le faire de trois manières différentes. L'une est la dépendance SQL qui utilise des événements de base de données, ce qui est comme le temps réel. L'autre est NCachesa propre dépendance de base de données qu'il utilise pour l'interrogation et c'est pour les bases de données qui n'ont pas de mécanisme de notification d'événement ou même pour le serveur SQL, si vous pensez que vous avez trop de dépendances SQL et pour chaque dépendance SQL, une dépendance de cache SQL est créée dans Serveur SQL qui est une structure de données supplémentaire. Pensez que si vous en aviez créé des centaines de milliers, votre serveur SQL allait s'étouffer. Donc peut-être que ce n'est pas une bonne idée si vous avez beaucoup de dépendances SQL d'avoir cette façon de synchroniser. Alors peut-être que la dépendance à la base de données est bien meilleure lorsqu'elle peut synchroniser des milliers de lignes en un seul appel, car elle dispose d'une table d'interrogation qu'elle surveille.
Et, il y a une troisième façon qui consiste à écrire simplement une procédure stockée CLR pour qu'elle soit appelée par votre déclencheur. Ainsi, si vous avez un déclencheur de mise à jour, d'insertion, de mise à jour ou de suppression, appelez cette procédure CLR. Et la procédure CLR prend les données de cette ligne, construit cet objet .NET que votre application utilise et le stocke dans le cache. Maintenant, c'est là qu'une API asynchrone est très utile car vous ne voulez pas attendre dans la transaction de base de données qu'un cache soit mis à jour. Cela ralentit simplement les transactions de la base de données qui ont tendance à expirer très rapidement. Donc, il est vraiment conseillé que si vous implémentez ce mécanisme, vous utilisiez les méthodes asynchrones pour aller mettre à jour les données.
Ce sont donc les trois façons de synchroniser le cache. Cette fonctionnalité est vraiment importante car elle vous permet de vous assurer que le cache sera toujours frais, sans quoi vous ne faites que deviner. Et, de la même manière, vous pouvez synchroniser le cache avec des bases de données non relationnelles. Il existe une fonction de dépendance personnalisée qui NCache a quel est votre code qui NCache appels que vous pouvez aller surveiller votre magasin de données personnalisé. Votre source de données personnalisée peut être un stockage cloud. Ça pourrait être n'importe quoi, c'est juste n'importe quel code que vous pouvez aller vérifier. Il est donc très important de garder le cache à jour et ce sont les moyens de vous en assurer.
Lecture et écriture
Ainsi, la fonctionnalité suivante est la lecture et l'écriture.
La lecture est essentiellement, c'est encore votre code. Maintenant, toutes ces fonctionnalités dont je parle NCache les a mais ils ne le sont pas NCache seul. Les caches Java en ont tous. Redis peuvent ou non en avoir. Donc, c'est ce que vous devez faire si vous voulez faire une analyse détaillée, si vous voulez savoir si ce Redis a ou non, en cas de NCache venez ici et allez simplement aux comparaisons et il y a un Redis versus NCache comparaison des fonctionnalités. Ceci est basé sur leur documentation et la documentation des caches. Ainsi, vous pouvez réellement télécharger ceci et parcourir toutes ces fonctionnalités. Ainsi, la lecture est essentiellement votre code qui se trouve sur le serveur de cache. Donc, ça ressemble à ça. Donc, c'est que vous mettez en œuvre. Alors, laissez-moi juste vous montrer cette interface pour que l'interface de lecture ressemble à… Alors, voici une interface de lecture ici, n'est-ce pas ? Curseur main dans NCache et il y a un InIt qui se connecte à votre source de données, dispose et il y a une méthode de chargement. Ainsi, load vous donne une clé et vous restituez un objet en fonction des données que vous avez obtenues. Et, ensuite, vous pouvez spécifier quand il doit expirer et tout. La même chose se passe avec l'écriture directe, c'est que vous avez InIt et disposez, puis il y a une écriture dans la source. Ainsi, l'écriture peut être ajoutée, mise à jour ou supprimée. Où utilisez-vous l'écriture continue et pourquoi sont-elles si importantes ?
La lecture, tout d'abord, donc la façon dont cela fonctionne, vous permet d'avoir un Cache.Get et le cache n'a pas les données. Le cache appellera votre lecture pour aller le chercher dans la base de données. C'est un avantage. Le deuxième avantage est que vous pouvez combiner la lecture avec l'expiration et la synchronisation de la base de données. Ainsi, au lieu de le supprimer du cache, vous le rechargez. L'écriture immédiate fonctionne de la même manière, sauf qu'il y a une écriture différée, ce qui signifie que vous ne mettez à jour le cache que dans la mesure où le cache met à jour votre base de données. Ainsi, vos mises à jour deviennent également ultra-rapides. Ainsi, partout où les performances de la base de données deviennent un goulot d'étranglement, vous disposez d'un cache pour vous renflouer. Une fois que vous avez implémenté la lecture et l'écriture, vous pouvez consolider tout le code de persistance ou la majeure partie dans le niveau de mise en cache et vous pouvez bénéficier de ces deux fonctionnalités dont nous venons de parler.
Regroupement de données et recherche de données
Ainsi, une fois que vous gardez le cache à jour et que vous effectuez également l'écriture directe, vous commencez maintenant à mettre en cache beaucoup de données. Ainsi, le cache n'est plus seulement un magasin de valeurs clés. Je veux dire que ce n'est pas pratique de tout récupérer comme une clé.
Il faut savoir chercher. Vous devez être capable de faire une recherche SQL. Donc, vous devez être capable de faire ce que vous avez l'habitude de faire avec la base de données.
Si un cache ne vous permet pas d'effectuer des recherches SQL, cela devient très limitant et de la même manière, car vous ne pouvez pas effectuer de jointures dans un cache car il s'agit d'un cache distribué. Il existe d'autres fonctionnalités de regroupement et de sous-groupement et de balises qui vous permettent de grouper des données et récupérez tout en un seul appel.
Encore une fois, il est très important de faciliter la recherche de données dans le cache si vous souhaitez mettre en cache beaucoup de données. Ces fonctionnalités sont donc très importantes.
Fonctionnalités de cache distribué
Je vais juste passer rapidement en revue quelques-unes, une fonctionnalité que je voulais vraiment aborder s'appelle cache proche ou cache client.
Dès que les personnes qui ont l'habitude de faire du cache InProc autonome, lorsqu'elles passent à un cache distribué, leurs performances chutent soudainement parce qu'elles traversent le réseau. Ils doivent passer par la sérialisation et du coup les performances ne sont plus rapides. Beaucoup de nos clients se plaignent, eh bien, je m'attendais à ce que mes performances augmentent, elles ont en fait chuté. Et la raison en est que vous ne pouvez pas rivaliser avec le cache InProc autonome qui contient l'objet stocké sur votre tas. Donc, si vous avez une fonctionnalité de cache client qui est essentiellement exactement un cache local qui garde cet objet local mais il est connecté au cache en cluster.
Encore une fois, c'est une caractéristique qui NCache a et la plupart des caches Java ont qui vous donneront vraiment les mêmes performances rapides sans perdre la chose.
Pour NCache, vous pouvez aller sur notre site Web et le télécharger est un cache open source. Ainsi, vous pouvez télécharger le cache open source ou l'Enterprise Edition et, comme je l'ai dit, vous pouvez obtenir toutes les comparaisons entre NCache ainsi que Redis sur ça.