Профилирование использования ЦП веб-приложением ASP.NET - но не базы данных!

Я наблюдаю постоянно высокую загрузку ЦП для моего веб-приложения ASP.NET (естественно, только в рабочем производственном блоке ....!), И я пытаюсь сузить причину - в основном это максимальная загрузка четырехъядерного блока Xeon. и нет никакой возможности это сделать!

Использование ЦП веб-процессом обычно выше, чем у процесса БД, что само по себе вызывает у меня тревогу (?).

Однако использование стандартных инструментов профилирования (dotTrace, Red Gate и т. Д.) Показывает только время, потраченное на отдельные методы (а не фактическое использование ЦП), и, в конечном итоге, по-прежнему выделяет методы, привязанные к БД. Хотя это может указывать на возможности для кеширования или улучшения индексов, я не понимаю, как это само по себе приведет к высокой загрузке ЦП процессом веб-приложения?

Любые предложения или советы о том, как я могу сузить круг вопросов?

Спасибо!


asp.net performance profiling cpu cpu-usage
person James Crowley    schedule 14.07.2009    source источник
comment
Снижается ли загрузка ЦП, если вы повторно используете рабочий процесс Asp.Net?   -  person Justin    schedule 22.07.2009
comment
нет необходимости отключать Viewstate, вы можете уменьшить размер состояния просмотра, написав код в событии Application_BeginRequest файла Global.asax.   -  person    schedule 05.10.2011

Ответы (4)


arrow_upward
3
arrow_downward

Некоторые предложения попробовать в первую очередь.

1. Развертывание с помощью сборки выпуска Проверьте, находится ли развернутый продукт в режиме выпуска. При работе в режиме отладки много времени тратится на загрузку pdbs вместе со сборками.

2. Отключить ViewState Отключить состояние просмотра, если оно не требуется. ViewState - это не что иное, как данные, хранящиеся в скрытых полях, которые должны сохраняться между запросами. он увеличивает общую полезную нагрузку страницы как при обслуживании, так и при запросе. Также возникают дополнительные накладные расходы при сериализации или десериализации данных состояния представления, которые отправляются обратно на сервер. Наконец, состояние просмотра увеличивает выделение памяти на сервере.

3. отключение состояния сеанса:

Если вы не собираетесь его использовать, отключите состояние сеанса. По умолчанию он включен. Фактически вы можете отключить это для определенных страниц или для всего приложения.

Существует несколько базовых функций мониторинга производительности приложений ASP.NET, ознакомьтесь с этими двумя статьями MSDN " Мониторинг производительности приложений ASP.NET " и Счетчики производительности для ASP.NET

person Pradeep Kumar    schedule 22.07.2009
comment
Не забудьте также отключить режим отладки в файле конфигурации - person Itanex; 04.09.2013

arrow_upward
0
arrow_downward

Можете ли вы настроить несколько модульных тестов для вызова различных методов и посмотреть, как они влияют на использование процессора? В Visual Studio есть несколько встроенных инструментов тестирования, если вы используете Team System, но даже если вы этого не сделаете, вы можете написать многопоточный тестер для вызова определенных функций сотни раз.

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

person SqlRyan    schedule 19.07.2009

arrow_upward
0
arrow_downward

вы регистрируете / сообщаете о необработанном исключении? Если этого не сделать, и проверьте, соответствует ли какой-либо из них вашим высоким пикам CPD, у вас может быть переполнение стека, вызывающее пики.

http://msdn.microsoft.com/en-us/library/ms998306.aspx

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

person Damien McGivern    schedule 27.07.2009

arrow_upward
0
arrow_downward

Как отмечает Pradeepno, на самом деле лучше всего начать со счетчиков производительности - они могут дать вам очень хорошее представление о том, какая часть процессора потребляет.

Использование веб-приложения выше, чем использование БД, не совсем удивительно. Если у вас есть приличный дизайн БД, большинство веб-приложений вряд ли заставят прилично мощный сервер БД потеть.

person Wyatt Barnett    schedule 27.07.2009