Orlando Code Camp 2019

ASP optimieren.NET Core Leistung mit verteiltem Cache

Von Iqbal Khan
Präsident & Technologie-Evangelist

ASP.NET Core wird immer beliebter für die Entwicklung von stark frequentierten Webanwendungen. Erfahren Sie, wie Sie ASP optimieren.NET Core Leistung für die Verarbeitung extremer Transaktionslasten ohne Verlangsamung durch Verwendung eines verteilten Open Source .NET-Cache. Dieser Vortrag umfasst:

Schneller Überblick über ASP.NET Core Leistungsengpässe
Überblick über das verteilte Caching und wie es Leistungsprobleme löst
Wo können Sie verteiltes Caching in Ihren Anwendungen verwenden?
Einige wichtige verteilte Cache-Funktionen
Praktische Beispiele mit Open Source NCache als verteilter Cache

Ich werde das Thema durchgehen, wie Sie ASP optimieren können.NET core Leistung und ich werde verteiltes Caching als Technik verwenden, um diese Verbesserungen vorzunehmen, und ich werde es verwenden NCache wie das Beispiel hier.

ASP.NET Core Beliebt (stark frequentierte Apps)

Wir alle kennen das ASP.NET core ist das neue .NET core, die saubere, leichte Architektur, die plattformübergreifende und offene Quelle – und das wird zu einem Hauptgrund, warum immer mehr Menschen auf ASP umsteigen.NET core.

Außerdem gibt es eine große Anzahl älterer ASP.NET-Benutzer, und insbesondere wenn Sie eine ASP.NET MVC-Anwendung verwenden, sollten Sie auf ASP umsteigen.NET core ist ziemlich einfach. Wenn Sie kein MVC sind, müssen Sie natürlich viel Code schreiben. All das sind die Gründe, warum Sie sicher auch wegen ASP hier sind.NET core ist die führende .NET-Wahl für die Erstellung von Webanwendungen.

ASP.NET Core Benötigt Skalierbarkeit

Also, wenn Sie ASP haben.NET core wird immer häufiger in Situationen mit hohem Verkehrsaufkommen eingesetzt. Hoher Datenverkehr bedeutet normalerweise, dass Sie eine kundenorientierte Anwendung haben. Sie können ein Online-Unternehmen sein, Sie können ein Einzelhandelsunternehmen sein. Es gibt eine Vielzahl von Branchen, Gesundheitswesen, E-Government, soziale Medien, Online-Wetten, Glücksspiel, alles, was Sie sich vorstellen können. Jeder ist heutzutage online. Also, irgendjemand! Wenn es einen Webanwendungs-ASP gibt.NET core verwendet wird, bedeutet das ASP.NET core muss skalierbar sein.

Was ist Skalierbarkeit?

Was bedeutet das? Lassen Sie mich das kurz definieren, ich bin sicher, Sie wissen eine Menge davon, aber der Vollständigkeit halber werde ich nur die Terminologie definieren.

Skalierbarkeit bedeutet also: Wenn Sie eine Anwendung haben, die bei fünf Benutzern eine wirklich gute Reaktionszeit hat, klicken Sie darauf und innerhalb von ein oder zwei Sekunden wird die Seite wieder angezeigt. Wenn Sie dann die gleiche Reaktionszeit mit fünftausend, fünfzigtausend oder fünfhunderttausend Benutzern erreichen können, ist Ihre Anwendung skalierbar. Wenn Sie das nicht können, sind Sie nicht skalierbar. Wenn Sie mit fünf Benutzern keine hohe Leistung erzielen, müssen Sie andere Diskussionen darüber führen, wie Sie Ihren Code geschrieben haben. Ich gehe jedoch davon aus, dass Ihre Anwendung mit guten Algorithmen und einem guten Ansatz entwickelt wurde und dass es sich um eine Hochleistungsanwendung mit fünf Benutzern handelt. Wie sorgt man also für eine hohe Leistung bei Spitzenlast?

Was ist lineare Skalierbarkeit?

Wenn Sie also von fünf über fünftausend auf fünfzigtausend gehen können, spricht man von linearer Skalierbarkeit.

Und die Art und Weise, wie Sie dies erreichen, ist, wie Sie in einer Umgebung mit Lastausgleich wissen, die Bereitstellung von ASP.NET core Sie erweitern Ihre Anwendung mit einem Load Balancer und fügen immer mehr Server hinzu. Wenn Sie also weitere Server hinzufügen, erhöht sich Ihre Transaktionskapazität und Ihre Kapazität für die Anzahl der Anfragen pro Sekunde linear. Wenn Sie das erreichen können, werden Sie auch die gleiche Leistung erbringen können. Und das ist das Ziel des heutigen Vortrags, dass wir diese Höchstleistung auch unter Spitzenlast erreichen wollen. Wenn Sie also unter Spitzenlast keine hohe Leistung haben, wenn Sie keine lineare Anwendung haben, bedeutet das, dass es irgendwo Engpässe gibt. Sobald Sie also einen bestimmten Schwellenwert überschreiten, spielt es keine Rolle, ob Sie weitere Felder hinzufügen. Tatsächlich wird es die Dinge wahrscheinlich verlangsamen, weil es irgendwo einen Engpass gibt, der Ihre Anwendung verhindert. Sie möchten also auf keinen Fall eine nichtlineare Skalierbarkeit aufweisen.

