Was ist die beste Lösung für die Speicherung von ASP.NET-Sitzungsvariablen? StateServer oder SQLServer?

Question

StateServer oder SQLServer?

• Was ist die beste Lösung für die Speicherung von ASP.NET-Sitzungsvariablen?
• Was sind die Vor- und Nachteile der beiden?
• Ist das eine besser als das andere in einer bestimmten Situation?

Answer 1

Hier sind einige Gedanken zu den Vor- und Nachteilen. Ich habe auch die Lösung Microsoft Velocity Distributed Caching hinzugefügt.

Vorteile für InProc

• Schnellste verfügbare Option (alles im Speicher/RAM)
• Einfach einzurichten (nichts Neues in der .config-Datei erforderlich .. ich denke, dies ist das Standardverhalten).
• Ich glaube, die meisten Leute benutzen das.

Nachteile für InProc

• Wenn die Website (Anwendungspool) stirbt, gehen alle Sitzungsinformationen verloren.
• Funktioniert nicht in einem WebFarm-Szenario -> Sitzungsinformationen sind nur pro App-Pool.
• Kann keine Nicht-Sitzungsinformationen enthalten.

Pro's für einen StateServer

• Im Speicher/RAM, also schnell (hat aber eine gewisse Netto-Latenzzeit siehe unten), also vielleicht nicht so schnell wie Inproc.
• Standardkonfiguration für ein Webfarm-Szenario. Mehrere iis-Sites verwenden einen Stateserver, um den Status der Sitzungsinformationen zu steuern.

Nachteile für StateServer

• Erfordert, dass der ASP.NET StateServer-Dienst zur Ausführung eingestellt ist.
• StateServer erfordert einige Anpassungen in der Konfiguration, um 'remote iis machine'-Anfragen zu akzeptieren.
• Es gibt eine winzig kleine Netzlatenz, wenn die iis-Anfrage die Sitzungsinformationen auf einem anderen vernetzten Rechner abrufen/einstellen muss.
• Kann keine Nicht-Sitzungsinformationen enthalten.

Pro's für SqlServer (als State Server)

• Der Status bleibt immer erhalten, auch nach einem Neustart der iis-Site.

Nachteile von SqlServer (als State Server)

• Langsamste Lösung -> Netzlatenz UND Festplattenlatenz (da der Sql-Server den Status auf der Festplatte speichert / von der Festplatte liest).
• Am schwierigsten einzurichten/zu konfigurieren.
• Kann keine Nicht-Sitzungsinformationen enthalten

Vorteile von Velocity (oder anderen verteilten Caching-Systemen)

• Kann mehr als nur Sitzungsinformationen verarbeiten -> Objekte, Anwendungseinstellungen, Cache, etc. (Das ist IMO eine sehr GUTE Sache!!)
• Kann nur im Speicher sein oder in einer Datenbank gespeichert werden.
• Wenn ein "Knoten" ausfällt, funktioniert das System immer noch. (vorausgesetzt, es gibt 2+ Caching-Knoten)

Nachteile von Velocity (oder anderen verteilten Caching-Systemen)

• Kosten in der Regel $$$
• Am schwierigsten einzurichten (man muss Dinge installieren, Konfigurationen anpassen, zusätzlichen speziellen Code hinzufügen).
• Hat eine Netzwerklatenz (die im Allgemeinen nichts ausmacht), kann aber eine Festplattenlatenz haben, wenn der Dienst die Daten persistiert (z. B. auf einem SQL-Server).

Answer 2

Ich gehe davon aus, dass Sie eine Art von Webfarm verwenden.

Ein Beispiel für einen State Service ist ein Web Garden (mehrere Worker-Prozesse auf demselben Rechner). In diesem Fall können Sie die Lastverteilung nutzen, um die Verbindung eines Benutzers zu einem bestimmten Server aufrechtzuerhalten, und die n Worker-Prozesse müssen sich alle denselben State Service teilen.

EDIT: In der Web-Garten + State Service oder Sql-Server-Szenario, haben Sie auch den Vorteil, in der Lage, die Worker-Prozesse auf dieser Maschine ohne die verbundenen Clients verlieren ihre Sitzung zu recyceln.

Ich bin nicht so vertraut mit der Verwendung von SQL Server als Sitzungszustandsspeicher, aber ich würde denken, dass Sie durch die Verwendung eines SQL Servers in einem Cluster an Robustheit gewinnen würden. In diesem Fall könnten Sie immer noch mehrere Arbeitsprozesse und mehrere Server haben, aber Sie müssten keine sticky session (Serveraffinität) verwenden.

Und noch ein Hinweis: Sie können den Statusdienst auf einem zweiten Rechner verwenden und alle Server in der Farm auf diesen Rechner zugreifen lassen, aber Sie hätten dann einen Single Point of Failure.

Und schließlich gibt es verteilte zustandsdienstähnliche Anwendungen von Drittanbietern (und einige selbstentwickelte). Einige von ihnen haben Leistungsvorteile gegenüber den anderen Optionen, und das Ereignis Session_End wird tatsächlich ausgelöst. (Sowohl beim State Service als auch bei der SQL Server-Sitzungsunterstützung wird das Session_End-Ereignis in Global.asax nicht ausgelöst (vielleicht gibt es eine Möglichkeit, sich in SQL Server einzuklinken)).

Answer 3

In einer n-Tier-Umgebung, in der der Sitzungsstatus von SQL Server gehostet wird, erzeugen Sie zusätzlichen Netzwerkverkehr zu Ihrem Backend und verlieren einige SQL Server-Ressourcen, die sich nun um diesen zusätzlichen Verkehr (sitzungsbezogene Anfragen) kümmern müssen. Die SQL Server-Zustandsverwaltung ist auch langsamer als der State Server.

Sollten Ihre Server jedoch bei einem unvorhergesehenen Zwischenfall ausfallen, wird SQL Server höchstwahrscheinlich die Sitzungsinformationen beibehalten, im Gegensatz zu einem State Server.

Answer 4

Nach meiner persönlichen Erfahrung hatte ich einige Probleme beim Speichern von Sitzungsvariablen. Ich verlor immer wieder die Sitzung und ich glaube, es war das Anti-Virus, das, während es jede Datei auf dem Server scannte, IIS die Site neu kompilierte und die Sitzungen tötete. (Ich muss sagen, dass ich keine Macht über diesen Server hatte, mir wurde gesagt, dass ich die Anwendung dort hosten sollte)
Also beschloss ich, die Sitzung im SQL Server zu speichern, und jetzt sind alle zufrieden... es geht unglaublich schnell

Werfen Sie einen Blick auf dieser Artikel für einen schnellen Start

Answer 5

Die Verwendung eines einzigen Rechners für die Speicherung des Zustands in einem Webgarten bedeutet eine einzige Fehlerquelle. Wir verwenden SQL-Status, aber das bedeutet einen gewissen Mehraufwand.