Was ist die beste Lösung zum Speichern von ASP.NET-Sitzungsvariablen? StateServer oder SQLServer?

Hier sind einige Gedanken über Pro's / Con's. Ich habe auch Microsoft Velocity Distributed Caching-Lösung hinzugefügt.

Vorteile für InProc

• Schnellstes optionales verfügbares (es ist alles im Gedächtnis / RAM)
• Einfach zu installieren (nichts Neues in der .config-Datei erforderlich .. ich denke, das ist das Standardverhalten).
• Die meisten Leute, die ich glaube, benutzen das.

Nachteile für InProc

• Wenn die Website (Anwendungspool) abstirbt, gehen alle Sitzungsinformationen verloren.
• Funktioniert nicht in einem WebFarm-Szenario - & gt; Sitzungsinformationen sind nur für den App-Pool verfügbar.
• Kann keine Nicht-Sitzungsinformationen enthalten.

Pro's für einen StateServer

• In memory / ram, also ist es schnell (hat aber etwas Nettolatenz .. lesen Sie weiter unten), also ist es vielleicht nicht so schnell wie Inproc.
• Standardkonfiguration für ein Webfarmszenario Mehrere IIS-Sites verwenden einen Statusserver, um die Statussitzungsinformationen zu steuern.

Con's für StateServer

• Erfordert die Ausführung des ASP.NET StateServer-Dienstes.
• StateServer erfordert einige Konfigurationseinstellungen, um Anforderungen von Remote-Maschinen zu akzeptieren.
• Es gibt eine kleine winzige Nettolatenz, wenn die iis-Anfrage die Sitzungsinformationen auf einer anderen Netzwerkmaschine abrufen / einstellen muss.
• Kann keine Nicht-Sitzungsinformationen enthalten.

Pro's für SqlServer (als Zustandsserver)

• Der Status wird immer beibehalten, auch wenn die iis-Site neu gestartet wird.

Con's für SqlServer (als Zustandsserver)

• langsamste Lösung - & gt; Nettolatenzzeit UND Festplattenlatenz (da der SQL-Server den Zustand auf der Festplatte speichert / von der Festplatte liest).
• Am schwierigsten einzurichten / zu konfigurieren.
• Kann keine Nicht-Sitzungsinformationen enthalten

Pro's für Velocity (oder andere verteilte Caching-Systeme)

• Kann mehr als nur Sitzungsinformationen verarbeiten - & gt; Objekte, Anwendungseinstellungen, Cache, usw. (Dies ist eine sehr gute Sache IMO !!)
• Kann nur Speicher sein oder in einer Datenbank bestehen.
• Wenn ein "Knoten" ausfällt, funktioniert das System immer noch. (Angenommen, es gibt 2+ Caching-Knoten)

Con's für Velocity (oder andere verteilte Caching-Systeme)

• Im Allgemeinen kosten $$$
• Am schwierigsten zu installieren (muss installiert werden, Konfigurationseinstellungen optimieren, zusätzlichen speziellen Code hinzufügen).
• Hat eine Netzwerklatenz (die im Allgemeinen nichts ist), könnte aber eine Festplattenlatenz haben, wenn der Dienst die Daten persistiert (zB an einen Sql-Server).

Ich denke, die Annahme wäre, dass Sie eine Webfarm irgendeiner Art verwenden.

Eine Verwendung des Staatsdienstes erfolgt in einem Web Garden (mehrere Worker-Prozesse auf demselben Rechner). In diesem Fall können Sie den Lastenausgleich verwenden, um die Verbindung eines Benutzers zu einem bestimmten Server zu halten, und den n Worker alle Prozesse verarbeiten lassen, die denselben Zustandsdienst verwenden.

BEARBEITEN: Im Szenario "Webgarten + Statusdienst" oder "SQL Server" haben Sie auch den Vorteil, die Arbeitsprozesse auf dieser Maschine zu recyceln, ohne dass die verbundenen Clients ihre Sitzung verlieren.

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

Und noch ein Hinweis: Sie können den Statusdienst auf einem zweiten Computer verwenden und alle Server in der Farm haben diesen Computer betroffen, aber Sie haben dann einen einzigen Fehlerpunkt.

Und schließlich gibt es 3rd Party (und einige selbstgewachsene) verteilte State-Service-ähnliche Anwendungen. Einige davon haben Leistungsvorteile gegenüber den anderen Optionen, und das Ereignis Session_End wird tatsächlich ausgelöst. (Sowohl im Statusdienst als auch in der SQL Server-Sitzungsunterstützung wird das Session_End in Global.asax nicht ausgelöst (möglicherweise gibt es eine Möglichkeit, den SQL Server zu verwenden)).

In einer n-tierigen Umgebung mit SQL Server-Hosting-Sitzungsstatus erstellen Sie zusätzlichen Netzwerkverkehr für Ihr Back-End sowie einige SQL Server-Ressourcen, die diesen zusätzlichen Datenverkehr (Sitzung) übernehmen müssen Anfragen). SQL Server-Statusverwaltung ist auch langsamer als Statusserver.

Wenn Ihre Server jedoch bei unvorhergesehenen Vorfällen ausfallen, wird SQL Server höchstwahrscheinlich die Sitzungsinformationen verwalten, im Gegensatz zu einem Statusserver.

In meiner persönlichen Erfahrung hatte ich ein paar Probleme beim Speichern in Sitzungsvariablen. Ich verlor immer wieder die Sitzung und ich glaube, es war der Anti-Virus, der, während er jede Datei auf dem Server scannte, die Site neu kompilierte und die Sitzungen löschte. (Ich muss sagen, ich hatte keine Macht über diesen Server, ich wurde aufgefordert, die App dort zu hosten)

Also habe ich beschlossen, die Sitzung im SQL Server zu speichern und alle sind jetzt glücklich ... es ist unglaublich schnell

Schauen Sie sich diesen Artikel für einen schnellen Start an

Die Verwendung einer einzelnen Maschine zur Speicherung des Status in einem Webgarten bedeutet einen einzelnen Fehlerpunkt. Wir verwenden SQL-Status, aber es fügt ein wenig Overhead hinzu.

In Proc ist sehr schnell. Aber Begrenzung haben. Wir können nur ein einzelnes System verwenden. Beim Neustart des Systems gehen Informationen verloren. Arbeiterprozesse in derselben Maschine

StateServer speicherte die Sitzungsinformationen auf einem anderen Computer. Web Farm kann die Sitzung verwenden. Für Beispiel: mehrere Worker-Prozesse können vom Server auf die Sitzungsinformationen zugreifen. Wenn der Server neu gestartet wird, gehen Informationen verloren.

SQL Server wird verwendet, um die Informationen in Tabelle zu speichern. Standardmäßig wird es in TempDB gespeichert. Diese tempdb wird nach dem Aufruf von sqlservice dynamisch aufgerufen. Damit bleiben die Daten auch nicht erhalten. In diesem Szenario können wir in unserer eigenen Datenbank mit Hilfe von Script, das Custom Option heißt, speichern.