Ich habe die Aufgabe erhalten, ein Problem zu untersuchen, bei dem sich die Sitzung eines Benutzers zwischen den Aktualisierungen einer Seite ändert. Ich habe sofort (ohne etwas über die Website zu wissen) gesagt, dass es sich um ein Problem mit der Lastverteilung bzw. der Konfiguration des Webclusters handelt. Später habe ich jedoch herausgefunden, dass die Website nicht lastverteilt ist – es handelt sich um einen einzelnen Server.
Die Anwendung verfügt über ein Korbobjekt, das in der Sitzung gespeichert ist. Der Benutzer legt Artikel in den Korb usw. Wenn die Seite auf der Korbseite aktualisiert wird, ändern sich die Artikel im Korb, und manchmal sind keine vorhanden.
Die Sitzung geht nicht verloren, sie wird beim nächsten Aktualisieren fast immer wiederhergestellt, aber dann kann der Warenkorb beim nächsten Aktualisieren leer sein oder einen anderen Inhalt haben. Ich habe dieses Verhalten schon oft gesehen, aber nur bei Multiserver-Setups.
Wir haben versucht, dies in einer Entwicklerumgebung zu replizieren, allerdings ohne Erfolg. Wir können das Problem einfach nicht reproduzieren, aber in der Praxis kommt es häufig vor.
Die Webanwendung ist eine ASP.NET WebForms-Site, die unter .NET 4.0 auf Windows Server 2008 R2 und IIS 7.5 ausgeführt wird.
Der Sitzungsstatusmodus ist „InProc“ und das Sitzungstimeout ist auf 480 Minuten eingestellt.
Ich habe Fiddler verwendet, um die Anfragen und Antworten zu prüfen, und die an den Server übergebene ASP.NET-Sitzungs-ID ist jedes Mal dieselbe. Abgesehen vom tatsächlich zurückgegebenen HTML scheint es zwischen den Antworten keinen Unterschied zu geben.
Hat jemand eine Idee, was dieses Problem verursachen könnte?
Aktualisierung 1:
Ich habe einige der Protokollierungsfunktionen überarbeitet, die ein Kollege im Warenkorbcode implementiert hat. Ich kann jetzt sehen, dass die Sitzungs-ID gleich bleibt und der Wert der Sitzungsvariable ebenfalls gleich bleibt, obwohl unterschiedliche Daten angezeigt werden.
Entschuldigung, ich hätte ihre Protokollierung überprüfen sollen, bevor ich das gepostet habe.
Ich bin jedoch überzeugt, dass es sich um ein Serverproblem handelt, der Code funktioniert in unserer Testumgebung wie erwartet.
Antwort1
„Ich sagte, dass es sich anscheinend um ein Problem mit dem Lastenausgleich bzw. der Konfiguration des Webclusters handelt. Später fand ich jedoch heraus, dass für die Website kein Lastenausgleich durchgeführt wird – es handelt sich um einen einzelnen Server.“
Nur weil es sich um einen einzelnen Server handelt, bedeutet das nicht, dass kein Lastenausgleich stattfindet. IIS verfügt über eine Funktion namens „Web Garden“, die die Webarbeit auf mehrere Prozesse aufteilt, sodass sie auf mehrere CPUs verteilt werden kann.
Es ist wie eine kleine „Web Farm“ – daher der Name „Web Garden“. :)
Ein Effekt bei der Verwendung eines Web Gardens ist, dass InProc-Sitzungsvariablen nicht mehr richtig funktionieren, da Sie bei jeder Seitenanforderung möglicherweise in einem anderen Arbeitsprozess landen. InProc (In Process) funktioniert nur zuverlässig, wenn Sie immerim gleichen Prozess.
Lösung 1:
- Stellen Sie sicher, dass IIS nicht auf die Verwendung eines Web Gardens eingestellt ist. Gehen Sie dazu wie folgt vor:
- Öffnen Sie den IIS-Manager.
- Bestimmen Sie, welchen App-Pool Ihre Web-App verwendet.
- Klicken Sie mit der rechten Maustaste auf Ihren App Pool und wählen Sie "Erweiterte Eigenschaften".
- Scrollen Sie nach unten und stellen Sie "Maximale Anzahl an Worker-Prozessen" Zu
1.
Lösung 2:
- Verwenden Sie einen Sitzungsstatusserver, dessen einzige Aufgabe darin besteht, die Sitzungszustände für alle Arbeitsprozesse zu verwalten.
- Ändern Sie dann die Web-App von InProc zu StateServer.
- KasseKonfigurieren eines Statusservers zur Aufrechterhaltung des Sitzungsstatus (IIS 7)um damit anzufangen. :)
Schauen Sie sich diesen MSDN-Blog an:In-Proc-Sitzungsstatusverwaltung
Darin werden Ihre Sitzungsstatusoptionen beschrieben und wie Sie den Verlust einer InProc-Sitzung beheben.
Antwort2
Ich habe den Code schon lange nicht mehr geändert. (letzte Änderung: 20. Juli 2016)
Aber ich habe dasselbe Problem mit Windows Server 2016. Mein Kunde hat ein Upgrade von Windows 2012 R2 auf Windows 2016 durchgeführt. Ich konnte das Problem nicht lösen.
Dann habe ich ein Downgrade auf den alten Server (Windows 2012 R2) durchgeführt. Mein Problem wurde gelöst. Ich denke, es ist ein Fehler, aber ich kann nicht sicher sein
Vielleicht hilft es dir.