Диагностика "Тайм-аут запроса" HttpExceptions

Ответ 1

У меня такая же проблема на наших производственных серверах, которые используют небольшой веб-сервис AJAX. После выполнения захвата пакетов за пределами нашего брандмауэра мы обнаружили, что POST для этой услуги поступает в два сегмента TCP, а второй сегмент не дошел до нас. (первый пакет содержит только заголовки, второй недостающий пакет должен быть телом json). Поэтому в основном IIS просто сидит там, ожидая остальной части POST. После настроенного таймаута сервер отправляет RST-пакет клиенту и регистрирует ошибку "Истекло время ожидания" - это правильное поведение.

Мы пытаемся получить клиентский реестр без большой удачи, но в нашем случае это, как представляется, полностью связанное с сетью (или, возможно, некоторое "программное обеспечение безопасности", которое не нравится содержимое сообщения).

Ответ 2

Если вы используете IIS 7, вы можете использовать Failed Request Tracing. Я на самом деле не использовал его для тайм-аутов, я в основном установил его для захвата только определенных кодов ошибок HTTP. Но я знаю, что вы можете заставить его сбрасывать следы любого запроса, занимая больше X раз.

Ответ 3

Вы пробовали отправлять сообщения вручную через telnet и просто не завершаете POST. Мне было бы интересно посмотреть, сможете ли вы воспроизвести поведение, которое вы видите. Учитывая природу сайта, я не удивлюсь, если вы намеренно попытаетесь взломать систему с некоторыми отклоненными POST.

Я иногда заметил, что мне нужно перезапустить Safari, чтобы заставить SO работать снова после зависания какого-либо действия, но я предположил, что это была моя проблема.

Ответ 4

В этой статье описывается, как поймать это с помощью windbg:

http://blogs.msdn.com/b/asiatech/archive/2012/06/21/how-to-troubleshoot-httpexception-request-timed-out-asp-net-4-0-64-bit.aspx

Ответ 5

Мы часто видели их с нашим очень большим веб-клиентом трафика - интересно, связано ли это. То, что предположительно происходило, было HttpWebRequest (я предполагаю, что у вас проблемы с HttpWebResponse? Возможно, у них такие же проблемы) использует какой-то janky пул потоков под обложками, даже если ваши запросы синхронны. Время от времени что-то заходило бы в тупик, потому что какой-то другой объект .NET, выше в стеке, использовал один и тот же системный поток, и один из них мог бы вымолить другого, в конечном счете, вызвать тайм-аут. Я думаю, что проблема лучше описана здесь: http://www.deez.info/sengelha/2005/03/03/beware-threadpools-and-httpwebrequest/

Ответ 6

Я также сканирую IP-адреса в ваших журналах, чтобы узнать, неоднократно ли возникают проблемы с теми же людьми. Вы знаете, возможно, что некоторые люди все еще используют учетные записи удаленного доступа, или могут возникнуть другие проблемы с сетью на их конце. Но, конечно, не просто записывайте его, не исследуя столько, сколько сможете.

Ответ 7

Мы сталкиваемся с тем же вопросом "Время ожидания запроса" с нашими веб-серверами после переключения с IIS6 на IIS7. Я считаю, что проблема связана с IIS7. Я предполагаю, что эти ошибки были проглочены или проигнорированы дальше по цепочке обработки в IIS6, прежде чем запрос был передан ASP.Net для обработки. Сегодня я запускаю Failed Request Tracing, чтобы узнать, могу ли я уловить больше информации об этой проблеме. До сих пор кажется, что ваше объяснение причин клиентской стороны кажется наиболее достоверным.