Какие счетчики производительности ASP.NET лучше всего отслеживать?
В perfmon для ASP.NET есть масса счетчиков. Какие из них лучше всего (я думаю о выборе 5–10), которые лучше всего отслеживать в нашей тестовой среде, чтобы мы могли ответить разработчикам.
Я думаю о таких вещах, как время запроса, длина очереди запросов, активные сеансы и т. д.
Ответы 3
Для нормального (не тестирования производительности / стресс-тестирования) вам подойдет следующее:
- Всего байт запроса (очень важно, особенно для веб-приложений (не интранет))
- Запросы не выполнены
- Запросов / сек
- Ошибки при выполнении
- Ошибки, не обработанные во время выполнения
- Общее количество подключений к SQL-серверу за сеанс
- Активные сеансы государственного сервера
Для тестирования производительности вам, вероятно, понадобятся такие вещи, как:
- % Использования ЦП (убедитесь, что вы проверяете очень низкую загрузку ЦП, так как это может указывать на то, что что-то не работает)
- Запросы в очереди
- Обращения к выходному кешу
Могу ли я получить эти значения программно с помощью Powershell and WMI?
Чаще всего я использую счетчики памяти. Все они. Я знаю, что они не относятся к ASP.NET, но единственные проблемы, с которыми я когда-либо сталкивался с веб-приложением, были проблемы с памятью.
Чрезмерная куча, сборники второго поколения и% времени в сборке мусора являются наиболее важными. Если ваше время в GC выходит из-под контроля, это признак того, что ваш пользовательский интерфейс и состояние просмотра слишком велики. Большая куча и множество коллекций поколения 2 говорят о том, что вы храните слишком много вещей в памяти (например, состояние сеанса inproc).
Обычные приложения ASP.NET, основанные на веб-элементах управления, требуют создания большого количества объектов, которые затем быстро уничтожаются, поскольку страница реконструируется, а затем удаляется. Коллекции high gen0 - это неплохо. Когда вы начинаете видеть, что множество объектов попадает в gen1, а затем в gen2, это говорит о том, что вы либо утекаете память, либо удерживаете слишком много состояния.
Не могли бы вы уточнить свои цифры? Что такое «большая куча» и «много соединений поколения 2»?
Мой опыт такой же, как и у Уилла. Большинство проблем с производительностью веб-приложений asp.net, вероятно, связаны с памятью. % времени в GC имеет решающее значение для мониторинга. Трудно указать жесткие пороги для% времени в GC, но все, что в среднем превышает 15%, привлекло бы мое внимание. Должно быть намного больше коллекций Gen 0, чем Gen 1, и намного больше коллекций Gen 1, чем Gen 2. GC# Invoked должен быть 0 или очень маленьким. Если # Invoked GC близок к Gen 2 Collections, код явно вызывает GC.Collect, и приложение будет проводить большой% времени в GC. В GC все потоки приостановлены, так что это очень плохо.
Помните о счетчиках памяти при запуске нескольких пулов приложений ASP.NET проверить проблему на http://blog.dynatrace.com/2009/02/27/can-you-trust-your-net-heap-performance-counters/
Насколько важен (или даже полезен) общий объем запроса байтов? Это просто постоянно растущее количество всех отправленных байтов.