Welche Apps benötigen Skalierbarkeit?

Um es noch einmal zusammenzufassen: Welche Arten von Anwendungen müssen skalierbar sein?

Offensichtlich ASP.NET core worüber wir reden. Möglicherweise verfügen Sie auch über Webdienste, was bedeutet, dass ASP.NET-Apps die Web-Apps sind, was bedeutet, dass ihre Benutzer Menschen sind. Webdienste sind wiederum Web-Apps. Ihre Benutzer sind andere Apps. Microservices sind ein relativ neues Konzept, das auch für serverseitige Anwendungen gilt. Dazu gehört natürlich auch die Neuarchitektur Ihrer gesamten Anwendung. Ich werde nicht näher darauf eingehen, wie Sie das machen. Ich erwähne nur die Typenanwendung, damit Sie abbilden können, was auch immer Sie tun oder was Ihr Unternehmen tut, ob es darauf abgebildet wird oder nicht. Und schließlich noch viele allgemeine Serveranwendungen. Diese Serveranwendungen führen möglicherweise eine Stapelverarbeitung durch. Wenn Sie beispielsweise ein großes Unternehmen oder eine Bank sind, müssen Sie möglicherweise viele Dinge im Hintergrund in einem Batch-Modus, einem Workflow-Modus und das sind die Server-Apps, verarbeiten.

Das Skalierbarkeitsproblem und die Lösung

Daher müssen alle diese unterschiedlichen Arten von Anwendungen mit Skalierbarkeit umgehen können, was bedeutet, dass sie in der Lage sein müssen, alle steigenden Transaktionslasten ohne Verlangsamung zu verarbeiten. Es liegt also offensichtlich ein Skalierbarkeitsproblem vor, sonst würden wir dieses Gespräch nicht führen. Wenn alles in Ordnung war, ist die gute Nachricht, dass nicht Ihre Anwendungsebene, sondern Ihr ASP das Problem ist.NET core Die Anwendung ist nicht das Problem, es ist die Datenspeicherung. Welche Daten Sie auch immer berühren, es spielt keine Rolle, sie verursachen einen Leistungsengpass. Und das sind Ihre relationalen Datenbanken, Ihre Mainframe-Altdaten und eine Reihe anderer Daten. Interessant, NoSQL databases sind nicht immer die Antwort, denn in vielen Situationen ist man dazu nicht in der Lage ... weil NoSQL database fordert Sie auf, Ihre relationale Datenbank aufzugeben und zu einer neuen SQL-Datenbank zu wechseln NoSQL database was Ihnen aus verschiedenen technischen und nichttechnischen Gründen nicht möglich ist. Und wenn Sie nicht in der Lage sind, zu einem zu wechseln NoSQL database, was nützt es? Rechts?

Mein Fokus liegt also darauf, dass Sie dieses Problem mit der relationalen Datenbank im Bild lösen müssen, denn das ist die Datenbank, die Sie, wie gesagt, aus verschiedenen Gründen verwenden müssen. Und wenn Sie nicht in der Lage sind, sich davon zu lösen, dann NoSQL databases sind in vielen Situationen nicht die Antwort.

Verteilte Cache-Bereitstellung

Daher sollten Sie weiterhin eine relationale Datenbank verwenden und stattdessen einen verteilten Cache in Ihrer Anwendung bereitstellen.

So sieht es aus. Wenn Sie also sehen, dass Sie über die gleiche Anwendungsebene verfügen, können Sie ihr immer mehr Server hinzufügen, wenn Ihre Transaktionslast wächst. Bei vielen davon, beispielsweise bei Webanwendungen und Webdiensten, handelt es sich in der Regel um einen darüber liegenden Load Balancer, der sicherstellt, dass jeder Webserver die gleiche Last von den Benutzern erhält. Bei Serveranwendungen gibt es möglicherweise nicht viel Balancer, das hängt jedoch von der Art der Anwendung ab. Tatsache ist jedoch, dass Sie immer mehr Server hinzufügen können und es hier nur eine Datenbank gibt. Und wie gesagt, vielleicht gibt es welche NoSQL database für einige kleinere Spezialdaten, aber der Großteil der Daten ist immer noch relational. Das Ziel besteht also darin, eine Caching-Ebene dazwischen zu platzieren, und ein verteilter Cache ist im Wesentlichen ein Cluster aus zwei oder mehr Servern, und diese Server sind kostengünstige Server. Dabei handelt es sich nicht um High-End-Datenbankserver, und alles wird im Speicher gespeichert.

Warum in Erinnerung? Denn der Speicher ist einfach viel schneller als die Festplatte. Wenn Ihre Anwendung immer mehr leisten muss, müssen Sie sich darüber absolut im Klaren sein. Eine Festplatte, egal ob SSD oder HDD, wird Sie umbringen. Man muss in die Erinnerung gehen. Alles muss im Speicher abgelegt werden, sonst erreichen Sie nicht die gewünschte Leistung. Und zwar unabhängig davon, ob Sie einen verteilten Cache nutzen oder nicht, aber im Arbeitsspeicher ist dies der Speicher. Ein verteilter Cache verfügt also über zwei oder mehr Server. Es bildet einen Cluster und das Wort Cluster bedeutet, dass jeder Server den anderen Server im Cluster kennt und die Ressourcen, den Speicher, die CPU und die Netzwerkkarte gebündelt hat. Das sind also die drei Ressourcen, die es zu einer logischen Kapazität zusammenfasst.

