Вопрос

Мы использовали "Drip", чтобы попытаться определить, почему страницы с панелями обновления в них, как правило, используют много памяти на стороне клиента.На странице с обычной обратной отправкой мы видим 0 утечек, обнаруженных Drip.Однако, когда мы добавляем панель обновления в микс, кажется, что каждый отдельный объект DOM, который находится внутри панели обновления, протекает (согласно Drip).

Я не уверен, что Drip достаточно надежен, чтобы сообщать о подобных вещах - сообщения об утечках, похоже, указывают на то, что Drip слегка изменяет страницу.

Есть ли у кого-нибудь какой-нибудь опыт в этом?Должен ли я запаниковать и прекратить использовать Microsoft Ajax?Я не прочь усомниться в Microsoft, но мне кажется подозрительным, что это могло быть это плохой.

Кроме того, если вы знаете средство, которое лучше, чем Drip, это тоже было бы полезно.

Это было полезно?

Решение

Согласно ASP.NET "АЯКС" в действии, стр.257

Непосредственно перед заменой старой разметки на обновленный HTML все элементы DOM на панели проверяются на предмет поведения Microsoft Ajax или прикрепленных к ним элементов управления.Чтобы избежать утечек памяти, компоненты, связанные с элементами DOM, удаляются, а затем уничтожаются при замене HTML.

Итак, насколько я знаю, любые компоненты asp.net ajax на панели обновления расположены для предотвращения утечек памяти, но все остальное там будет просто заменено полученным html.

Так что, если у вас их нет asp.net компоненты ajax в целевом контейнере для ответа, это было бы в основном то же самое, что внутренняя замена html любым другим запросом js framework / ajax, поэтому я бы сказал, что это просто то, как браузер обрабатывает это, а не asp.net ajax вызывает это.

Кроме того, хотя это может быть "утечка", это может быть сделано специально, что означает, что браузер, возможно, еще не восстановил элементы dom и не выпустил их.Кроме того, drip может быть причиной их утечки, поскольку он подключается к этим элементам dom.

Другие советы

Это очень вероятно.Это было в значительной степени то, что мы предполагали (проблема с браузером, не обязательно Ajax).

Наша проблема сейчас в том, что многие пользователи получают доступ к этому приложению через среду Citrix, поскольку каждая страница постоянно создает объекты DOM и не выпускает их, среда Citrix начинает работать с перебоями после некоторого использования.Я видел похожие жалобы в Интернете (особенно там, где вы достаточно глупы, чтобы получить доступ к веб-сайту Ajax через Citrix), но мне не становится намного легче от того, что это предполагаемое поведение.

Теперь мне интересно, придумал ли кто-нибудь разумный обходной путь.У нас также есть клиентское приложение, в котором мы используем .NET BrowserControl для доступа к этим веб-сайтам, а не просто обычный IE7, поэтому, если кто-нибудь знает секретный вызов API (FreeStaleDomObjectsFTW()) мы можем использовать с этого конца стека, это тоже было бы полезно.

вы могли бы прикрепиться к Событие загрузки страницы класса PageRequestManager и пройдите по свойствам обновления панелей и удалите элементы DOM в каждой из них.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top