Daran besteht absolut kein Zweifel. ASP.NET ist in die Jahre gekommen und ein Großteil der ASP.NET-Anwendungen weist mittlerweile einen hohen Datenverkehr auf und ist geschäftskritisch. Das bedeutet, dass Sie sich keine ungeplanten Ausfallzeiten der gesamten Website oder einiger Server leisten können, bei denen viele Benutzer ausfallen. Dies liegt daran, dass diese Ausfallzeiten Sie teuer in Form von Umsatzeinbußen und einem schlechten Ruf kosten, der schwer zu beheben ist.
Wenn die Speicherung des ASP.NET-Sitzungsstatus nicht ordnungsgemäß gehandhabt wird, kann dies zu ungeplanten Ausfallzeiten führen. Microsoft bietet vier Speicheroptionen für den ASP.NET-Sitzungsstatus:
- InProc: Sitzungen bleiben im Arbeitsprozess
- StateServer: Sitzung wird in einem separaten Prozess gehalten
- SQL Server: Sitzung wird in SQL Server beibehalten
- Benutzerdefiniert: Die Sitzung wird in einem benutzerdefinierten Store eines Drittanbieters gespeichert
Beide InProc und StateServer sind nicht in der Lage, den ASP.NET-Sitzungsstatus auf mehr als einen Server zu replizieren und verursachen daher Datenverlust, wenn ein Webserver ausfällt. In der Tat, wenn Sie eine Single haben StateServer für die gesamte Website und sie fällt aus, Sie sind völlig fertig, weil Ihre gesamte Website ausfallen wird.
SQL Server ist die dritte Speicheroption für den ASP.NET-Sitzungsstatus und bietet Serverredundanz und Datenreplikation, da Sie einen Datenbankcluster erstellen können, entweder gespiegelt oder mit Lastausgleich.
Allerdings ist die Einrichtung von SQL Server-Clustern teuer und es stehen günstigere und praktikablere Alternativen zur Verfügung. Darüber hinaus wurde SQL Server (wie alle relationalen Datenbanken) für die Speicherung strukturierter relationaler Daten und nicht für BLOBs entwickelt. wohingegen der ASP.NET-Sitzungsstatus in SQL Server als BLOBs gespeichert wird. Daher ist der Zugriff auf die Sitzungen nicht nur langsam, sondern die Datenbank wird auch schnell zu einem Engpass, wenn Sie versuchen, Ihre Anwendung zu skalieren.
Eine wesentlich bessere Alternative zu all dem ist die Verwendung der benutzerdefinierten Speicheroption von ASP.NET-Sitzungsstatus und verwenden Sie einen verteilten In-Memory-Cache (NCache) als Ihren ASP.NET-Sitzungsstatusspeicher. NCache repliziert Sitzungen auf mehreren Servern, sodass beim Ausfall eines Servers keine Sitzungsdaten verloren gehen. NCache Der Zugriff ist auch viel schneller als auf SQL Server, da es sich um einen speicherinternen Server handelt. Endlich, NCache ermöglicht Ihnen die einfache Skalierung des Cache-Clusters, wenn die Größe Ihrer Webfarm wächst. Fügen Sie dem Cluster einfach weitere Cache-Server hinzu, damit es nie zu Engpässen kommt.
Und das Beste daran ist, dass für die Nutzung keine Programmierung erforderlich ist NCache für die Speicherung des ASP.NET-Sitzungsstatus. Ändern Sie einfach Ihre web.config, um Folgendes anzugeben:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<assemblies> <add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.4.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </assemblies> <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="NCacheTest" enableLogs="false" cacheName="myReplicatedCache"/> </providers> </sessionState> |
Wenn Sie eine ASP.NET-Anwendung in einer Webfarm ausführen, werfen Sie einen Blick darauf NCache und sehen Sie, wie es Ihren ASP.NET-Sitzungsstatusspeicher verbessert. Hier sind einige nützliche Links für NCache:
Sie können mit mindestens zwei dedizierten Servern in einem Cache-Cluster beginnen, um eine hohe Verfügbarkeit und Zuverlässigkeit zu gewährleisten. Anschließend wird empfohlen, ein Verhältnis von 4:1 zwischen Ihren Web-/App-Servern und Cache-Servern beizubehalten, um eine optimale Leistung und Skalierbarkeit für Ihre Anwendungen zu erzielen .