Speicher, da jeder Server über RAM verfügt. Eine typische Konfiguration, die wir bei unseren Kunden gesehen haben, liegt zwischen 16 und 32 GB RAM und jedem Cache-Server. Wir empfehlen einen Mindestwert von 16, zwischen 16 und 32. Und dann, anstatt über 32 zu gehen, sagen wir 64 oder 128 GB RAM in jeder Box, was dann eine Erhöhung der CPU-Kapazität erfordert, denn je mehr Speicher Sie haben Sie müssen mehr Müll sammeln. Da .NET GC verwendet, bedeutet mehr Garbage Collection mehr CPU, andernfalls wird die Garbage Collection zum Engpass. Es ist also besser, eine Reichweite von 16 bis 32 zu haben und nicht größer und einfach mehr Boxen zu haben, als 128 GB mit zwei Boxen. Dafür ist also die Erinnerung da.

Die CPU ist offensichtlich das Zweite. Auch hier handelt es sich bei der typischen Konfiguration um eine Box mit etwa 8 Kernen. Einige der High-End-Bereitstellungen würden etwa 16 Kerne verwenden, aber 8 Kerne pro Box reichen aus. Wie gesagt, kostengünstige Server. Und natürlich die Netzwerkkarte, denn alle Daten, die von hier nach hier gesendet werden, werden über die Netzwerkkarten gesendet. Auf der Anwendungsebene gibt es nun offensichtlich mehr Anwendungsserver als Cache-Server. Und auch hier empfehlen wir normalerweise ein Verhältnis von etwa vier zu eins oder fünf zu eins. Fünf Anwendungsserver zu einem Cache-Server mit mindestens zwei Cache-Servern. Wenn Sie hier also fünf Anwendungsserver haben, haben diese fünf Netzwerkkarten und sie senden Daten an Netzwerkkarten im Verhältnis fünf zu eins.

Als Netzwerkkarte müssen also mindestens eine Gigabit- oder 10-Gigabit-Netzwerkkarte in den Cache-Servern vorhanden sein. Abgesehen davon müssen Sie sie nur zusammenfügen. Nehmen wir an, Sie beginnen mit mindestens zwei, und wenn Sie das Maximum von zwei erreicht haben, müssen Sie es weiterleiten und Ihre Anwendung ausführen. Alles wird superschnell laufen, oder vielleicht führen Sie gerade Lasttests durch. Alles wird superschnell laufen und die Last erhöht sich. Plötzlich wird auf der Serverseite eine höhere CPU-Leistung und ein höherer Speicherverbrauch festgestellt, und die Antwortzeit wird sich verlangsamen. Das wird nun mit der relationalen Datenbank passieren, außer dass Sie hier eine dritte Box hinzufügen können und plötzlich eine weitere große Erleichterung verspüren und jetzt mit einem wieder höheren Durchsatz beginnen und jetzt mehr und mehr Transaktionen hinzufügen können, wird der Höhepunkt erreicht sein raus und dann fügst du ein viertes Kästchen hinzu, weißt du?

Auf diese Weise nimmt dieses Bild weiter zu, und dies wird nie zu einem Engpass, und Sag niemals nie, aber fast nie wird es zu einem Engpass, weil Sie immer mehr Server hinzufügen können. Und wenn Sie hier weitere Server hinzufügen, fügen Sie einfach mehr in diesem Cache hinzu, was mit der Datenbank nicht möglich ist. Jetzt habe ich 8020 geladen. In Wirklichkeit gehen eher 90 % des Datenverkehrs in den Cache und 10 % in die Datenbank, da immer mehr Daten einfach aus dem Cache gelesen werden. Ich werde einige andere Aspekte davon durchgehen, die ein Cache bewältigen muss, aber das ist im Grunde nur ein Bild, das ist der Grund, warum Sie einen verteilten Cache benötigen.

Verwenden des verteilten Caches

Okay! Also, lasst uns weitermachen. Jetzt habe ich Sie hoffentlich davon überzeugt, dass Sie eine integrieren müssen verteilter Cache Die erste Frage, die mir in Ihrer Bewerbung in den Sinn kommt, ist: Was mache ich damit? Wie benutze ich es? Es gibt also drei Hauptkategorien, in denen Sie einen verteilten Cache verwenden können.

Es gibt noch andere, aber für den Großteil der Diskussion sind die drei wirklich hochrangig.

App-Daten-Caching

Nummer eins ist das Zwischenspeichern von Anwendungsdaten. Darüber habe ich bisher gesprochen. Welche Daten sich auch immer in der Datenbank befinden, das nenne ich Anwendungsdaten. Sie werden zwischengespeichert, damit Sie nicht in die Datenbank gelangen. Bedenken Sie nun, dass bei jedem dieser Punkte das Problem beim Zwischenspeichern von Anwendungsdaten darin besteht, dass die Daten an zwei Orten vorhanden sind. den Cache und die Datenbank. Und wenn Daten an zwei Orten vorhanden sind, was kann dann schief gehen? Nicht mehr synchronisiert! Ja! Daher könnten die Daten nicht mehr synchron sein. Wenn also Ihre Daten und der Cache nicht mit der Datenbank synchronisiert sind, kann das zu vielen Problemen führen. Ich könnte zweimal eine Million Dollar abheben, wenn ich davon ausgehen müsste, aber sagen wir mal so... Das ist das erste Problem, das mir in den Sinn kommt.

