2010-12-02 5 views
0

ich mit Webgärten in ASP.NET mit IIS 6.0 bin bastelt. Mehrere Quellen (Source1Source2) erklären, wie InProc Session mit Web Gardens nicht gut funktioniert. Ich habe ein Programm gebaut, um es zu beweisen, aber die Ergebnisse sind schwer zu erklären. Bitte helfen Sie mir, die Ergebnisse meiner Tests zu erklären.
TEST
Ich habe die maximale Anzahl der Worker-Prozesse auf 1000 in IIS festgelegt. Ich erstelle eine Webanwendung, die eine Zeichenfolge in Session speichert und den Wert mit einem Klick auf die Schaltfläche abruft. Führen Sie die Web-App in den IE-, FF- und Blackberry-Browsern aus.

RESULT
IE: zieht normalerweise Sitzung richtig. Die Sitzung ist fehlgeschlagen, nachdem die Website ca. 3 Minuten inaktiv war.
FF: Sitzung nie selten fehlgeschlagen. Nach dem Sitzen ~ 15 Minuten Sitzung fehlgeschlagen.
BB: Regelmäßig versagt. Das Verhältnis stimmt mit dem überein, was Source2 sagt. Je größer die Anzahl der Arbeitsprozesse im Garten ist, desto wahrscheinlicher ist es, dass die Sitzung fehlschlägt.

Meine Interpretation
FF/IE/Desktop-Browser mehr Speicher, der kann für eine bessere Caching ermöglicht.Der Nachweis, dass Webgärten nicht gut fliegen mit InProc Sessions

Anmerkungen
Wenn der IE bei jedem Besuch auf neuere Versionen einer Seite überprüft wird, hat dies keine Auswirkungen. Bemerkenswert ist, dass Postbacks vom Blackberry ziemlich sicher sind, eine neue Instanz von w3wp.exe zu erstellen, während die Mem-Nutzung für denselben w3wp.exe-Prozess mit Postbacks von IE/FF erhöht wurde.

+0

Ich würde der Browser nicht erwarten keine Auswirkungen auf den Sitzungsstatus haben. Sind Sie sicher, dass die Browser anders verhielten? Welche Beweise haben Sie für diese Sitzung gescheitert? – n8wrl

+0

Der Beweis ist, dass die Zeichenfolge ist daher nicht in der Sitzung führt es zu einem Objekt Verweise auf eine Instanz eines Objekts nicht festgelegt, wenn ich die TextBox mit den Sitzungsdaten zu füllen versuchen. –

+0

Welche Cache-Richtlinie wird mit der Seite an den Browser gesendet? Wenn Sie wiederholt auf eine Seite mit Cache-Richtlinien treffen, wird sie nicht jedes Mal zum Server geleitet. Das könnte dazu führen, dass es aussieht, als wäre die Sitzung am Leben, obwohl sie es nicht ist. – n8wrl

Antwort

2

Die Tatsache, dass Browser mehr Speicher haben nichts haben sollte mit InProc Sitzungen und WebGardens sind wie die Server-Seite Komponenten zu tun.

Sie sehen mehr Probleme, wie Sie die Anzahl der Arbeitsprozesse erhöhen, weil die mehr Zahl der Arbeiter wahrscheinlich die weniger verarbeitet ist, dass Ihre Anfrage durch den gleichen Arbeitsprozess behandelt werden, wenn sie zurückkommt. Mit anderen Worten, wenn Sie nur einen Worker-Prozess haben, haben Sie eine Chance von 1 zu 1, dass er bei einer zweiten Anfrage zum selben Worker-Prozess zurückkehrt. Wenn Sie zwei Arbeitsprozesse haben, haben Sie 1 zu 2 Chancen. Wenn Sie drei Arbeitsprozesse haben, haben Sie 1 von 3 Chancen und so weiter. obwohl

Ich frage mich, warum Sie InProc Sitzungen, zu verwenden versuchen. Es gibt fast keinen guten Grund, da sie sehr leicht verschwinden können. Lesen Sie diesen Artikel http://www.west-wind.com/Weblog/posts/1986.aspx

+0

Punkt auf den serverseitigen Komponenten genommen. Es erklärt immer noch nicht die große Varianz in den Ergebnissen basierend auf Browser. Die Artikel, die ich in meinem Beitrag verlinkt habe, erklären das Verhältnis, so dass der Unterricht nicht notwendig ist. Da MS InProc als Standard in ASP.NET verwendet, vertraue ich darauf, dass es ziemlich zuverlässig ist, aber das ist nebensächlich. Ich suche nach einer Erklärung der tatsächlichen Testergebnisse. –

+0

MS verwendet inProc als Standard, weil es die beste Leistung ist. Sie warnen wiederholt davor für Farmen und jeden Sitzungszustand für Skalierbarkeit. – n8wrl

+0

@ n8wrl Einverstanden. Ich möchte diese Tatsache einfach mit Konsistenz beweisen oder die Inkonsistenz in Bezug auf Web-Gärten erklären. –

Verwandte Themen