ASP.Net Sitzungszustand

Question

Ich frage mich, ob es möglich wäre, die sqlConnectionString für SessionState in ASP.net basierend auf der Domäne, auf der eine Anwendung läuft, zu ändern?

Ein Szenario; Wir haben 20 Websites, die von einer Anwendung ausgeführt werden und jeweils mit verschiedenen Datenbanken kommunizieren, je nachdem, von welcher Domäne (Website) aus sie durchsucht werden.

Beim Durchsuchen von www.domain1.com spricht die Anwendung mit der Datenbank 'db1'. Die Website www.domain2.com spricht dagegen mit der Datenbank 'db2' usw., wodurch der relevante Inhalt ausgewählt wird und auch die Last auf jede Datenbank verteilt wird, anstatt eine Master-Datenbank zu verwenden, um alle Verbindungen für die Websites zu handhaben.

Ein Problem, das jedoch aufgetreten ist - für dieses Setup verwenden wir den SqlServer-Modus für den SessionState, sodass alle Benutzer aller Websitesitzungen in einer aspstate-Datenbank gespeichert werden. Mit zunehmender Auslastung der Websites / Anzahl der Websites nimmt diese Datenbank jedoch unter steigendem Druck zu, um alle Session-Anfragen für alle Websites zu verarbeiten, und wir beginnen, einige Timeouts zu erhalten, bei denen die Verbindungen zu dieser Datenbank zu einem Engpass werden.

Wir können die Websites trennen und sie in ihre eigene Anwendung verschieben und verschiedene Anwendungen mit demselben Code einrichten, aber in jeder Anwendung eine andere Session-Datenbank in jeder Web.Config festlegen und so die Last reduzieren. Diese Aufgabe wäre jedoch ziemlich zeitaufwändig und würde langfristig zu mehr Verwaltungsaufwand führen. ALSO.. Ich würde gerne wissen, ob es möglich ist, innerhalb des Codes die sqlConnectionString für SessionState, basierend auf einer Domäne, zu ändern, bevor das Sitzungsobjekt erstellt wird? Können wir von System.Web.HttpApplication erben und das Ereignis Application_AcquireRequestState verwenden, um das erforderliche Setup des HttpSessionState-Objekts zu erstellen?

Hoffentlich ergibt das Sinn und jemand kann einige Hinweise geben und mir beweisen, dass dies kein unrealistischer Traum ist!

Prost, Steve

Answer 1

Ihr Problem ist weniger, dass die Verbindungen zur Datenbank blockieren, sondern dass Sie die Netzwerkverbindung zur Datenbank mit Daten aus allen Sitzungen überlasten.

Standardmäßig serialisiert der Sql Server-State-Anbieter einfach Ihre Daten und sendet sie an die Datenbank. Dies ist SEHR ineffizient und dauert auf einem schnellen Netzwerk sehr lange.

Wir haben dieses Problem gelöst, indem wir zu einem benutzerdefinierten Anbieter wie DOTSS gegangen sind, der den Sitzungsinhalt vor dem Senden an die Datenbank komprimiert. Die Kompressionsraten, die wir sehen, liegen bei 80%-90% und die Kompressionszeit beträgt weniger als 10ms.

Answer 2

Ich denke, du übersiehst einen großen Punkt - wenn der Engpass der SQL-Server ist, wird es nicht viel helfen, Dinge in separaten Datenbanken auf demselben Server zu platzieren. Entweder läuft SQL an seine Grenzen oder das Netzwerk hat nicht genügend Bandbreite. Ich würde versuchen herauszufinden, welches davon der Fall ist, bevor ich irgendetwas unternehme.

Answer 3

Sie können einen benutzerdefinierten Sitzungsstatusanbieter implementieren. Siehe MSDN für Details. Ich habe es noch nie gemacht, aber mit ein wenig Glück können Sie das SqlServer-Sitzungsstatusmodul umwickeln und basierend auf der Domain umleiten

Answer 4

• Zunächst einmal sehe ich keinen Vorteil darin, "Ich würde gerne wissen, ob es möglich ist, innerhalb des Codes die sqlConnectionString für SessionState basierend auf einer Domäne zu ändern, bevor das Sitzungsobjekt erstellt wird", im Vergleich dazu, dies in der web.config festzulegen.
• Zweitens denke ich, dass du diese Verbindungszeichenfolgeneinstellung in App_Start ändern musst, damit alle Anfragen diese geänderten Einstellungen verwenden. Application_AcquireRequestState ist wahrscheinlich zu spät für dies.

Answer 5

Warum nicht die Websites in separate Webanwendungen aufteilen und Hostheader verwenden, um zwischen den Websites zu unterscheiden. Auf diese Weise könnten Sie ganz einfach konfigurieren, welche Sitzungsdatenbank Ihre Webanwendung verwenden soll, da jede Webanwendung eine separate web.config-Datei hätte.