「Drip」を使用して、UpdatePanelを含むページがクライアント側のメモリを大量に使用する傾向がある理由を特定しようとしています。通常のポストバックのあるページでは、Dripによって検出されたリークは0です。ただし、更新パネルをミックスに追加すると、更新パネル内にあるすべてのDOMオブジェクトがリークしているように見えます（Dripによると）。
Dripがこれらの種類のことを報告するのに十分信頼できるかどうかはわかりません-報告されたリークは、Dripがページをわずかに変更していることを示しているようです。
誰かがこれを経験したことがありますか？パニックになってMicrosoftAjaxの使用をやめるべきですか？私はマイクロソフトを疑う以上のことはしていませんが、それがこれほど悪いことかもしれないと私には怪しいようです。
また、Dripよりも優れたツールを知っている場合は、それも役立ちます。
ASP.NET AJAX in Actionによると、p。257
古いマークアップが更新された HTML に置き換えられる直前に、パネル内のすべての DOM 要素が、Microsoft Ajax の動作またはそれらに関連付けられているコントロールについて調べられます。メモリ リークを回避するために、DOM 要素に関連付けられたコンポーネントは破棄され、HTMl が置き換えられると破棄されます。
私の知る限り、更新パネル内の asp.net ajax コンポーネントはメモリ リークを防ぐために破棄されますが、そこにあるその他のものは受信した html に置き換えられます。
したがって、応答のターゲット コンテナーに asp.net ajax コンポーネントがない場合、基本的には、他の js フレームワーク / ajax 要求を使用した内部 html 置換と同じであるため、それは単なる方法であると言えます。これを引き起こすasp.net ajaxではなく、ブラウザがこれを処理します。
また、「リーク」している可能性がありますが、仕様によるものである可能性があります。つまり、ブラウザーがまだ dom 要素を回収して解放していない可能性があります。また、ドリップはそれらの dom 要素に付着しているため、それらが漏れている可能性があります。
PageRequestManagerクラスのpageLoadingイベントにアタッチし、パネルの更新プロパティを調べて、それぞれのDOM要素を削除することができます。
その可能性は非常に高いです。これは、ほぼ想定どおりの結果でした (ブラウザの問題であり、Ajax とは限りません)。
私たちの問題は、このアプリケーションが Citrix 環境を介して多くの人にアクセスされ、各ページが継続的に DOM オブジェクトを作成し、それらを解放しないため、Citrix 環境が使用後にスラッシングを開始することです。同様の苦情をオンラインで見たことがあります (特に、Citrix 経由で Ajax Web サイトにアクセスするほど馬鹿げている場合)。
誰かが巧妙な回避策を思いついたのではないかと今思っています。また、直接の IE7 ではなく、.NET BrowserControl を使用してこれらの Web サイトにアクセスするクライアント アプリもあります。したがって、誰かが秘密の API 呼び出し ( FreeStaleDomObjectsFTW() ) を知っていれば、スタックのその端から利用できます。同様に有用であること。