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