ASP.NET ist zur ersten Wahl für Entwickler bei der Entwicklung von Webanwendungen mit hohem Datenverkehr geworden. Aufgrund ihrer Skalierbarkeit kann die ASP.NET-Anwendungsebene nahtlos Tausende von gleichzeitigen Benutzern mit Millionen von Anforderungen pro Tag verarbeiten. Solche ASP.NET-Anwendungen mit hohem Datenverkehr werden in einer Webfarm mit Lastenausgleich mit einem Load Balancer bereitgestellt, der Benutzeranforderungen an mehrere Webserver weiterleitet.
Während die ASP.NET-Anwendungsebene selbst bei hohen Transaktionslasten eine außergewöhnlich gute Leistung erbringt, ist die Anwendung in anderen Bereichen mit einigen kritischen Skalierbarkeitsengpässen konfrontiert. Diese Engpässe können Ihre ASP.NET-Anwendung verlangsamen und sogar anhalten, wenn Ihre Geschäftstätigkeit ihren Höhepunkt erreicht.
Das Problem: Vier Leistungsengpässe
Diese vier ASP.NET-Leistungsengpässe werden im Folgenden beschrieben:
Datenbankengpass
In einer Webfarm mit Lastenausgleich können Sie bei steigender Transaktionslast einfach weitere Webserver hinzufügen, um sie linear zu skalieren. Sie können der Datenbankebene jedoch nicht weitere Datenbankserver (SQL Server, Oracle usw.) auf die gleiche Weise hinzufügen. Die Datenbank wird also langsamer und kann irgendwann sogar abstürzen. Dieser Zusammenbruch ist der kritischste Leistungsengpass, mit dem Ihre Anwendung konfrontiert ist.
ASP.NET-Sitzungsstatus-Speicherengpass
Der ASP.NET-Sitzungsstatus muss irgendwo gespeichert werden, und seine Speicherung wird wie die Anwendungsdatenbank zu einem Engpass. Es gibt drei von Microsoft bereitgestellte Speicheroptionen, nämlich InProc, State Server und SQL Server. Alle drei haben Leistungsengpässe.
InProc zwingt Sie dazu, einen einzelnen Worker-Prozess pro Webserver zu verwenden, was in einer Multiprozessor- oder Multicore-Umgebung nicht funktioniert, wo mehrere Worker-Prozesse bevorzugt werden.
Und in einer Webfarm mit Lastenausgleich ist ein Sticky-Session-Bit auf dem Load Balancer erforderlich, um Benutzeranfragen immer an den Webserver zu senden und die Sitzung zu erstellen, selbst wenn dieser Webserver überlastet ist, während andere im Leerlauf sind.
Außerdem ist SQL Server kein idealer Speicher für den ASP.NET-Sitzungsstatus, da er sie als BLOBs speichert und SQL Server damit nicht gut funktioniert.
NCache Details ASP.NET-Sitzungscaching Dokumente zum ASP.NET-Sitzungscaching
ASP.NET View State Engpass
ASP.NET View State ist eine clientseitige Zustandsverwaltungsfunktion, die auf dem Webserver erstellt wurde, um die Daten von Steuerelementen wie Schaltflächen und Dropdowns zu speichern. Diese Daten werden nur dann an den Browser gesendet, wenn ein Postback auftritt. Und ein ASP.NET View State string kann leicht Hunderte von KB groß sein, multipliziert mit Millionen von Anfragen, die Sie täglich erhalten.
Dies verlangsamt nicht nur die Antwortzeit Ihrer ASP.NET-Anwendung, sondern verbraucht auch viel zusätzliche Bandbreite, was Ihre Betriebskosten erheblich erhöhen kann.
Unnötige Seitenausführung
Häufig ändert sich die ASP.NET-Seitenausgabe über mehrere Anforderungen hinweg nicht, da sich die zugrunde liegenden Daten nicht geändert haben. Die Seite wird jedoch weiterhin ausgeführt, um die gleiche Ausgabe wie beim letzten Mal zu erzeugen. Diese zusätzliche Seitenausführung verbraucht viele Systemressourcen, einschließlich Arbeitsspeicher und CPU, und führt außerdem Datenbankaufrufe durch.
Die Lösung: Verteilter In-Memory-Cache
Die am besten geeignete Lösung für all diese Probleme besteht darin, einen verteilten In-Memory-Cache in Ihr ASP.NET zu integrieren und ASP.Net Core Anwendung. NCache ist ein beliebter verteilter Open-Source-Cache für .NET. Lassen Sie uns schnell besprechen, wie wir unsere vier Leistungsengpässe beheben können NCache.
NCache Details ASP.NET Core Sitzungsspeicherstrategien ASP.NET View State Caching-Eigenschaften und Übersicht
Zwischenspeichern von Anwendungsdaten
NCache ermöglicht es Ihnen, Ihre Anwendungsdaten (sowohl schreibgeschützte Referenzdaten als auch sich häufig ändernde Transaktionsdaten) zwischenzuspeichern, um diese teuren Datenbankreisen zu reduzieren. Anstatt zur Datenbank zu gehen, NCache leitet 85-90 % Ihrer Anfragen an den Cache weiter. Dies schließt die Wahrscheinlichkeit von Datenbankkonflikten aus.
Im Gegensatz zu einer Datenbank NCache wird nie zu einem Engpass, weil es ein ist verteilter Cache und skaliert linear. NCache erstellt einen Cluster von Cache-Servern und ermöglicht es Ihnen, dem Cluster weitere Server hinzuzufügen, wenn Ihre Transaktionslast zunimmt. Im Folgenden finden Sie einen Beispielcode, der die Daten aus der Datenbank abruft und im Cache-Cluster speichert (falls sie nicht bereits im Cache vorhanden sind).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Customer Load(string customerId) { // Key format: Customer:PK:1000 string key = "Customers:CustomerID:" + customerId; Customer cust = (Customer) _cache[key]; if (cust == null) { // Item not in cache so load from db LoadCustomerFromDb(cust); // Add item to cache for future reference _cache.Insert(key, cust); } return cust; } |
Konfiguration des Sitzungsstatusspeichers
NCache können Sie auch Ihre ASP.NET-Sitzungen im Cache speichern. Dies ist ein viel schnellerer In-Memory-Speicher als Ihre anderen Speicheroptionen. Um Verlässlichkeit zu bieten, NCache repliziert Ihre Sitzungen auf mehreren Servern. Wenn also ein Server abstürzt, gehen keine Sitzungsdaten verloren. Das Schöne an ASP.NET Session State Storage in NCache ist, dass es keinen Programmieraufwand gibt und Sie es nahtlos durch eine Änderung der web.config einbinden können. Unten ist ein Beispiel.
1 2 3 4 5 6 7 8 9 |
<configuration> ... <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" |
Statuskonfiguration anzeigen
NCache Hier können Sie Ihre Dateien zwischenspeichern ASP.NET View State auf Seiten des Webservers, indem nur ein Identifikationsschlüssel an den Browser gesendet wird. Beim Zurücksenden in einem Postback, NCache ruft die View-Ergebnisse ab, indem es den Identifikationsschlüssel über seinen HTTP-Handler abfängt. Dieser Ansichtszustand wird dann an Ihre ASP.NET-Seite gesendet.
Das Nettoergebnis ist eine viel schnellere ASP.NET-Anwendung mit einem viel geringeren Bandbreitenbedarf. Nachfolgend finden Sie ein Beispiel für die Verwendung einer Konfigurationsänderung NCache zum Caching ASP.NET View State:
ASP.NET-Ausgabecache
Um die unnötige Ausführung von ASP.NET-Seiten zu verhindern, wenn sich ihre Ausgabe nicht ändert, bietet ASP.NET eine Ausgabe-Cache Framework für Einzelserver- und Einzelarbeitsprozesskonfigurationen. NCache, andererseits erweitert es für Konfigurationen mit mehreren Servern und mehreren Worker-Prozessen.
Durch NCache, können Sie auch damit rechnen, dass Ihre Seiten ablaufen, wenn die zugehörigen Daten in der Datenbank geändert werden. Unten finden Sie ein Beispiel.
Zusammenfassung
Zusamenfassend, NCache an Verteilter In-Memory-Cache mit linearer Skalierbarkeit, einfacher Ansichtszustandskonfiguration und nahtloser Konfiguration mit Ihrer Anwendung ist die beste Lösung für all diese Leistungsengpässe. Diese Funktionen optimieren die Leistung Ihrer .Net-Anwendung und machen sie schneller, zuverlässiger und hochverfügbar.