Jeder Cache, jeder verteilte Cache, der dieses Problem nicht bewältigen kann, bedeutet, dass Sie auf schreibgeschützte Daten beschränkt sind. Sondern das, was wir Referenzdaten nennen. Und so begann das Caching, also das Zwischenspeichern schreibgeschützter Daten in meinen Nachschlagetabellen. Die Nachschlagetabelle umfasst etwa 10 % Ihrer Daten. Bei einigen Anwendungen handelt es sich nicht um eine durchschnittliche Anwendung. 90 % Ihrer Daten sind keine Suchdaten. Es handelt sich um Transaktionsdaten. Es sind Ihre Kunden, Ihre Aktivitäten, Ihre Bestellungen, alles. Wenn Sie also nicht in der Lage sind, alle diese Daten zwischenzuspeichern, besteht der Vorteil, sagen wir, 10 % der Daten darin, dass die Suche möglicherweise tatsächlich zu mehr als ihrem angemessenen Anteil durchgeführt wird. Diese 10 % könnten Ihnen also den Vorteil von 30 % verschaffen, aber Sie haben immer noch 70 % der Daten, die Sie in die Datenbank übertragen müssen. Aber wenn Sie alle Daten zwischenspeichern könnten, was nur möglich wäre, wenn Sie diesen Komfort hätten, dann würden Sie den echten Nutzen daraus ziehen.

ASP.NET Core Spezifisches Caching

Der zweite Anwendungsfall oder die zweite Art der Nutzung ist das, was ich ASP nenne.NET core spezifisches Caching und es gibt drei Möglichkeiten. Eine davon sind die Sitzungen, die am häufigsten verstanden werden. ASP.NET hatte sie ASP.NET core hat sie. Sie sind hier, um zu bleiben. Ich glaube nicht, dass Sitzungen verschwinden werden, auch wenn einige Leute argumentieren, dass wir keine Sitzungen verwenden sollten. Es ist nicht schädlich, wenn Sie sie verwenden. Das einzige Problem dabei ist, wo man sie lagert. Das war immer das Problem mit ASP.NET. Welche Speicheroptionen Microsoft Ihnen auch gegeben hat, sie waren alle voller Probleme. Daher bestand die einzige Option zu diesem Zeitpunkt darin, einen verteilten Cache zu verwenden, den man in den ASP.NET-Tagen glücklicherweise als benutzerdefinierte Option integrieren konnte. Im ASP.NET core, Microsoft hat kein eingebautes oder sie haben ein Image wie ein eigenständiges In-Memory, aber sie gehen sofort in eines über IDistributedCache oder ein benutzerdefinierter Sitzungsanbieter, den Sie beispielsweise in einen verteilten Cache eines Drittanbieters einbinden können NCache.

Sitzungen sind das erste, das zweite ist das Antwort-Caching. Ich wollte sagen, wer kennt sich nicht mit Antwort-Caching aus, aber das ist keine gute Art zu fragen. Das Antwort-Caching ähnelt einer neueren Version des Ausgabecaches, basiert jedoch stärker auf Standards. Es ist die Seitenausgabe, die Sie zwischenspeichern können, und ich werde darauf näher eingehen, aber das ist auch etwas, das Sie zwischenspeichern und einen verteilten Cache als Middleware dafür anschließen können.

Und drittens, wenn Sie ein Signal oder eine Anwendung haben, bei der es sich um die Live-Web-App handelt. Live-Web-Apps sind Apps, bei denen Sie beispielsweise über eine Aktienhandelsanwendung verfügen, die ständig alle Aktienkursänderungen weitergeben muss und Hunderttausende Kunden hat. Sie sind alle miteinander verbunden, sodass sie alle mit dem Caching oder den Anwendungsebenen verbunden bleiben. Es ist anders als beim regulären HTTP, bei dem für jede Webanfrage eine neue Socket-Verbindung geöffnet wird. Hier bleibt die Socket-Verbindung geöffnet und Ereignisse werden vom Server weitergegeben. Wenn Sie also in einem SignalR eine höhere Transaktion und eine große Anzahl von Benutzern haben, müssen Sie über ein Webformular mit Lastenausgleich verfügen. Da die Sockets jedoch offen bleiben, kommuniziert jeder Server mit seinem eigenen Client, aber jetzt ist alles so Clients oder alle Server verfügen über unterschiedliche Clientgruppen, sodass sie Daten gemeinsam nutzen müssen. Diese Daten werden also über eine Rückwandplatine gemeinsam genutzt und diese Rückwandplatine wird ... Dort schließen Sie also einen verteilten Cache an. Ich werde nicht auf die Details dieser Besonderheit eingehen. Ich werde die ersten beiden durchgehen, aber nicht den dritten.

