Pregunta

Hemos estado usando "Drip" para intentar identificar por qué las páginas con UpdatePanels tienden a utilizar mucha memoria del lado del cliente.Con una página con una devolución de datos regular, vemos 0 fugas detectadas por Drip.Sin embargo, cuando agregamos un panel de actualización a la mezcla, cada objeto DOM que está dentro del panel de actualización parece tener fugas (según Drip).

No estoy seguro de que Drip sea lo suficientemente confiable como para informar este tipo de cosas; las filtraciones reportadas parecen indicar que Drip está modificando ligeramente la página.

¿Alguien tiene alguna experiencia con esto?¿Debería entrar en pánico y dejar de usar Microsoft Ajax?No estoy por encima de dudar de Microsoft, pero me parece sospechoso que pueda ser este malo.

Además, si conoce una herramienta que sea mejor que Drip, también sería útil.

¿Fue útil?

Solución

De acuerdo a ASP.NET AJAX en acción, pag.257

Justo antes de que el código antiguo se reemplace con el HTML actualizado, todos los elementos DOM en el panel se examinan en busca de comportamientos de Microsoft Ajax o controles adjuntos a ellos.Para evitar pérdidas de memoria, los componentes asociados con los elementos DOM se eliminan y luego se destruyen cuando se reemplaza el HTML.

Hasta donde yo sé, todos los componentes de asp.net ajax dentro del panel de actualización están eliminados para evitar pérdidas de memoria, pero cualquier otra cosa allí simplemente se reemplazará con el html recibido.

Entonces, si no tiene ningún componente ajax de asp.net en el contenedor de destino para la respuesta, sería básicamente lo mismo que un reemplazo interno de html con cualquier otra solicitud js framework/ajax, por lo que diría que es solo el cómo. el navegador maneja esto, en lugar de que asp.net ajax cause esto.

Además, si bien puede haber una "filtración", puede ser por diseño, lo que significa que es posible que el navegador aún no haya recuperado los elementos dom ni los haya liberado.Además, el goteo podría estar provocando fugas, ya que se adhiere a esos elementos dom.

Otros consejos

Eso es muy probable.Esto fue más o menos lo que asumimos (problema del navegador, no necesariamente Ajax).

Nuestro problema ahora es que, como muchas personas acceden a esta aplicación a través de un entorno Citrix, y cada página crea continuamente objetos DOM y no los publica, el entorno Citrix comienza a fallar después de algún uso.He visto quejas similares en línea (especialmente cuando eres lo suficientemente tonto como para acceder a un sitio web Ajax a través de Citrix), pero no me hace sentir mucho mejor que este sea el comportamiento previsto.

Ahora me pregunto si a alguien se le ha ocurrido una solución inteligente.También tenemos una aplicación cliente en la que utilizamos .NET BrowserControl para acceder a estos sitios web, en lugar de simplemente IE7, por lo que si alguien conoce una llamada API secreta (FreeStaleDomObjectsFTW()) podemos utilizar desde ese extremo de la pila, eso también sería útil.

podrías adjuntar al Evento pageLoading de la clase PageRequestManager y revise los paneles actualizando la propiedad y elimine los elementos DOM en cada uno.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top