ASP Tipp 6: Verwenden Sie das „Session“-Objekt mit Umsicht

Nachdem Ihnen nun die Vorteile des Zwischenspeicherns im Application- und Session-Objekt bekannt sind, schlagen wir vor, das Session-Objekt zu meiden. Wie Sie im Folgenden sehen werden, haben Sitzungen, die auf viel verwendeten Sites verwendet werden, mehrere Nachteile. Bei viel verwendeten Sites handelt es sich um Sites mit Anforderungen von Hunderten von Seiten pro Sekunde oder Tausenden von gleichzeitigen Benutzern. Dieser Tipp ist noch wichtiger für Sites, die horizontal skalieren müssen, d. h. Sites, die mehrere Server zum Bewältigen der Belastung oder zum Implementieren von Fehlertoleranz verwenden. Bei kleineren Sites, wie z. B. Intranetsites, sind die praktischen Aspekte von Session-Objekten den Mehraufwand wert.

Zusammenfassend gilt, dass ASP für jeden Benutzer, der einen Webserver abfragt, ein Session-Objekt erstellt. Für jedes Session-Objekt ist (zusätzlich zu den in diesem gespeicherten Daten) ein Speicheraufwand von 10 KB erforderlich, und jedes Session-Objekt verlangsamt die Abfragen geringfügig. Das Session-Objekt bleibt aktiv, bis eine konfigurierbare Zeitüberschreitung (in der Regel 20 Minuten) erreicht wird.

Das größte Problem bei Session-Objekten ist nicht die Leistung, sondern die Skalierbarkeit. Session-Objekte sind nicht webserverübergreifend. Wenn ein Session-Objekt auf einem Server erstellt wurde, verbleiben seine Daten auf diesem. Wenn Sie Session-Objekte in einer Webservergruppe verwenden, müssen Sie also eine Strategie entwickeln, damit die Anfragen aller Benutzer an den Server geleitet werden, auf dem sich das Session-Objekt befindet. Dies wird als „feste Zuweisung“ eines Benutzers zu einem Webserver bezeichnet. Daraus wird der Begriff „fest zugewiesene Sitzungen“ abgeleitet. „Fest zugewiesene“ Benutzer verlieren Ihren Sitzungszustand, wenn der Webserver abstürzt, da die Session-Objekte nicht auf der Festplatte gespeichert sind.

Strategien zum Implementieren von fest zugewiesenen Sitzungen umfassen Hardware- und Softwarelösungen. Lösungen, wie z. B. das Programm für Netzwerklastenausgleich in Windows 2000 Advanced Server und Local Director von der Firma Cisco, können fest zugewiesene Sitzungen auf Kosten einer gewissen Skalierbarkeit implementieren. Diese Lösungen sind aber nicht perfekt. Das Einbringen eigener Softwarelösungen ist zurzeit auch nicht empfehlenswert (wir haben es mit ISAPI-Filtern und URL-Veränderungen u. ä. versucht)

Das Application-Objekt ist ebenfalls nicht serverübergreifend. Wenn Anwendungsdaten über die Webservergruppe freigegeben und aktualisiert werden müssen, müssen Sie eine Back-End-Datenbank verwenden. Schreibgeschätzte Anwendungsdaten sind jedoch in Webservergruppen weiterhin nützlich.  

Die meisten unternehmenskritischen Sites möchten mindesten zwei Webserver bereitstellen, selbst wenn der einzige Grund hierfür ein Erhöhen der Betriebszeit (der Umgang mit Ausfüllen und Serverwartung) ist. Aus diesem Grund müssen Sie beim Entwerfen einer unternehmenskritischen Anwendung entweder „fest zugewiesene Sitzungen“ implementieren oder Session-Objekte sowie sonstige Zustandsverwaltungsmethoden vermeiden, die den Benutzerzustand auf individuellen Webservern speichern.  

Wenn Sie keine Session-Objekte verwenden, denken Sie daran, sie zu deaktivieren. Sie können für Ihre Anwendung dazu den Internetdienste-Manager verwenden (siehe ISM-Dokumentation). Wenn Sie sich für die Verwendung von Session-Objekten entscheiden, können Sie ihre Auswirkungen auf die Leistung auf verschiedene Weise minimieren.

Sie können Inhalt, der keine Session-Objekte benötigt, (wie z. B. Hilfebildschirme, Besucherbereiche usw.) in eine separate ASP-Anwendung verschieben, für die Session-Objekte deaktiviert sind. Sie können ASP Seite für Seite darüber informieren, dass das Session-Objekt auf einer bestimmten Seite nicht benötigt wird. Positionieren Sie dazu folgende Anweisung am oberen Rand der ASP-Seite.

<% @EnableSessionState=False %>

Ein guter Grund für die Verwendung dieser Anweisung ist das interessante Problem, das bei Session-Objekten mit Framesets auftritt. ASP garantiert, dass zu einem bestimmten Zeitpunkt nur eine Anforderung von einem Session-Objekt ausgeführt wird. Wenn ein Browser für einen Benutzer mehrere Seiten anfordert, wird dadurch garantiert, dass zu einem bestimmten Zeitpunkt nur eine ASP-Anforderung beim Session-Objekt eingeht. Dadurch werden beim Zugreifen auf das Session-Objekt Multithread-Probleme vermieden. Dies führt jedoch auch dazu, dass alle Seiten in einem Frameset serialisiert, d. h. nacheinander statt simultan, gezeichnet werden. Der Benutzer muss daher u. U. lange warten, bis alle Frames angezeigt werden. Zusammenfasend gilt: Wenn bestimmte Frameset-Seiten nicht vom Session-Objekt abhängen, teilen Sie dies ASP mithilfe der Anweisung @EnableSessionState=False auf jeden Fall mit.  

Anstelle des Session-Objekts gibt es eine Reihe anderer Optionen zum Verwalten des Sitzungszustands. Für geringe Zustandsmengen (weniger als 4 KB) empfehlen sich Cookies, QueryString-Variablen und Variablen mit verborgenen Formularen. Für größere Datenmengen, wie z. B. Einkaufswagen, ist eine Back-End-Datenbank die beste Lösung. Es gibt viele Artikel über Zustandsverwaltungsmethoden in Webservergruppen. Weitere Einzelheiten finden Sie in den Referenzen zum Sitzungszustand.