Wenn ich einen leeren Session_Start-Handler in Global.asax.cs erstelle, verursacht dies einen erheblichen Treffer beim Rendern von Seiten im Browser.
Wie man reproduziert:
Erstellen Sie eine leere ASP.NET MVC 3-Webanwendung (ich verwende MVC 3 RC2). Fügen Sie dann einen Home-Controller mit diesem Code hinzu:
%Vor%Erstellen Sie als nächstes eine Ansicht Home / Index.cshtml und fügen Sie folgendes in den BODY-Abschnitt ein:
%Vor%Wenn Sie diese Seite ausführen, werden auf der Seite 20 IFRAME angezeigt, die jeweils eine Nummer enthalten. Alles, was ich hier mache, ist eine Seite zu erstellen, die 20 weitere Seiten hinter den Kulissen lädt. Bevor Sie fortfahren, notieren Sie, wie schnell diese 20 Seiten geladen werden (aktualisieren Sie die Seite einige Male, um die Ladevorgänge zu wiederholen).
Als nächstes gehen Sie zu Ihrem Global.asax.cs und fügen Sie diese Methode (ja, der Körper der Methode ist leer):
%Vor%Führen Sie die Seite jetzt erneut aus. Dieses Mal werden Sie feststellen, dass die 20 IFRAMEs viel langsamer geladen werden, eine Sekunde nach der anderen. Das ist seltsam, weil wir in Session_Start eigentlich nichts machen ... es ist nur eine leere Methode. Aber das scheint genug zu sein, um die Verlangsamung in allen folgenden Seiten zu verursachen.
Weiß jemand, warum das passiert, und besser noch hat jemand einen Fix / Workaround?
Aktualisieren
Ich habe festgestellt, dass dieses Verhalten nur auftritt, wenn der Debugger angeschlossen ist (mit F5). Wenn Sie es ohne den angehängten Debugger (Strg-F5) ausführen, scheint es in Ordnung zu sein. Also, vielleicht ist es kein bedeutendes Problem, aber es ist immer noch seltsam.
tl; dr : Wenn Sie dieses Problem mit Webforms haben und keinen Schreibzugriff auf den Sitzungsstatus auf dieser Seite benötigen, können Sie EnableSessionState="ReadOnly" zu Ihrer @Page -Direktive hinzufügen.
Offensichtlich zwingt das Vorhandensein von Session_Start allein ASP.NET dazu, alle Anfragen, die von derselben Sitzung stammen, sequentiell auszuführen. Dies kann jedoch Seite für Seite behoben werden, wenn Sie keinen Schreibzugriff auf die Sitzung benötigen (siehe unten).
Ich habe meine eigene Testeinstellung mit Webforms erstellt, die eine aspx-Seite verwendet, um Bilder zu liefern. 1
Hier ist die Testseite (einfaches HTML, Startseite des Projekts):
%Vor%Hier ist die aspx-Seite (GetImage.aspx):
%Vor% Und die relevanten Teile des Codebehinds (GetImage.aspx.cs, using und namespace übersprungen):
Testläufe
Run 1 , unmodified: Die Seite lädt schnell, das Ausgabefenster zeigt eine zufällige Mischung aus Start und End s, was bedeutet, dass die Anfragen parallel verarbeitet werden.
Run 2 , fügen Sie Session_Start zu global.asax hinzu (müssen Sie F5 einmal im Browser drücken, ich weiß nicht warum): Start und End alternate zeigt an, dass die Anforderungen nacheinander verarbeitet werden. Wenn Sie den Browser mehrmals aktualisieren, zeigt dies, dass dies Leistungsprobleme hat, selbst wenn der Debugger nicht angeschlossen ist.
Run 3 , wie Run 2, aber EnableSessionState="ReadOnly" zur @Page Direktive von GetImage.aspx hinzufügen: Die Debug-Ausgabe zeigt mehrere Start s vor der ersten End . Wir sind wieder parallel und wir haben eine gute Leistung.
1 Ja, ich weiß, dass dies mit einem Ashx-Handler getan werden sollte. Es ist nur ein Beispiel.
Kann Ihnen nicht sagen, was Ihr Debugger tut (intellitrace? detaillierte Protokollierung? Ausnahmen der ersten Chance?), aber Sie sind immer noch in den Händen der Sitzungen Fähigkeit, gleichzeitige Anfragen zu behandeln.
Der Zugriff auf den ASP.NET-Sitzungsstatus ist pro Sitzung exklusiv, dh wenn zwei verschiedene Benutzer gleichzeitig Anfragen stellen, wird der Zugriff auf jede einzelne Sitzung gleichzeitig gewährt. Wenn jedoch zwei gleichzeitige Anforderungen für dieselbe Sitzung (mit demselben SessionID-Wert) gestellt werden, erhält die erste Anforderung exklusiven Zugriff auf die Sitzungsinformationen. Die zweite Anforderung wird erst nach Abschluss der ersten Anforderung ausgeführt. (Die zweite Sitzung kann auch Zugriff erhalten, wenn die exklusive Sperre für die Informationen aufgehoben wird, weil die erste Anforderung das Sperrzeitlimit überschreitet.) Wenn der EnableSessionState-Wert in Die @ Page-Direktive wird auf ReadOnly festgelegt, eine Anforderung für die schreibgeschützte Sitzungsinformation führt nicht zu einer exklusiven Sperre für die Sitzungsdaten. Es kann jedoch sein, dass schreibgeschützte Anforderungen für Sitzungsdaten immer noch auf eine Sperre warten müssen, die durch eine Lese- / Schreibanforderung für das Löschen von Sitzungsdaten festgelegt wurde.
Quelle: Überblick über den ASP.NET-Sitzungsstatus , mein Schwerpunkt
Tags und Links asp.net global-asax