IIS: как определить, связано ли медленное время с медленным подключением к сети

Согласно http://support.microsoft.com/kb/944884 , «когда большой ответ или большие ответы отправляются клиенту по медленному сетевому соединению, значение поля, занимающего время, может оказаться больше ожидаемого».

У меня есть ситуация, когда клиент скажет: «Я отправил запрос на ваш веб-сервер в 10:03:24, и это заняло 20 секунд, почему?». Я также вижу это в журналах IIS, но серверный модуль ASP.NET записал его как 100 мс, а счетчики ЦП и Диска были низкими.

Я подозреваю, что это связано с медленным подключением к сети. Как я могу доказать это?

Обновить:

1) Это запросы веб-службы SOAP, следовательно, нет встроенной графики, только HTTP POST с одной страницей результатов XML.

2) Кроме того, я воспроизвел это, ограничив скорость сети на стороне клиента, и симптомы точно такие же.

3) Проблема временная, то есть один и тот же запрос обычно быстрый для клиента, но иногда медленный. Я не могу воспроизвести это сам, кроме как путем дросселирования сети. Ведение журнала ASP.NET на сервере всегда показывает скорость, а в IIS - медленно, когда клиент говорит, что это медленно.

4) У меня есть доступ только к серверу, и я должен предоставить клиенту как можно больше информации, чтобы они согласились с тем, что проблема была не на сервере, и знают, какие журналы / инструменты запускаются на клиенте для поиска первопричины.

— Джон
источник

Являются ли эти запросы обычным просмотром страниц, требующим извлечения встраиваемой графики и т. Д.? Или это автоматизированные запросы, которые возвращают только одну страницу? Действительно ли мы измеряем время загрузки страницы или время ответа на один HTTP-запрос?

— Дэвид Шварц

Ответы:

У меня есть ситуация, когда клиент скажет: «Я отправил запрос на ваш веб-сервер в 10:03:24, и это заняло 20 секунд, почему?». Я также вижу это в журналах IIS, но серверный модуль ASP.NET записал его как 100 мс, а счетчики ЦП и Диска были низкими.

Я подозреваю, что это связано с медленным подключением к сети. Как я могу доказать это?

Он начинается с поиска пакетов пакетов между браузером вашего клиента и всеми источниками images / scripts / html для вышеупомянутой веб-страницы. Если вы обнаружите постоянные отбрасывания пакетов, то вы точно знаете, что в сети есть что-то, что необходимо исправить ... даже если это просто перегруженная ссылка. Отбрасывание пакетов - не единственная причина медленной сети, но это самый распространенный источник в моем опыте. Другими источниками могут быть неправильно настроенный прокси или механизм кэширования. К сожалению, я не могу перечислить всех возможных виновников сети здесь.

Однако люди часто обвиняют сеть, когда на самом деле проблемы со скоростью находятся в пределах их собственного контроля. Возможные объяснения:

Предположим, что HTML-код для этой страницы был написан плохо, и он загружает необходимые сценарии в неправильном порядке, поэтому вся страница отображается медленно, хотя почти все ресурсы были на месте.
Страница ожидает ресурс, который просто не существует, и время ожидания истекло.
Сценарий находится в медленном цикле, который на некоторое время блокируется
Механизм кеширования занимает много времени для доставки изображения
Ваш CGI ищет что-то в базе данных, а сам поиск идет медленно
Вы используете аналитику Google , которая замедляет работу из-за того, как написана страница

Я мог бы продолжить, но суть в том, что вы должны точно определить причину, по которой страница медленно работает самостоятельно. Возможна некорректная сеть; Также возможно, что другие факторы способствуют снижению производительности.

Для дальнейшей диагностики:

Если страница хорошо загружается в Firefox, то вкладка «Сеть» в Firebug - ваш друг (нажмите F12, затем перейдите на вкладку «Сеть» и перезагрузите страницу). Firebug дает вам хорошую диаграмму водопада о том, как страница загружается и где задержки
Если страница хорошо загружается в Chrome, вы можете сделать что-то подобное (нажмите CntlShiftI, нажмите на вкладку сети и перезагрузите страницу).
Если страница поддерживается только в IE (кстати, позор разработчикам HTML), лучше всего начинать загрузку каждого из этих элементов страницы ASP по отдельности, curlпока не найдете что-то, что выглядит слишком медленно, а затем выяснить, почему этот конкретный элемент медленный.

Кстати, примеры Chrome и Firefox использовали CGI-запрос от Debian.org ; Это хороший пример задержки, возникающей при поиске CGI.

Когда все остальное терпит неудачу, вы можете получить .pcapиз wireshark и пропустить его tcptrace; однако, хотя tcptraceон очень хорош при анализе дампов пакетов, нет никаких гарантий, что вы можете изолировать проблему с помощью tcptraceодной. Смотрите этот ответ для получения информации об использовании tcptraceдиагностики.

— Майк Пеннингтон
источник

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

— Джон

Водопадные диаграммы в Firefox / Chrome поддерживают почтовые операции http, а также curl ... Я не уверен, как вы пришли к выводу, что информация неприменима, но может показаться, что она не предполагает полного применения инструментов в проблемной области. ,

— Майк Пеннингтон

Firefox / Chrome являются инструментами на стороне клиента. У меня есть только доступ к серверу, и я не могу воспроизвести с помощью собственного клиента. Мне нужно сказать только с сервера, был ли конкретный запрос медленным из-за проблем с сетью. Это оставляет захват пакетов, но это слишком тяжело, чтобы его можно было использовать в производственном процессе (рассмотрим 1 из 10 000 запросов, которые могут выполняться медленно).

— Джон

Как сетевой инженер, у которого за плечами более 15 лет, могу ли я с уважением предположить, что вы не можете диагностировать проблему HTTP-служб на стороне клиента только с одного сервера; вам просто не хватает информации (что, по-видимому, и ваш вывод ... однако вы, похоже, не готовы жить с этой реальностью :-).

— Майк Пеннингтон

Если перехват пакетов на сервере может диагностировать проблемы в сети (например, с помощью медленного подтверждения TCP), не разумно ли ожидать, что более легкий инструмент / регистратор может показать то же самое?

— Джон

Результатом статьи 944884 в КБ является то, что фактическое время, необходимое для завершения ответа, может не быть точно отражено в журнале. Именно поэтому в статье упоминается сетевое время.

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

— Грег Аскью
источник

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

— Джон

Задержка в 20 секунд также может быть вызвана перезапуском IIS его файла w3wp.exe, который переходит в спящий режим, когда он не используется.

— Стив Роллинс
источник

Вы можете улучшить этот ответ, ответив «как сказать». В моем случае w3wp.exe не работает, так как я отключил это поведение, но это может помочь другим.

— Джон