Улучшите производительность страницы ASPX с помощью сеток Telerik

Мой вопрос связан с повышением производительности страницы aspx. Поэтому, прочитав этот пост, прокомментируйте, возможно ли вообще улучшить производительность этой страницы.

Вот сценарий.

Я работаю над одним веб-приложением asp.net со следующими инструментами

  1. .Нет 3.5
  2. Типизированный набор данных (10 таблиц)
  3. IE 8 Compatibility View-IE7 Standards (приложение не работает в FF, Chrome или любом другом браузере)
  4. Телерик РадКонтролс. (сетка, числовые текстовые поля, выпадающие списки с автозаполнением)
  5. Кэш структуры приложения.
  6. Jquery и другие специфичные для страницы javascripts.

Страница ASPX содержит

  1. 8 сеток (из них 6 сеток телерика и 2 таблицы html)
  2. Все сетки телерика имеют определенные шаблоны EditFormTemplates.
  3. Много элементов управления (я не знаю, сколько элементов управления действительно используется, поэтому я не очень заинтересован в очистке страницы aspx, так как это может потребовать больших усилий dev/qa, что, к сожалению, сейчас не вариант.)
  4. Много javascript внутри RadScriptBlock. (У нас также есть javascrtip, который возится с шириной и другим пользовательским интерфейсом сеток)
  5. ViewState включен для всех сеток и элементов управления на странице.

Операции с этими сетками: Вставить, Обновить, Удалить, Копировать, Удалить все.

Все эти операции выполняются через частичные обратные передачи.

Обращений к базе данных не так много, так как большая часть данных кэшируется в appfabric.

Это может показаться странным, но на этой единственной странице тысячи строк кода. Приблизительно 30 тыс. строк в коде позади, 5 тыс. строк в jS и около 4 тыс. строк (вместе html/js) на странице aspx. В коде есть сложная логика, которая выполняется при загрузке страницы, а также при каждой частичной обратной публикации, и большинство сеток перепривязываются (редактируются) почти при каждой обратной передаче.

Что мы сделали для повышения производительности (что не очень помогло). Примечание. Повторное переписывание всей страницы было невозможно, поэтому все улучшения должны были быть внесены в эту страницу.

  1. Минимизированы все javascripts, CSS
  2. Добавлены все скрипты в коллекцию скриптов менеджеров Radscript (не знаю, поможет ли это в любом случае, но мне сказали это сделать.)
  3. Перемещен весь javascript, написанный на aspx, в файлы js из RadScriptBlock.
  4. Рефакторинг большого количества кода и минимизация использования appfabric (push, get).
  5. RadCompression уже реализован.
  6. Все грид-системы используют пейджинг сервера (5 записей на странице).

На странице почти нет статического содержимого. Кэширование страниц, кэширование фрагментов невозможно, учитывая использование этой страницы.

Не знаю, удивит ли это кого-то, но операции частичной обратной передачи на этой странице занимают около 4-6 секунд (запрос+ответ+рендеринг). Я думаю, что это довольно быстро, глядя на код, работающий в фоновом режиме. Но клиент так не считает.

Ожидается, что любая операция на странице не должна занимать более 1-1,5 секунд.

Вопросы

  1. Можно ли получить такое повышение производительности, глядя на инфраструктуру, используемую на этой странице?
  2. Если это вообще возможно, какие вещи мне не хватает и что могло бы улучшить работу страницы.
  3. Я видел, что ItemCreated и ItemDatabound каждой сетки вызываются гораздо чаще, чем RowCount. Я знаю, что это вызывается для каждого элемента, т.е. заголовка, нижнего колонтитула и элементов, но если у меня количество строк равно 5, почему эти методы вызываются более 10 раз?
  4. Я видел в коде, что разработчики использовали метод Rebind() как сумасшедший (может быть, это причина для # 3). Может ли кто-нибудь сказать мне, как правильно и в каком месте вызывать Rebind? Я знаю, что сетки Telerik неявно вызывают повторную привязку для вставок, но в каком сценарии нам нужно явно вызывать повторную привязку?

Я пытаюсь просмотреть всю кодовую базу и найти узкие места.

Я был бы очень признателен, если бы кто-нибудь дал мне какой-либо совет, который я готов попробовать в коде.

Дайте мне знать, если потребуется дополнительная информация.

Спасибо.

ИЗМЕНИТЬ

В дополнение к анализу я проверил состояние просмотра всей страницы, и оно составляет около 33 КБ. Кроме того, когда я удалил AjaxSettings со страницы, страница загружается довольно быстро за 2/3 секунды. Поэтому я чувствую, что Ajaxification страницы создает некоторую проблему при отображении страницы.

Я также зарегистрировал время серверного процесса, и это занимает около 1/2 секунды в зависимости от того, какая сетка находится в действии.


person Nilesh    schedule 09.04.2014    source источник
comment
Ознакомьтесь с этой статьей, в которой предлагаются методы оптимизации элементов управления Telerik AJAX: telerik.com/help/aspnet-ajax/   -  person Rumen Jekov    schedule 17.07.2014


Ответы (2)


После долгих анализов и копания в разных слоях мы обнаружили, что виновата была пара хранимых процедур. Также были идентифицированы ненужные вызовы процедур, что немного замедляло работу страницы. Исправление, которое дало нам хороший прирост производительности. Также нам пришлось внести некоторые изменения в события рендеринга сетки.

Не уверен, что этот ответ поможет кому-то в будущем, но я надеюсь, что, по крайней мере, он даст некоторые указания. Dynatrace очень пригодился в этом упражнении.

person Nilesh    schedule 20.08.2014

У меня есть примеры, когда доступ к данным Telerik был настроен неправильно, что приводило к сотням отдельных SQL-запросов для заполнения элемента управления вместо выполнения одного запроса, который извлекал все данные сразу. Вместо того, чтобы повторять все шаги, которые мы предприняли для анализа и исправления, я надеюсь, что все будет в порядке, если я просто опубликую ссылку на сообщение в блоге, которое я написал об этом: http://apmblog.dynatrace.com/03/04/2014/database-access-patterns-gone-wild-inside-telerik-sharepoint-and-asp-net/

person Andreas Grabner    schedule 11.02.2015