Frage

Wir haben „Drip“ verwendet, um herauszufinden, warum Seiten mit UpdatePanels dazu neigen, viel clientseitigen Speicher zu verbrauchen.Bei einer Seite mit einem regelmäßigen Postback sehen wir, dass Drip 0 Lecks erkannt hat.Wenn wir dem Mix jedoch ein Update-Panel hinzufügen, scheint jedes einzelne DOM-Objekt, das sich innerhalb des Update-Panels befindet, zu lecken (laut Drip).

Ich bin mir nicht sicher, ob Drip zuverlässig genug ist, um solche Dinge zu melden – die gemeldeten Leaks scheinen darauf hinzudeuten, dass Drip die Seite geringfügig verändert.

Hat jemand Erfahrung damit?Sollte ich in Panik geraten und aufhören, Microsoft Ajax zu verwenden?Ich bin mir nicht zu schade, an Microsoft zu zweifeln, aber es erscheint mir fragwürdig, dass das so sein könnte Das schlecht.

Wenn Sie ein Tool kennen, das besser als Drip ist, wäre das ebenfalls hilfreich.

War es hilfreich?

Lösung

Entsprechend ASP.NET AJAX in Aktion, P.257

Kurz bevor das alte Markup durch das aktualisierte HTML ersetzt wird, werden alle DOM-Elemente im Panel auf Microsoft Ajax-Verhalten oder damit verbundene Steuerelemente untersucht.Um Speicherlecks zu vermeiden, werden die mit DOM-Elementen verknüpften Komponenten entsorgt und dann zerstört, wenn das HTMl ersetzt wird.

Soweit ich weiß, sind alle asp.net-Ajax-Komponenten im Update-Panel entsorgt, um Speicherlecks zu verhindern, aber alles andere darin wird einfach durch den empfangenen HTML-Code ersetzt.

Wenn Sie also keine asp.net-Ajax-Komponenten im Zielcontainer für die Antwort haben, wäre dies im Grunde dasselbe wie ein innerer HTML-Ersatz durch eine andere JS-Framework-/Ajax-Anfrage, also würde ich sagen, dass es nur das Wie ist Der Browser übernimmt dies und nicht asp.net ajax verursacht dies.

Auch wenn es möglicherweise „undicht“ ist, kann dies auch beabsichtigt sein, was bedeutet, dass der Browser die Dom-Elemente möglicherweise noch nicht zurückgefordert und freigegeben hat.Auch Tropfen können dazu führen, dass diese auslaufen, da sie sich an diesen Domelementen festsetzen.

Andere Tipps

Das ist sehr wahrscheinlich.Dies entsprach im Wesentlichen unseren Annahmen (Browserproblem, nicht unbedingt Ajax).

Unser Problem besteht nun darin, dass viele Leute über eine Citrix-Umgebung auf diese Anwendung zugreifen und jede Seite kontinuierlich DOM-Objekte erstellt und diese nicht freigibt, so dass die Citrix-Umgebung nach einiger Zeit ins Straucheln gerät.Ich habe ähnliche Beschwerden online gesehen (insbesondere wenn man dumm genug ist, über Citrix auf eine Ajax-Website zuzugreifen), aber es gibt mir kein besseres Gefühl, dass dies das beabsichtigte Verhalten ist.

Ich frage mich jetzt, ob jemand einen cleveren Workaround gefunden hat.Wir haben auch eine Client-App, bei der wir .NET BrowserControl verwenden, um auf diese Websites zuzugreifen, und nicht nur IE7. Wenn also jemand einen geheimen API-Aufruf kennt (FreeStaleDomObjectsFTW()) können wir von diesem Ende des Stapels aus nutzen, das wäre auch nützlich.

Du könntest es anhängen pageLoading-Ereignis der PageRequestManager-Klasse Gehen Sie die Aktualisierungseigenschaften der Panels durch und entfernen Sie die DOM-Elemente in jedem.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top