Запросы в состоянии 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. Они не совершают длительные звонки на сторонние веб-сервисы или тому подобное.
- Я пробовал оба процесса autoConfig processModel, а также установки maxWorkerThreads, maxConnections, maxIOThreads и т. Д. На очень большие числа без разницы.
- Все запросы к базе данных выполняются менее чем за 1 секунду. Я профилировал весь день и не захватил ни одного запроса, который бы занимал больше времени.
- Я посмотрел на тонны счетчиков монитора производительности; очереди ASP.NET и очереди приложений всегда пусты, кажется, что ничего не ставится в очередь (что в любом случае не имеет смысла, если учесть, что сервер вообще не потеет)
- Я идентифицировал использование запросов списка appcmd, которые иногда "зависают" на этапе IIS "SendResponse". Это единственное, что я смог найти до сих пор, чтобы понять, почему мы видим, как пользователи застревают при навигации. Обратите внимание, что большинство запросов обрабатываются очень быстро, похоже, что здесь застряли случайные запросы из разных пулов приложений.
Есть идеи, на что еще я могу посмотреть? Что может привести к зависанию запросов на этапе "SendResponse" в IIS?
3 ответа
Обычно это происходит из-за того, что мобильные устройства на медленных подключениях к данным загружают большие файлы активов. Когда я говорю "большой", я имею в виду скорость соединения.
Запросы не "зависают", они просто занимают много времени, потому что они зависят от скорости сети пользователя. Запросы будут сброшены, если пользователь отключится, поэтому они, вероятно, терпеливо ждут загрузки страницы.
Проверьте 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".
Хотел поделиться своим недавним опытом с теми же симптомами, которые вы описали. У нас были периодические зависания запросов, когда браузер, казалось, долгое время (от 10 секунд до ~ 100 секунд) ждал случайных запросов. Это происходило как с запросами статического контента, так и с динамическим. После просмотра запросов, использующих тот же метод, что и вы (запросы списка appcmd), я увидел, что они застревают в SendResponse.
Чтобы воспроизвести проблему, я зациклил 100 000 запросов на небольшой статический файл .jpg и смог сгенерировать тысячи из 1236 ответов (проверено путем проверки журналов IIS).
После отключения сканирования в реальном времени Защитника Windows мой тест на 100 тысяч запросов сгенерировал 0 1236 ответов.В нашей среде UAT мы получали около 10-100 ошибок 1236 в наших журналах iis каждый день (из примерно 500 тысяч запросов). После отключения сканирования в реальном времени Защитника Windows у нас теперь не было ни одного статуса 1236 win32 ни для одного входящего запроса.