Nun zum Besonderen an ASP.NET core Spezifisches Caching besteht darin, dass die Daten nur im Cache vorhanden sind. Das ist es, was ich gesagt habe: Tragen Sie es nicht in die Datenbank ein. Es ist nicht nötig. Hierbei handelt es sich um temporäre Daten. Sie benötigen es nur für 20 Minuten, 30 Minuten, eine Stunde, 2 Stunden, danach müssen die Daten gelöscht werden. Wenn es also temporär ist, sollte es nur im Cache vorhanden sein. Wenn die Daten nur im Cache vorhanden sind und es sich um einen In-Memory-Cache handelt, was könnte dann schief gehen? Sie könnten Daten verlieren, da sich alles im Speicher befindet. Das Gedächtnis ist flüchtig. Ein guter verteilter Cache muss diese Situation natürlich bewältigen, was bedeutet, dass Sie replizieren müssen.

Pub/Sub-Nachrichten und -Ereignisse

Der dritte Anwendungsfall besteht darin, dass viele Anwendungen Workflow-Vorgänge ausführen müssen. Microservice ist ein sehr gutes Beispiel dafür. Sie müssen Aktivitäten koordinieren, obwohl Microservices nicht das Thema sind, sondern sogar ASP.NET core Anwendungen müssen dies gelegentlich tun. Also, Pub/Sub-Messaging ist eine andere Möglichkeit, denn Sie haben – auch hier sollten Sie bedenken – eine Infrastruktur, in der alle diese Boxen mit dieser redundanten In-Memory-Infrastruktur verbunden sind. Warum also nicht auch für Pub/Sub-Nachrichten verwenden?

Das sind also die drei häufigsten Anwendungsfälle. Dies sind also die drei Möglichkeiten, die Sie verwenden sollten NCache oder ein verteilter Cache, wenn Sie davon profitieren möchten, wenn Sie den Nutzen maximieren möchten.

Praktische Demo

Bevor ich darauf eingehe, wie Sie sie tatsächlich verwenden, möchte ich Ihnen kurz zeigen, wie ein verteilter Cache aussieht. Ich werde Azure als Umgebung verwenden und verwenden NCache. Und es ist nur eine kurze Demo von ...

Einrichten einer Umgebung

Ich bin also bei Azure angemeldet. Ich habe vier VMs, das sind wiederum alle .NET core.

Ich habe also vier VMs in Azure. Zwei davon werde ich als meine Cache-Server-VMs verwenden, was im Grunde so ist: Das sind diese beiden ... Ich werde einen Windows-Client und einen Linux-Client haben. Also, wenn ja, denn .NET core unterstützt Linux. Wenn Sie haben .NET core Als Anwendung möchten Sie diese möglicherweise unter Linux bereitstellen. Nun, im Falle von NCacheAuch hier betreibe ich kein Marketing NCache. Aber im Falle von NCache, es ist .NET core Es kann also sowohl auf den Servern als auch auf den Clients unter Windows oder Linux ausgeführt werden.

Okay! Lassen Sie uns auf Folgendes eingehen: Ich bin also bei diesem Client angemeldet, der Windows-Client-Box. Also werde ich jetzt loslegen und einen Cache für mich selbst erstellen.

Erstellen Sie einen geclusterten Cache

Also werde ich dieses Tool namens verwenden NCache, der NCache Manager kommt eigentlich nicht mit Open Source. Es gibt ein Befehlszeilenäquivalent dazu, aber ich bin hier einfach nur faul. Also werde ich es einfach verwenden NCache Manager, aber es ist die gleiche Funktionalität. Die Funktionalität ändert sich nicht, also habe ich es einfach gestartet NCache Manager. Ich werde sagen, einen neuen Cache erstellen. Sie haben gerade einen Cache benannt. Alle Caches sind benannt. Stellen Sie sich das als Verbindungszeichenfolge zur Datenbank vor und wählen Sie dann eine Topologie aus. Ich werde nicht auf die Topologien eingehen, werde aber gegen Ende darauf eingehen, was ein Cache tun muss, um alle diese Anforderungen erfüllen zu können. Daher werde ich einfach die Partitionsreplikat-Cache-Topologie verwenden. Asynchrone Replikation. Ich werde meinen ersten Cache-Server hinzufügen. 10.0.0.4 und der zweite 5. Ich habe also zwei Cache-Server. Ich werde alles als Standard beibehalten. Ich gehe zu Räumungen und all den anderen.

Und ich werde jetzt zwei Clients angeben. 10.0.0.6 und 7. Ich komme hierher und starte einfach den Cache. Stellen Sie sich das also wie eine Datenbank vor: Anstelle eines Servers haben Sie mehrere Server, die den Cluster bilden. Sie erstellen einen Cluster aus Cache-Servern und weisen dann Clients zu. Sie müssen die Clients nicht zuweisen, da Sie sie einfach ausführen können, aber ich mache es hier, weil es Ihnen mehr Flexibilität gibt.

Stress simulieren und Cache-Statistiken überwachen

