Frames IE6 y fuga de memoria

Antes de comenzar esta pregunta, entiendo que todos los aspectos son incorrectos. Por favor tenlo en mente...

Tengo una aplicación de intranet tipo CRM con un softphone integrado desarrollado en 2001 que he heredado. Es básicamente una aplicación de cobros que integra controles de telefonía con un front-end basado en web para la gestión de cuentas. (Telefonía Genesys y un sistema de cobranzas basado en AS400... usando MQSeries)

Estoy tratando de modernizar esta aplicación tanto como me sea posible antes de llamarla "final de la vida útil". Como parte de mis intentos de modernizarlo, implementé jQuery y jQuery UI para mi funcionalidad y UI de JS. No me estoy volviendo loco con eso, pero está bastante bien arraigado.

Ahora, ingrese el problema: actualmente usamos IE6 y la aplicación se construye usando marcos. La implementación de las bibliotecas jQuery ha expuesto la naturaleza similar a un tamiz de la aplicación desde la perspectiva de la memoria. Actualmente consume alrededor de 75 Mb de memoria en el inicio y crece a cualquier lugar entre 150 Mb y 300 Mb después de aproximadamente 2 a 3 horas. Entonces el navegador falla.

Reduje las fugas de memoria a la conversación cruzada entre los marcos. He probado las páginas individualmente en sIEve y Drip y no se han encontrado fugas. Pero acceda a las páginas dentro del conjunto de marcos y es una bomba de tiempo.

Sé que la respuesta es rediseñar la aplicación sin marcos y empezar a usar un navegador mejor. Hay dos problemas con eso:

  1. Probé esto en IE9 y los problemas siguen ahí, pero un poco más controlados

  2. Rediseñar la aplicación tomaría alrededor de $500k y de 6 a 12 meses.

¿Alguien sabe una manera de resolver el problema de "fuga de marco"? Sé que no he dado ningún ejemplo de código, pero solo estoy buscando conocimientos generales. Estoy llamando al IE CollectGarbage() método de carga y descarga para cada página de la aplicación, pero fue en vano. He intentado llamar al empty() método en jQuery. He intentado configurar a todos los niños de la document.body elemento para null. Nada está funcionando.

Odiaría tener que retirar todos estos cambios porque en realidad se han implementado algunas características de reducción de costos bastante grandes.

INFORMACIÓN ADICIONAL

Me las arreglé para identificar el escenario en el que ocurren las fugas de memoria. Pensé que era una "conversación cruzada" entre cuadros, pero parece que las fugas de memoria ocurren cuando se actualiza un solo cuadro.

Configuré un conjunto de marcos básico con 5 instancias de la misma página (una que estoy bastante seguro de que no tiene fugas por tamiz).

<html>
    <head>
        <title>Frame Leak Test</title>
    </head>
    <frameset cols="*" rows="50%,50%" frameborder="1">
        <frameset cols="33%,33%,34%" rows="100%">
            <frame src="http://npasappgeneqa02/live/" />
            <frame src="http://npasappgeneqa02/live/" />
            <frame src="http://npasappgeneqa02/live/" />
        </frameset>
        <frameset cols="50%,50%" rows="100%">
            <frame src="http://npasappgeneqa02/live/" />
            <frame src="http://npasappgeneqa02/live/" />
        </frameset>
    </frameset>
</html>

La página de índice que se está cargando no muestra fugas en sIEve.

Cuando cargo la página del conjunto de marcos en sIEve y hago clic en actualizar automáticamente, no se informan pérdidas de memoria. Sin embargo, si hago clic derecho -> actualizar en un marco individual, el 75% de los elementos cargados en el DOM se enumeran como fugas.

Obviamente, la actualización automática es equivalente a la actualización F5/shift+F5. Y eso limpia la memoria de la página. Pero cuando se recarga un cuadro individual, la memoria nunca se borra... aparentemente. Y cada pantalla que mis usuarios tienen que ver se recarga en el marco principal.

