Какие ключевые мониторы производительности следует отслеживать для приложения ASP.NET

Question

У меня есть сайт, который получает 5 миллионов запросов в день. В тяжелые дни страницы возвращаются около 10 секунд. Я также получаю из памяти исключения. Я читал Улучшение производительности и масштабируемости приложений .NET от Microsoft и вижу, что есть много метрик, которые я мог бы посмотреть. Мой вопрос:

Какие основные счетчики, которые я должен наблюдать, будут:

• Скажите, где тратятся 10 секунд
• Скажите, где память б

это приложение ASP.NET 2.0, работающее на Win2003 с IIS6

Answer 1

Поскольку количество запросов в день составляет около 5 миллионов записей, и оно растет,

Я бы предложил следующее:

Клиентская сторона

Получить Fiddler и получить показания количества запросов на страницу и времени их оборота. Сделайте это для первого запроса и последовательных запросов. В идеале вы должны выбрать данные для 5 первых запросов и 5 последовательных запросов, прежде чем выбирать данные и делать из них выводы.

Параметры для чтения:

• Сколько запросов на странице происходит?
• Сколько их может быть кешируется?
• Ресурсы узкого места?

Серверная сторона

Чтобы определить время поворота на стороне сервера, я бы предложил Ayendes, Rhino.HttpModule или что-то еще, я точно не помню. Это дает время обработки страницы на стороне сервера.

Параметры для чтения из него:

• Это проблема на стороне сервера или на стороне клиента?

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

На последнем замечании, я думаю, вы можете покончить с любыми изменениями в вашем коде. Потому что вы предполагаете, что под нагрузкой время оборота составляет около 10 секунд. Смотрите, браузер не может запрашивать более 6 (+/- 2) ресурсов одновременно. Итак, что-то под нагрузкой загружает ваш веб-сервер. Смоделируйте ситуацию и увидите, что количество запросов Team Foundation System должно помочь. Кроме того, Отчеты IIS могут предоставлять запросы на стороне сервера. Посмотри на них. Они могут дать вам четкую картину.

Надеюсь, это поможет.

Answer 2

По KPI:

Некоторые уже упоминали об этом в других ответах. Я не помню настоящие названия счетчиков, но в целом: Количество запросов в секунду (Интернет) % Процессор (Web & SQL) Память GC (большая куча, поколение 0, 1, 2) Коэффициент попадания в кэш для вашего SQL Server Длина очереди диска (Web и, что более важно, ваш SQL) любой счетчик, связанный с блокировкой и взаимоблокировкой в ​​SQL

При получении ответа на ваши вопросы выше:

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

Инструменты, с которыми вы хотите ознакомиться, чтобы ответить на эти вопросы: .NET Profiler (для профилирования вашего кода ASP.NET) .NET CLR Profiler (для профилирования использования памяти)

Но, тем не менее, сначала создайте веб-тесты (вы можете легко сделать это с Fiddler для начала) и настройте их далее (чтобы можно было выполнять привязку данных) с VS и запустите нагрузочное тестирование с приближением к реальному представлению данных (в емкости) и количество пользователей. Из веб-тестов вы сможете определить, какая страница не работает. Затем углубитесь в профилировщики, чтобы выяснить, почему.

Вы уже на правильном пути, просматривая ScaleNet.pdf (или онлайн-версию). Это немного устарело, но все еще в силе. Продолжайте читать и применять то, что вы читаете там.

Answer 3

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

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

Но не будет волшебства "наблюдать за этим", чтобы решить вашу проблему. Решить проблемы масштабируемости сложно.

Answer 4

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

следующая статья - хорошее начало.

Answer 5

Если вы посмотрите на него с самого базового уровня, у вас есть только 4 основных момента:

• Диск
• CPU
• Память
• Сеть

Вы можете отслеживать это: Диск - это длина очереди, остальные -% загрузки.

Однако проблема может быть не в одном из них. Это может быть параметр конфигурации, который, например, устанавливает максимальное количество соединений. Хорошее место, чтобы начать искать их - журнал ошибок IIS или журнал событий.