Dann möchte ich den Client testen. Ich bin also der Kunde. Ich glaube, ich bin 10.0.0.6. Lassen Sie mich nur sicherstellen, wer ich bin. Ich glaube, ich bin 10.0.0.6, glaube ich. Aufleuchten! Ich mache also noch einmal alles innerhalb des virtuellen Azure-Netzwerks, sodass der Client tatsächlich der Anwendungsserver ist und der Cache jetzt alle zusammen sind. Im Falle von NCache Das hättest du von bekommen können azure marketplace. .6 ist also der Windows-Client. Also starte ich PowerShell und stelle sicher, dass ich etwas sehen kann. Okay! Okay! Sie sehen also, dass dieser Client mit dem Cache kommuniziert und ich jetzt auf jedem Cache-Server etwa XNUMX Anfragen pro Sekunde durchführe. Lassen Sie mich noch etwas Ladung hinzufügen. Ich werde eine weitere PowerShell öffnen und eine weitere Instanz des Clients betonen. Sie werden sehen, dass die Zahl auf über XNUMX bis XNUMX pro Server steigen wird.

Und jetzt lasst es uns tun ... Ich werde tatsächlich ... Also habe ich hier eine Eingabeaufforderung geöffnet. Lassen Sie mich in die Linux-Box einloggen. Hoppla! Und Entschuldigung! Dort starten wir PowerShell. Ich muss die Teilbibliotheken des Klons importieren NCache und ich werde den gleichen Stress-Demo-Cache machen, also werde ich … Bevor ich das mache, wie Sie sehen, mache ich etwa dreizehn bis fünfzehnhundert pro Server, füge dies als Linux-basierten Client hinzu, der mit dem Cache kommuniziert und jetzt habe ich plötzlich fast zweitausendfünfhundert Anfragen pro Server.

Ich verarbeite also etwa fünftausend Anfragen pro Sekunde auf einem Server mit zwei Servern. Wie gesagt, Sie können immer mehr Ladung hinzufügen, und wenn Sie die beiden Boxen voll ausschöpfen, fügen Sie eine dritte und dann eine vierte hinzu. So einfach ist das also, und auch hier handelt es sich um eine Simulation. Es ist eine echte Sache wie ein Stresstest-Tool. Das müssen Sie also im Hinterkopf behalten. Ich werde jetzt mit dem eigentlichen Cache fortfahren. Es ist ein Stresstestprogramm. Es wird einfach wie ein Byte-Array eingefügt. Ich denke, es werden 1 Daten eingegeben. Es fügt hinzu, es aktualisiert, es erhält. Es simuliert also, was auch immer Ihre tatsächliche Anwendung ist, und verfügt über Parameter, die Sie ändern können, um zu sehen, wie hoch das Verhältnis von Lese- und Schreibvorgängen ist, über das wir gesprochen haben. Und das ist ein Werkzeug, mit dem wir geben NCache, sodass Sie es tatsächlich in Ihrer eigenen Umgebung testen können. Also, um zu sehen, wie NCache tatsächlich ausgeführt wird, bevor Sie tatsächlich viel Zeit damit verbringen, Ihre Anwendung dorthin zu migrieren. Lassen Sie mich kurz durchgehen. Ich glaube, ich leite das.

ASP.NET Core Sitzungsspeicher

Nachdem wir nun gesehen haben, wie ein Cache aussieht, wie Sie weitere Clients hinzufügen und ihn stärker auslasten können, ist es ganz einfach. Der einfachste Weg, einen Cache zu verwenden, besteht also darin, Sitzungen darin abzulegen. Und für Sitzungen gibt es zwei Dinge, die Sie tun können.

Entweder können Sie einfach einen IDistributedCache-Anbieter verwenden. Sagen wir NCache hat eins. Sobald Sie es angeben NCache als IDistributeCache, ASP.NET core beginnt, es zur Speicherung von Sitzungen zu verwenden. Und lassen Sie mich Ihnen tatsächlich etwas davon zeigen. Ich habe diesen ASP.NET core Anwendung. Wie Sie hier sehen können. In meinen Konfigurationsdiensten gebe ich Folgendes an, ich sage „make“. NCache mein verteilter Cache-Anbieter. Sobald ich das mache, fängt es an und dann verwende ich Standardsitzungen und diese Standardsitzungen verwenden IDistributedCache, das jetzt verwendet wird NCache. Ganz gleich, welchen Anbieter für verteilten Cache Sie haben, das ist alles, was Sie tun müssen. Wie Sie sehen, werden nur sehr kleine Codeänderungen und Ihre gesamte Anwendung automatisch ausgeführt. Alle Sitzungen werden sofort in einem verteilten Cache abgelegt.

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();	
}

Und eines der Dinge, die wir gesehen haben, ist, dass viele unserer Kunden, wenn sie Sitzungen in der Datenbank speichern und Probleme haben, so etwas anschließen müssen NCache ist augenblicklich und der Nutzen, den sie sehen, ist eine bemerkenswerte Verbesserung augenblicklich. Der geringste Aufwand bringt den maximalen Gewinn. Denn natürlich gibt es auch das Application Direct Caching.

Ich werde ein paar überspringen, weil ich denke … Es gibt also mehrere Möglichkeiten, Sitzungen anzugeben. Einer war der IDistributedCache, der zweite ist, dass Sie tatsächlich einen benutzerdefinierten Sitzungsanbieter verwenden können, der NCache hat auch und wiederum sind alle davon Open Source. Dann machen Sie für das Antwort-Caching erneut dasselbe. Sie bestimmen NCache als verteilter Cache und wird automatisch zum Cache für das Antwort-Caching. Ich werde nicht näher darauf eingehen.

