Измерение времени отклика для веб-приложения IIS
У меня есть веб-приложение dot net, и я хотел бы измерить время отклика. В настоящее время у меня есть две меры. "Внутренняя" мера выполняется в самом веб-приложении. "Внешняя" мера - это время возврата клиента от клиента (включая задержку в сети и т. Д.).
Очевидно, что внутреннее время отклика всегда меньше, чем внешнее время отклика, иногда довольно значительно.
Я хочу еще одну (возможно, более 1) меру, которая находится между этими двумя измерениями. Как бы я провел такие измерения? Например, мера, которая игнорирует время передачи по сети, но запускается, как только запрос попадает на сервер / IIS / мой пул приложений / и т. Д.
К сожалению, у меня недостаточно знаний IIS, чтобы даже прояснить этот вопрос, не говоря уже о том, чтобы ответить на него сам.
Изменить: некоторая дополнительная информация
Веб-приложение является механизмом вычисления AC#. Нет доступа к базе данных, нет пользователей. Приложение предоставляет конечную точку WCF. Время отклика довольно постоянное и составляет около 200 мс, но иногда оно достигает пика, и я обеспокоен именно этими пиками. Одним из источников всплесков является перезапуск пула приложений (каждые 29 часов), но мы можем запланировать это.
Я измеряю производительность от клиента на самом сервере, чтобы обойти сеть. Это устраняет многие шипы, но не все. Я использую нагрузку при загрузке процессора 30% сервером. Использование клиентского процессора незначительно.
4 ответа
Я хочу еще одну (возможно, более 1) меру, которая находится между этими двумя измерениями. Как бы я провел такие измерения?
Если у вас есть доступ к разработчикам, которые создали это приложение, попросите их написать небольшой пакет инструментария (не блокирующий!), Который позволяет вам напрямую извлекать этот счетчик из приложения.
Если вы не можете, вам нужно будет начать отладку самого приложения, чтобы определить, как долго и где оно тратит время на выполнение.
Поскольку это Windows-машина, вы можете начать с монитора процессов, чтобы получить общее представление о том, что происходит во время каждого запроса. Затем вы можете перейти на более надежные средства отладки, такие как windbg logger.exe.
Похоже, вы ищете инструмент управления производительностью приложений. Существует несколько приложений для.NET, и в зависимости от инструмента и вашего бюджета вы можете оценить производительность отдельных веб-запросов, получить трассировку транзакций до конкретных строк кода, отловить ошибки приложений, сопоставить производительность подсистем сервера (диск, процессор, память).), отслеживать производительность зависимостей (уровни / механизмы кэширования, внешние веб-сервисы, базы данных) и многое, многое другое.
Некоторыми распространенными инструментами APM, которые приходят, чтобы найти и приступить к дальнейшим исследованиям, являются Dynatrace, AppDynamics, New Relic и Lean Sentry.
Имейте в виду, что простая покупка одного из этих инструментов ничего не решит для вас. Вам нужно будет нанять эксперта или изучить инструмент (ы) достаточно хорошо, чтобы собрать действенную информацию, но вы, вероятно, получите гораздо больше деталей, которые просто не "видны", когда вы отслеживаете извне приложения без каких-либо хуков / apis / etc, раскрывающие часть того, что происходит под капотом.
Быстро и просто: начните измерение непосредственно на том же сервере или (если вы боитесь последствий нагрузки) в той же сети (обычно в демилитаризованной зоне, где расположен сервер вашего веб-приложения).
На самом деле вы узнаете о различных факторах производительности веб-приложений:
- Чистое время ответа вашего приложения (только ваше приложение, только один пользователь)
- Общее время отклика вашего приложения (включает приложение; стек веб-сервера; несколько пользователей; одновременный доступ к вашим источникам данных, устройствам и сети)
Здесь абсолютно нормально видеть различия. Измерение было бы сомнительным, если нет.
Однако, если вы хотите избежать ошибок измерения, вызванных различной скоростью сети, пропускной способностью, проблемами на стороне клиента и т. Д., Начните измерение общего времени отклика на локальном узле (и отметьте результаты в соответствии с этим) или увеличьте количество точек измерения (клиенты), сроки измерения и подсчитать среднюю сумму (для этого вы можете создать свой собственный JavaScript или использовать существующие инструменты, например, Google Analytics).
Похоже, работа для счетчиков производительности. Если вы нажмете на Пуск -> Выполнить -> Perfmon.msc, то в приложении, которое запускается, вы можете добавить все виды мониторинга для различных аспектов IIS и системы. Он должен быть в состоянии дать вам окончательные ответы на запросы IIS, включая то, сколько времени они потратили на ожидание обработки и сколько времени они обрабатывали.
Это также позволит вам сохранить их в файл или БД, если вы хотите регистрироваться в течение более длительных периодов.
Вы говорите, что процессор работает на 30%. Это многоядерный компьютер? Если у него 4 ядра и ваш код не распараллелен, то вы можете страдать от перегрузки процессора, даже если он не выглядит таким образом.