Назад | Перейти на главную страницу

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

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

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

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

Обновить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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