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

Запросы в состоянии IIS «SendResponse» надолго зависали; Медленное веб-приложение IIS 7.5 / ASP.NET 4.0

У меня есть набор очень мощных, очень мало используемых серверов, на которых работает пара виртуальных машин с Windows Server 2008 R2 и IIS 7.5.

Эта проблема: Иногда обработка запросов занимает очень много времени. Пользователь видит, как его браузер вращается, очевидно, не получая ответа от IIS.

Некоторая статистика и попытки решения:

Нагрузка на серверы (хост и ВМ) незначительна. ЦП никогда не превышает 5%, доступно более 10 ГБ ОЗУ, все подключено через MPIO к быстрому SAN.
Я получаю от 30 до 50 запросов в секунду, смесь динамического и статического контента, только GET и POST. Большинство попаданий кэшируются (80% попаданий), поэтому нагрузка на структуру / SAN / IO практически равна нулю.
Разгрузка TCP отключена на хосте и виртуальной машине, как на сетевом адаптере, так и через отключение дымохода TCP.
Веб-приложения работают в интегрированном режиме ASP.NET 4.0. Они не совершают длительных вызовов сторонним веб-службам и т.п.
Я пробовал как processModel autoConfig, так и настройку maxWorkerThreads, maxConnections, maxIOThreads и т. Д. На очень высокие числа без разницы.
Все запросы к базе данных выполняются менее чем за 1 секунду. Я профилировал целый день и не уловил ни одного запроса, который занимал бы больше времени.
Я просмотрел тонны счетчиков монитора производительности; очереди ASP.NET и очереди приложений всегда пусты, кажется, что ничего не ставится в очередь (что в любом случае не имеет смысла, учитывая, что сервер вообще не потеет)
Я обнаружил, что с помощью запросов списка appcmd иногда запросы «застревают» на 20-60 секунд на этапе IIS «SendResponse». Это единственное, что я смог найти до сих пор, что могло бы объяснить, почему мы видим, что пользователи застревают при навигации. Обратите внимание, что большинство запросов обрабатываются быстро, похоже, здесь застревают случайные запросы из разных пулов приложений.

Есть идеи, на что еще я могу смотреть? Что может вызвать застревание запросов на этапе «SendResponse» в IIS?

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

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

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

Вы нашли какое-нибудь решение? Я уже довольно давно вижу то же самое, когда статический контент, такой как JS, PNG и GIF, застревает в состоянии «SendResponse» в модуле «IIS Web Core». У меня такая же ситуация с IIS 7 / ASP.NET 4.0. Я слежу за этим с этот код Microsoft.Web.Administration, а не appcmd.

ОБНОВЛЕНИЕ: при некоторых дальнейших исследованиях я обнаружил, что это может быть разорванное сетевое соединение. В эта тема, человек сообщает коды состояния Win32 1236 в своих журналах IIS, что означает «Сетевое соединение было прервано локальной системой». Однако я не уверен, означает ли это, что запрашивающая сторона отменила запрос или веб-сервер прервал запрос. Возможно, запрашивающая сторона может перейти на другую страницу вашего сайта до того, как будут выполнены все эти HTTP-запросы для содержимого страницы (изображения, JS и т. Д.), Что, вероятно, прервет все ожидающие запросы к веб-серверу (т. Е. Он щелкнет ссылку на странице при первом рендеринге). Я нашел несколько кодов состояния 1236 Win32 в моих журналах IIS (в основном для статического контента, такого как GIF, PNG и JS, некоторые из которых привязаны к страницам ASPX), однако я не уверен, что это те же запросы, что и я. Я застрял в состоянии "SendResponse".