2008-09-04 13 views
2

Nous avons utilisé "Drip" pour essayer d'identifier pourquoi les pages avec UpdatePanels ont tendance à utiliser beaucoup de mémoire côté client. Avec une page avec un postback régulier, nous voyons 0 fuites détectées par Drip. Toutefois, lorsque nous ajoutons un panneau de mise à jour au mélange, chaque objet DOM qui se trouve dans le panneau de mise à jour semble fuir (selon Drip).Est-ce que Microsoft ASP.NET Ajax provoque des fuites d'objets DOM?

Je ne suis pas certain que Drip soit assez fiable pour rapporter ce genre de choses - les fuites rapportées semblent indiquer que Drip modifie légèrement la page.

Quelqu'un a-t-il une expérience avec ceci? Devrais-je paniquer et cesser d'utiliser Microsoft Ajax? Je ne suis pas au-dessus de douter de Microsoft, mais il me semble louche qu'il pourrait être ce mauvais. De plus, si vous connaissez un outil meilleur que Drip, ce serait également utile.

Répondre

2

Selon ASP.NET AJAX in Action, p. Juste avant que l'ancien balisage ne soit remplacé par le code HTML mis à jour, tous les éléments DOM du panneau sont examinés afin de détecter les comportements ou les contrôles Microsoft Ajax qui y sont attachés. Pour éviter les fuites de mémoire, les composants associés aux éléments DOM sont éliminés, puis détruits lors du remplacement de HTMl. Donc, autant que je sache, tous les composants aspax asp.net dans le panneau de mise à jour sont disposés pour éviter les fuites de mémoire, mais tout ce qui s'y trouve sera simplement remplacé par le html reçu. Donc, si vous n'avez aucun composant asp.net ajax dans le conteneur cible pour la réponse, ce serait fondamentalement le même qu'un remplacement html interne avec toute autre requête js framework/ajax, donc je dirais que c'est juste la façon dont le navigateur gère cela, plutôt que l'ajax aj.net provoquant cela. De plus, bien qu'il puisse s'agir d'une "fuite", cela peut être dû à la conception, ce qui signifie que le navigateur n'a peut-être pas encore récupéré les éléments dom et les a libérés. En outre, le goutte-à-goutte peut causer ces fuites, car il s'attache à ces éléments dom.

0

C'est très probable. C'était à peu près ce que nous avons supposé (problème de navigateur, pas nécessairement Ajax). Notre problème est maintenant, avec cette application étant accessible par de nombreuses personnes via un environnement Citrix, chaque page créant continuellement des objets DOM et ne les libérant pas, l'environnement Citrix commence à se débattre après quelques utilisations. J'ai déjà vu des plaintes similaires en ligne (en particulier lorsque vous êtes assez stupide pour accéder à un site web Ajax via Citrix), mais cela ne me fait pas beaucoup mieux sentir que c'est le comportement voulu.

Je me demande maintenant si quelqu'un a trouvé une solution astucieuse. Nous avons également une application client où nous utilisons le .NET BrowserControl pour accéder à ces sites Web, plutôt que simplement IE7, donc si quelqu'un connaît un appel d'API secrète (FreeStaleDomObjectsFTW()), nous pouvons utiliser à partir de cette extrémité de la pile, ce serait utile aussi.