ASP.Net чрезмерное использование пользовательских элементов управления

Question

Я изучаю веб-приложение asp.net, которое широко использует элементы управления пользователями на каждой странице. На большинстве страниц содержится около 10-20 пользовательских элементов управления. Элементы управления пользователя, по-видимому, являются визуальным представлением бизнес-объектов (если это имеет смысл), хотя и с более тонкой детализацией, такой как каждая вкладка элемента управления вкладки, имеющего его содержимое в пользовательском элементе управления. Сам проект имеет более 200 пользовательских элементов управления (файлы ascx).

Производительность приложения очень плохая (и причина, по которой я расследую). Для каждого события (например, для выбора щелчка или выпадающего меню и т. Д.) Требуется около 5 секунд для загрузки страницы (10 секунд в визуальной студии). Приложение не использует Ajax.

Отслеживание является болезненным, поскольку сами страницы aspx не имеют кода в коде, поскольку пользователь контролирует все это, поэтому для отслеживания одной страницы требуются инструкции трассировки во всех элементах управления пользователя, которые находятся на этой странице.

На самом деле я считаю, что каждый пользовательский контроль за своим бизнес-кодом и его повторное использование - это умная идея, но чрезмерное использование пользовательских элементов управления приведет к поражению производительности? Это похоже на структуру приложения asp.net, написанного кем-то с сильным фоном WinForms?

EDIT
думал, что я должен добавить, что я не подвергаю сомнению использование пользовательских элементов управления (или даже сумма), но просто ли имея так много на странице, что все достижения вещи (каждый пользовательский элемент управления подключается к база данных, например), как правило, вызывают проблемы с производительностью ... Например, если только один пользовательский элемент управления postback делает что-то, что касается обработки всех остальных, некоторые из них видны, а некоторые нет ... @ Дэвид Макьюинг отметил, что у него было 40 оптимизированных пользовательских элементов управления и т. д., но если разработчик был основан на WinForms или «не знаком с asp.net», то как они будут следить за тем, чтобы каждый из них был оптимизирован ...

EDIT2
После получения трассировки оператора sql те же вызовы данных выполняются 5-6 раз на страницу для каждого события, так как разные пользовательские элементы управления требуют данных, которые не хранятся обычно, например. каждый пользовательский элемент управления на вкладке (упомянутый выше) делает тот же вызов, чтобы заполнить объект из базы данных ... Я действительно не здесь, чтобы обвинять пользовательские элементы управления в том, что проблема (я должен удалить вопрос?), как ясно проблема это НЕ пользовательский контроль, но с использованием их в этом конкретном случае ... который, я считаю, чрезмерен!

Answer 1

10-20 (или даже сотни) Элементы управления пользователя не могут быть тривиальными. Наличие самих элементов управления и идея инкапсуляции, безусловно, не являются источником ваших проблем.

Это невозможно сказать точно, что проблема фактически не профилировать приложения, конечно, но, основываясь на моем опыте, я могу сказать следующее:

Что более вероятно, является конкретной реализацией бизнеса логика внутри каждого пользовательского элемента управления неудовлетворительна. Если вы возвращаете сообщения после того, как вы описали, каждый элемент управления, вероятно, обращается к вашему DAL для собственных данных по каждому запросу. Это может быть смягчено двумя вещами:

• Убедитесь, что пользовательские элементы управления кэшировать все свои данные на первой загрузки и никогда повторно загрузить его, если явно не указано в (как правило, событие от службы более низкого уровня)
• Убедитесь, что все элементы управления используют набор общих служб, которые могут повторно использовать данные. Например. если два элемента управления нуждаются в доступе к списку клиентов, и они выполняются в контексте того же сеанса запроса, для которого требуется только один поиск в списке клиентов.

Answer 2

Я полагаю, что вы не знакомы с приложениями, в которых используется столько пользовательских элементов управления?

Похоже, вы можете перейти к выводу, что этот незнакомый аспект приложения является причиной незнакомой плохой производительности. Вместо того, чтобы делать предположения, почему бы не попробовать один из следующих средств профилирования, а также выяснить:

• JetBrains' dotTrace
• Red-Gate ANTS
• Automated QA's AQTime

Все это может сделать память и CPU профилирование ASP .NET.

Answer 3

Я считаю, что одной из ключевых целей UserControls является повторное использование кода. То есть, если одна и та же функциональность возникает на нескольких веб-страницах, тогда лучше создать для нее UserControl.Это не только позволяет разработчику писать (или копировать и вставлять) один и тот же код на несколько веб-страниц, но это также упрощает обслуживание. Любые изменения, внесенные в UserControl, автоматически применяются везде, где используется UserControl. Разработчику обслуживания не нужно беспокоиться о поиске всех разных мест, которые необходимо изменить кодексу.

Я не уверен, что однопользовательский UserControl эффективен. Они инкапсулируют и разделяют код, который хорош на загруженной веб-странице.

Можете ли вы проверить, используются ли ваши UserControls повторно или многие из них используются только один раз.

Answer 4

Я согласен с Сондерсом в том, что вы делаете некоторые профилирования, чтобы определить влияние определенных вещей.

Обратите внимание, что вы можете получить некоторые бесплатные стресс-тестирования инструментов для IIS здесь: http://support.microsoft.com/kb/840671

скажу, однако, что наличие слишком много элементов управления, вероятно, не очень хорошая вещь, ИМХО. Не зная больше, я бы предположительно сказал, что 20 слишком много.

Answer 5

Я стану твердо в лагере людей, которые предполагают, что нет жестких ограничений для ряда пользовательских элементов управления, которые должны использоваться на странице. Похоже, что трассировка на уровне приложения используется здесь, а не трассировка на уровне страницы. Вполне может быть, что некоторые из этих элементов управления вызывают проблему. Черт, это может быть единственный контроль, вызывающий всю суету. Однако, поскольку невозможно сделать какое-либо предположение об уровне использования ресурсов, что «средний» (если есть такая вещь) контроль пользователя занимает, то также невозможно предложить лимит. В противном случае мы сможем получить аналогичные ограничения на количество членов класса или количество хранимых процедур в базе данных.

Теперь, если мы говорим о 20 сложных пользовательских элементах управления, каждый из которых извлекает свои собственные данные с каждым обновлением, и каждый из них имеет кучу суб-элементов управления, используя ViewState, независимо от того, нужен он или нет, тогда да, это проблема. Тем не менее, это больше связано с общим дизайном, чем с наличием слишком большого количества элементов управления.Если, с другой стороны, они создали общий пользовательский элемент управления, чтобы действовать как нечто большее, чем композит метки слева от текстового поля (или, может быть, даже каждая комбинация ярлыка + пользовательский элемент управления) и посыпали это во всем приложении, я могу себе представить, что вы получите кучу этих страниц на странице, и я не понимаю, почему это может повредить что-либо.