ASP.NET Core App-Daten-Caching

Ich möchte, dass Sie sich etwas näher mit diesem Thema befassen. Wenn Sie also Anwendungsdaten zwischenspeichern, müssen Sie im Gegensatz zu Sitzungen jetzt tatsächlich API-Programmierung durchführen. Es sei denn, Sie machen den Entity-Framework-Kern.

Also z.B. bei NCache, wieder Open Source, es gibt einen EF-Core-Anbieter. Deshalb haben wir Erweiterungsmethoden für EF Core implementiert. Sie können also tatsächlich einstecken NCache open source und verwenden Sie Ihre regulären EF-Kernabfragen und am Ende können Sie aus dem Cache oder aus der Datenbank sagen, so etwas, es ist nur eine Erweiterungsmethode, die automatisch mit dem Zwischenspeichern von Inhalten beginnt. Sie haben die vollständige Kontrolle darüber, was Sie zwischenspeichern möchten und was nicht. Schauen Sie es sich doch mal an. Es ist eine wirklich wirkungsvolle Methode.

Wenn Sie EF Core verwenden, empfehle ich Ihnen dies. Ich denke, für jeden ASP.NET core Für eine Anwendung sollte die gesamte Datenbankprogrammierung über den EF-Kern erfolgen, insbesondere da der EF-Kern eine viel schönere Architektur als der alte EF aufweist. Das ist also eine Möglichkeit, es zu tun.

Das andere ist, dass man diese tatsächlich herstellen kann. Sie können die IDistributedCache-API oder die Schnittstelle verwenden, die Ihnen die Flexibilität bietet, nicht an eine Caching-Lösung gebunden zu sein, aber dies ist mit Kosten verbunden. Es ist sehr einfach. Es gibt nur eine Get-Eingabe und im Grunde gibt es auch eine Remove-Funktion. Das ist alles. Und all die Dinge, über die wir gesprochen haben: Wenn Sie den Cache nicht mit der Datenbank synchronisieren können, gehen all diese Dinge verloren. Wenn Sie also von all diesen Funktionen profitieren möchten, müssen Sie auf die API zugreifen, die all diese Funktionen tatsächlich unterstützt. Und da Sie sich auf einen Open-Source-Cache festlegen, ist dies normalerweise einfacher, aber das direkte Caching der Anwendung und die API sind sehr einfach, es gibt einen Schlüssel und einen Wert. Der Wert ist Ihr Objekt.

Cache frisch halten

Lassen Sie mich nun zu dem Thema kommen, wie Sie den Cache frisch halten können. Die wirklich wertvollen Informationen, oder? Was machst du?

Nun, das Erste, was fast jeder verteilte Cache tut, sind Abläufe! Du machst absoluten Ausdruck. Was auch immer Sie in den Cache legen, Sie sagen, dass Sie es in fünf Minuten aus dem Cache entfernen. Es ist also sicher, es in fünf Minuten aufzubewahren. Ich glaube, in fünf Minuten bin ich der Einzige, der es aktualisiert, nachdem es andere Leute vielleicht getan haben. Also, NCache hat es, alle anderen haben es auch. Vorübergehend … es gibt einen gleitenden Ausdruck für vorübergehende Daten wie Sitzungen und andere, der besagt, dass die Sitzung beendet wird, wenn Sie sie nicht mehr verwenden und eine bestimmte Zeit lang nicht berührt werden, sagen wir Sitzungen, wenn sich der Benutzer nach 20 Minuten Inaktivität abmeldet läuft ab. Es passiert also das Gleiche. Ablauffristen, so ziemlich jeder hat sie.

Als nächstes folgt der synchronisierte Cache mit der Datenbank. Mit dieser Funktion können Sie Ihre Datenbank vom Cache überwachen lassen. Sie können also tatsächlich … wenn Sie Dinge hinzufügen NCacheNehmen wir an, Sie können eine SQL-Abhängigkeit haben, die dies ermöglicht NCache zu überwachen. Bei der SQL-Abhängigkeit handelt es sich um eine SQL-Server-ADO.NET-Funktion, die wir verwenden. Mit der SQL-Abhängigkeit können Sie eine SQL-Anweisung oder Speicherprozedur angeben, die dies zulässt NCache um Ihre SQL Server-Datenbank, diesen spezifischen Datensatz, zu überwachen. Und wenn Änderungen in diesem Datensatz auftreten, benachrichtigt der SQL Server NCache und jeder Cache entfernt diese Daten aus dem Cache, oder wenn Sie diese Synchronisierung mit einer Durchlesefunktion kombinieren, werden sie neu geladen. Nehmen wir also an, Sie hätten ein zwischengespeichertes Kundenobjekt und eine SQL-Abhängigkeit, und dieser Kunde wurde in der Datenbank geändert, bei der es sich um die Transaktionsdaten des Kunden handelt, sodass er sich häufig ändern wird. Sie können „Durchlesen“ und „Automatisches Neuladen“ bei einem Ausdruck oder verwenden Datenbanksynchronisierung.

