ASP.NET AJAX-Lastausgleichsprobleme

Question

Dies wäre eine Frage für jeden, der Code im App_Code-Ordner hat und einen Hardware-Load-Balancer verwendet.Es stimmt, dass der Hardware-Load-Balancer auf Sticky Sessions eingestellt werden könnte, um das Problem zu lösen, aber in einer perfekten Welt würde ich die Funktion gerne deaktivieren.

Wenn sich eine Datei im App_Code-Ordner befindet und die Site nicht vorkompiliert ist, generiert iis zufällige Dateinamen für diese Dateien.

server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"

Wenn also ein Benutzer die Seite postet und auf den anderen Server weitergeleitet wird, funktioniert nichts.

Hat jemand eine Lösung dafür?Ich könnte zu einer vorkompilierten Website wechseln, aber unsere Qualitätssicherungsabteilung hätte dann nicht mehr die Möglichkeit, nur die geänderten Dateien hochzustufen.

Answer 1

Sie könnten alles, was sich in Ihrem app_code befindet, in eine externe Klassenbibliothek verschieben, wenn Ihre Qualitätssicherungsabteilung die gesamte Bibliothek hochstufen kann.Ich denke, Sie bleiben bei Sticky Sessions hängen, wenn Sie keine bequeme oder erträgliche Möglichkeit finden, zu einer vorkompilierten Site zu wechseln.

Answer 2

Ist der Knoten <machinekey> auf beiden Servern auf den gleichen Wert eingestellt?

Sie können die Datei „machine.config“ in „web.config“ überschreiben, um dies festzulegen.Dies muss übereinstimmen, sonst kann es zu seltsamen Situationen wie dieser kommen.

Answer 3

Unterstützt Ihr Load Balancer Sticky Sessions?Wenn diese Option aktiviert ist, leitet der Balancer innerhalb eines bestimmten Zeitfensters immer wieder dieselbe IP an denselben Server weiter.Auf diese Weise würden alle Anfragen (AJAX oder anders) von einem Client immer denselben Server im Cluster/in der Farm treffen.

Answer 4

Ok, das Wichtigste zuerst...Die MachineKey-Sache ist wahr.Dies sollte unbedingt auf allen Maschinen mit Lastausgleich gleich eingestellt sein.Ich erinnere mich nicht an alles, was es betrifft, aber tue es trotzdem.

Zweitens: Machen Sie weiter und kompilieren Sie die Site vor.Sie können tatsächlich immer noch neue Versionen veröffentlichen, wenn eine CS-Datei für eine Seite vorhanden ist und diese Seite neu kompiliert wird.Was knifflig wird, sind die app_code-Dateien, die in einer einzigen DLL kompiliert werden.Wenn dort jedoch eine Änderung vorgenommen wird, können Sie die neue DLL hochladen und wieder sollte alles in Ordnung sein.

Um es noch einfacher zu machen, aktivieren Sie die Option „Feste Benennung und Einzelseitenassemblys verwenden“.Dadurch wird sichergestellt, dass die Dinge bei jeder Kompilierung denselben Namen haben. Sie müssen also nur die geänderten DLL-Dateien testen und dann ersetzen.

Alles in allem sollten Sie in der jetzigen Form kein Problem haben.Die Anfrage geht an IIS, das lediglich die Seite bereitstellt und nach Bedarf kompiliert.Wenn der Code dahinter auf jedem Computer unterschiedlich ist, sollte das eigentlich keine Rolle spielen, der Code ist derselbe und dieser Computer verweist auf seinen eigenen Code.Die eigentliche Anfrage/das eigentliche Postback weiß nichts davon und kümmert sich auch nicht darum.Alles, was ich oben gesagt habe, sollte zur Vereinfachung beitragen, aber es sollte trotzdem funktionieren ...Es handelt sich also wahrscheinlich um ein Maschinenschlüsselproblem.

Answer 5

Wenn es sich um einen Hardware-Load-Balancer handelt, sollten Sie kein Problem haben, da dort lediglich die Anforderungs-URL bekannt ist, in der der Server die angeforderte Seite kompilieren und bereitstellen würde.

Das einzige Problem, das ich mir vorstellen kann, ist der Sitzungs- und Ansichtsstatus.

Answer 6

Es stimmt, dass der Hardware-Load-Balancer auf Sticky Sessions eingestellt werden könnte, um das Problem zu lösen, aber in einer perfekten Welt würde ich die Funktion gerne deaktivieren.

Answer 7

Es scheint, dass dies nur für die ViewState-Verschlüsselung gilt.Es hat keine Auswirkungen auf die Dateinamen für automatisch kompilierte Assemblys.

Answer 8

Ich denke, dass das asp.net-Modell ziemlich stark von der Verschlüsselung und dem maschinenspezifischen Speicher abhängig ist, daher bin ich mir nicht sicher, ob es funktioniert, um Sticky IP für Sitzungen zu vermeiden.

Ich weiß nichts über ASP.NET AJAX (ich verwende stattdessen den MonoRail NJS-Ansatz), aber der Sitzungsstatus könnte ein Problem für Sie sein.

Sie müssen sicherstellen, dass die Sitzungszustände serialisierbar sind und keine InMemory-Sitzung verwenden.Sie müssen wahrscheinlich den ASP.NET Session State Server ausführen, um sicherzustellen, dass die gesamte Frontend-Farm denselben Sitzungsspeicher verwendet.In einem solchen Fall muss die Sitzung perfekt serialisierbar sein (deshalb wird kein Objekt in der Sitzung bevorzugt, Sie müssen immer eine ID verwenden, und ich wette, MS hält sich an diese Einschränkung, wenn sie eine AJAX-Bibliotheksentwicklung durchführen).