Domanda

Abbiamo utilizzato "Drip" per cercare di identificare il motivo per cui le pagine con UpdatePanels tendono a utilizzare molta memoria lato client.Con una pagina con un postback regolare, stiamo riscontrando 0 leak rilevati da Drip.Tuttavia, quando aggiungiamo un pannello di aggiornamento al mix, ogni singolo oggetto DOM che si trova all'interno del pannello di aggiornamento sembra perdere (secondo Drip).

Non sono sicuro che Drip sia abbastanza affidabile da segnalare questo tipo di cose: le fughe di notizie segnalate sembrano indicare che Drip sta modificando leggermente la pagina.

Qualcuno ha qualche esperienza con questo?Dovrei farmi prendere dal panico e smettere di usare Microsoft Ajax?Non ho dubbi su Microsoft, ma mi sembra sospetto che possa esserlo Questo Cattivo.

Inoltre, se conosci uno strumento migliore di Drip, anche questo sarebbe utile.

È stato utile?

Soluzione

Secondo ASP.NET AJAX in azione, P.257

Poco prima che il vecchio markup venga sostituito con l'HTML aggiornato, tutti gli elementi DOM nel pannello vengono esaminati per individuare comportamenti o controlli Microsoft Ajax ad essi collegati.Per evitare perdite di memoria, i componenti associati agli elementi DOM vengono eliminati e quindi distrutti quando viene sostituito l'HTML.

Quindi, per quanto ne so, tutti i componenti asp.net ajax all'interno del pannello di aggiornamento sono disposti per prevenire perdite di memoria, ma qualsiasi altra cosa contenuta verrà semplicemente sostituita con l'HTML ricevuto.

Quindi, se non disponi di componenti asp.net ajax nel contenitore di destinazione per la risposta, sarebbe sostanzialmente lo stesso di una sostituzione html interna con qualsiasi altra richiesta js framework/ajax, quindi direi che è proprio come il browser gestisce questo, anziché asp.net ajax che lo causa.

Inoltre, anche se potrebbe esserci una "perdita", potrebbe essere dovuto alla progettazione, il che significa che il browser potrebbe non aver ancora recuperato gli elementi dom e non averli rilasciati.Inoltre, il gocciolamento potrebbe causare perdite, poiché si attacca a quegli elementi della cupola.

Altri suggerimenti

E' molto probabile.Questo era più o meno quello che avevamo ipotizzato (problema del browser, non necessariamente Ajax).

Il nostro problema è ora, con questa applicazione a cui accedono molte persone tramite un ambiente Citrix, con ogni pagina che crea continuamente oggetti DOM e non li rilascia, l'ambiente Citrix inizia a funzionare male dopo un certo utilizzo.Ho visto lamentele simili online (specialmente quando sei abbastanza stupido da accedere a un sito Web Ajax tramite Citrix), ma non mi fa sentire molto meglio che questo sia il comportamento previsto.

Ora mi chiedo se qualcuno ha trovato una soluzione intelligente.Abbiamo anche un'app client in cui utilizziamo .NET BrowserControl per accedere a questi siti Web, anziché solo IE7, quindi se qualcuno conosce una chiamata API segreta (FreeStaleDomObjectsFTW()) possiamo utilizzare da quell'estremità dello stack, anche questo sarebbe utile.

potresti allegare al file evento pageLoading della classe PageRequestManager e passa attraverso i pannelli aggiornando la proprietà e rimuovi gli elementi DOM in ciascuno.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top