Nun ist Ihr Cache plötzlich für die Überwachung der Daten verantwortlich. Es gibt drei Möglichkeiten, dies zu tun: SQL-Abhängigkeit, DB-Abhängigkeit und Seal sind gespeicherte CLR-Prozeduren. Ich werde nicht näher darauf eingehen. Sie können auf unsere Website gehen und es lesen. Aber auch hier ist das Wichtigste: Wenn Sie keine Synchronisierung des Caches mit der Datenbank als Funktion haben, sind Sie auf diese schreibgeschützten und statischen Daten beschränkt. Und dann schränkt das das Ganze ein und Sie können diesen Cache auch mit der nicht relationalen Datenquelle synchronisieren.

Und drittens haben Sie vielleicht eine relationale … Meistens werden Sie relationale Daten zwischenspeichern, die Eins-zu-viele-Eins-zu-Eins-Beziehungen haben. Nehmen wir also an, ein Kunde hat mehrere Bestellungen. Wenn Sie den Kunden entfernen, sollten die Bestellungen auch nicht im Cache verbleiben, da Sie ihn möglicherweise aus der Datenbank gelöscht haben. Wenn Sie das also nicht tun, muss Ihre Anwendung all dies tun, aber es gibt ein ASP.NET-Cache-Objekt, das über diese Funktion verfügt, die als Schlüsselabhängigkeitsfunktion bezeichnet wird. NCache hat es implementiert, das es Ihnen ermöglicht, eine Eins-zu-Viele- oder Eins-zu-Eins-Beziehung zwischen mehreren Cache-Elementen herzustellen und dass, wenn ein Element aktualisiert oder entfernt wird, das andere Element automatisch entfernt wird. Durch die Kombination dieser vier Dinge können Sie also sicherstellen, dass Ihr Cache aktuell und konsistent mit der Datenbank bleibt. Und so können Sie dann mit dem Zwischenspeichern von Daten beginnen. Das ist also der erste Vorteil.

Durchlesen und Durchschreiben

Zweitens: Wenn Sie Durchlesen und Durchschreiben verwenden können, vereinfacht dies Ihre Anwendung.

Wie gesagt, Sie können das Durchlesen mit dem automatischen Neuladen kombinieren, was Ihre Anwendung ohne Durchlesen nicht leisten könnte. Und beim erneuten Durchschreiben können Sie den Cache aktualisieren, und der Cache kann die Datenbank aktualisieren, insbesondere wenn Sie ein Recht dahinter haben. Wir reden hier wieder von der Leistung, oder? Daher müssen alle Aktualisierungen an der Datenbank vorgenommen werden. Nun, und die Aktualisierungen werden im Vergleich zu den Lesevorgängen aus dem Cache langsam sein. Was wäre also, wenn Sie die Aktualisierungen an den Cache delegieren und sagen könnten, dass ich den Cache aktualisieren werde? Warum gehen Sie dann nicht hin und aktualisieren die Datenbank für mich? Ich weiß, dass es sicher ist, denn und wir werden am Eventual-Consistency-Modell arbeiten, das ist das, worum es bei verteilten Systemen geht, das man opfert, oder man wird in Bezug auf die Konsistenz nachsichtiger und entscheidet sich für das Eventual-Consistency-Modell. Das heißt, auch wenn es zu diesem Zeitpunkt nicht konsistent ist, weil der Cache aktualisiert wird, wird die Datenbank nicht aktualisiert, und zwar innerhalb weniger Millisekunden. Und bei manchen Daten kann man sich das nicht leisten, bei vielen Daten aber schon.

Wenn Sie also direkt dahinter vorgehen, sind Ihre Aktualisierungen plötzlich auch superschnell, und für Ihre Anwendung müssen keine Kosten für die Aktualisierung der Datenbank anfallen. Der Cache funktioniert, weil es sich um einen verteilten Cache handelt und er diesen als Stapel aufnehmen kann, und es gibt noch andere. Wenn Sie also einmal damit beginnen, bedeutet das, dass Sie jetzt viele Daten zwischenspeichern können.

Datengruppierung

Sobald Sie Daten zwischenspeichern, immer mehr Daten, wird Ihr Cache fast so umfangreich wie eine Datenbank, was bedeutet, dass Sie fast alle Daten zwischenspeichern.

Wenn Sie fast alle Daten zwischenspeichern, reicht der Schlüsselwert nicht aus, um Dinge zu finden. Man muss in der Lage sein, Dinge zu durchsuchen. AppFabric Früher gab es übrigens Gruppen und Untergruppen, Tags namens Tags. NCache open source hat AppFabric Verpackung. Also, diejenigen unter euch, die es bekommen haben AppFabric umziehen kann NCache als eine kostenlose Sache. Durch die Gruppierung können Sie Daten also einfach abrufen.

Daten suchen

Mithilfe der SQL-Suche können Sie Dinge wie „Geben Sie mir alle meine Kunden an, deren Stadt New York ist“ finden. Nun führen Sie Datenbankabfragen im Cache durch. Warum? Weil Ihr Cache nicht viele Daten enthält.

Das gesamte Paradigma ändert sich, weil immer mehr In-Memory-Speicher zur Verfügung stehen. Auch hier ist die Datenbank der Master. Der Cache hat es also immer noch nur für einen vorübergehenden Zeitraum.