No puedo simplemente actualizar el conjunto de marcos porque hay un softphone en el conjunto de marcos que provocará el Armagedón si se actualiza o se desconecta incorrectamente.

¿Alguien sabe de una forma de controlar la memoria del conjunto de marcos sin actualizarla?

preguntado el 09 de marzo de 12 a las 14:03

Por incluir las más diferentes formas posibles de maldad en una sola publicación del día y saberlo, ganas un voto a favor. Felicidades. Y siento que tengas que aguantar esto :( -

sencha.com/forum/… parece alguien que encontró una solución a un problema similar. ¿Quizás eso ayudaría? Igualmente, stackoverflow.com/questions/2312800/ie6-memory-leak-on-refresh parece que id podría tener algunas ideas pertinentes, específicamente las de asegurarse de que IE6 esté completamente parcheado y escribir el javascript desde cero en lugar de depender de JQuery. -

@BoltClock - Gracias por la simpatía. Estoy tentado a separar esto y configurarlo todo en iframes y llamadas AJAX. -

No tengo una respuesta, solo quiero que sepas que me siento mal por ti. -

+1 para una pregunta de alta calidad, lúcida y bien explicada. (¡Ah, y buena suerte!) -

3 Respuestas

No publicó ningún código para juzgar esto... pero muchos de estos escenarios resultan del uso inadecuado de los cierres.

La lectura incluye, pero no se limita a:

contestado el 23 de mayo de 17 a las 13:05

@Prizoner ZERO: no publiqué el código porque el problema es sistémico. Además, dado que es una aplicación de intranet personalizada, estoy limitado. Pero tu punto está bien tomado. Los únicos cierres introducidos son los inherentes a jQuery. Podría regresar y manejar los eventos yo mismo, pero no creo que eso cambie mucho. Gracias por las referencias. - doug tejedor

Busque situaciones en las que pueda vincular (o volver a vincular) los mismos eventos para un solo control varias veces sin desvincular primero dicho control... esto es más común de lo que piensa. - Prisionero CERO

Suena lógico. Le daré un vistazo. Gracias. - doug tejedor

Solo quería dar una actualización sobre esta situación particular. Creo que he encontrado una solución aceptable para este problema de pérdida de memoria:

  1. En lugar de usar la biblioteca jQueryUI completa en las páginas donde se necesitaban elementos de la interfaz de usuario, usé los scripts minimizados individuales (uicore + datepicker, etc.).
  2. Siempre que fue posible, evité los elementos de la interfaz de usuario que utilizaban la secuencia de comandos del widget, ya que aquí es donde surgía la mayor concentración de problemas.
    • una. Esto hizo que tuviera que escribir scripts personalizados para button elementos y el accordion elemento.
  3. Dado que esta aplicación se ejecuta en un frameset, utilizando window métodos (es decir, window.onload, window.onunload) no funcionan ya que la ventana en sí solo carga o descarga con el frameset. Para combatir esto, implementé document.body métodos, específicamente, document.body.onbeforeunload y haciendo un desvinculado global para eliminar cualquier referencia que estuviera pasando el rato ($("*").unbind();).

Con la metodología utilizada anteriormente, mi consumo de memoria de 4 horas en IE6 (e IE8) se redujo de ~200-250Mb a ~80-95Mb. Mi objetivo era mantener el consumo de 8 horas por debajo de 150 Mb y creo que esto cumplirá la tarea.

Gracias a todos por toda su ayuda.

Respondido 26 Abr '12, 20:04

Sugeriría ejecutar su código JS a través de cualquiera JSLint or JSHint.

Estas dos utilidades (*) son verificadores de calidad de código para Javascript. Las cosas de las que se quejan son donde el código JS es válido pero contiene malas prácticas de programación.

Es muy probable que detecten al menos algunas de las cosas que le están causando problemas.

(* JSHint es una bifurcación de JSLint, pero son lo suficientemente diferentes ahora que vale la pena probarlos a ambos)

Respondido 08 Abr '12, 22:04

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.