Der IIS bietet zwei verschiedene Möglichkeiten zur Session-Verwaltung:

• In-Proc(ess)
  Beim In-Process – Sessionmanagement werden die Session-Daten im selben Speicher gehalten wie der ASP.NET Arbeits-Prozess, welcher die aktuelle Anwendung hostet. Dieses ist die bei weitem schnellste Möglichkeit der Session-Verwalttung, birgt aber auch Risiken: Sollte die ASP.NET-Anwendung aus irgend einem Grund neu starten so sind auch sämtliche Session-Daten verloren.
• Out-Of-Process
  Beim Out-Of-Process – Sessionmanagement werden die Session-Daten – wie der Name schon vermuten lässt – in einem separaten Prozess verwaltet. Dieser kann entweder auf dem gleichen Server wie der IIS (und der ASP.NET Arbeitsprozess) laufen oder aber auch auf einem anderen Rechner. Dadurch erreicht man hier eine gewisse Skalierbarkeit, denn gerade bei vielen Benutzern (Sessions) und vielen in der Session gespeicherten Daten geht der IIS merklich in die Knie. Weiterhin bleiben die Session-Daten bei einem Reset der ASP.NET-Anwendung erhalten. Der Preis dafür ist jedoch ein gewisser Geschwindigkeitsnachteil gegenüber der In-Proc – Sessionverwaltung.
  "Physisch" gesehen gibt es hier zwei Möglichkeiten:
  • ASP.NET State Server
    Der IIS 6 bringt von Hause aus den ASP.NET State Service mit, welcher für die Speicherung der Session-Daten verwendet werden kann. Der State Service kann so konfiguriert werden, dass er auf dem gleichen Server läuft, um einen Web Garden zu unterstützen (selbst wenn nur ein einzelner Worker-Prozess genutzt wird) oder auf einem anderen Server, um eine Web Farm aufzuauen (was theoretisch aber auch mit einem einzelnen Server möglich sein müsste). Die Verwendung des State Servers ist verschiedenen Quellen zufolge etwa 15% langsamer als das In-Proc – Sessionmanagement.
  • SQL-Server
    Wie auch der State Server so kann der SQL-Server für die Session-Verwaltung entweder auf dem gleichen Server oder auf einer anderen Maschine laufen. Seine Verwendung ist etwa 25% langsamer also die In-Proc – Methode.

  Wichtiger Weise zu beachten ist hierbei noch, dass komplexe Objekte, die in der Session gespeichert werden sollen, beim Out-Of-Process – Sessionmanagement serialisierbar sein müssen.

Arbeitet eine ASP-NET – Anwendung mit Out-Of-Process – Sessionmanagement gibt es eigentlich kaum Punkte, um die man sich zu sorgen braucht. Bei der In-Process – Verwaltung ist das anders – denn folgende Features des IIS 6 können hier zu Fallstricken werden:

• Application Pools
  Ein Application Pool bietet die Möglichkeit, eine oder mehrere Webseiten von anderen Webseiten zu isolieren. Das wird durch die Verwendung mehrerer getrennter Worker-Prozesse realisiert, welche natürlich auch die Session-Daten getrennt verwalten. Ein virtueller Host im IIS 6 kann mehr als eine Application beinhalten. Steuert man das Anlegen der ASP.NET-Application nicht kann es passieren, dass eine Anwendung von mehreren Worker-Prozessen verwaltet wird. In diesem Fall springt die Anwendung zwischen mehreren Prozessen hin und her. Die Session-Daten sind dann nach dem ersten Request in einem Prozess "verloren", dafür existiert die gleiche Session mit inkonsistenten Daten (da diese nicht geupdatet werden) nun in mehreren Worker-Prozessen.
• Web Gardens
  Web Gardens sind kleine, skalierbare Webfarmen (wer hätte es gedacht…), bei denen auf einem Server mehrere Worker-Prozesse einen Application Pool verwalten. Weil jeder Worker-Prozess seinen eigenen Speicher für die Session-Verwaltung nutzt treten auch hier oben geschilderte Probleme auf. Web Gardens und In-Proc – Sessionmanagement ist also böse.
• Worker-Prozess Recycling
  Der IIS 6 bietet die Möglichkeit, Worker-Prozesse nach bestimmten zeitlichen Schemen zu recyclen, d.h. die alten Prozesse zu beenden und neue dafür zu starten, um den Server gesund und sauber zu halten. Das klingt zwar erst einmal super, hat aber den Haken dass beim Recycling eines Worker-Prozesses auch alle in ihm enthaltenen Session-Daten verschwinden. Füllt man gerade ein umfangreiches Formular auf einer Webseite aus oder hat seinen Einkaufswagen voll gepackt so kann dies ziemlich frustrierend werden.

Zusammenfassend bleibt also zu sagen: Generell ist bei ASP.NET-Anwendungen auf dem IIS 6 Out-Of-Process – Sessionmanagement die erste Wahl. Weiterhing sollte man zur vermeidung von Problemen auch möglichst nur einen einzigen Worker-Prozess pro Anwendung einsetzen. Dann kann auch so gut wie nichts mehr schief gehen