ASP.Net httpruntime executeTimeout не работает (и да, debug = false)

Question

Мы только недавно заметили, что executeTimeout перестал работать на нашем сайте.Он определенно работал ~ в прошлом году ... трудно сказать, когда он остановился.

В настоящее время мы работаем на:

• Windows-2008x64
• IIS7
• 32-битные двоичные файлы
• Управляемый конвейерный режим = классический
• Версия платформы = v2.0

Web.Config имеет

<compilation defaultLanguage="vb" debug="false" batch="true">
<httpRuntime executionTimeout="90" />

Любые подсказки о том, почему мы видим Timetaken вплоть до ~ 20 минут.Будут ли какие-либо эффекты для параметров компиляции для DebugType (full vs pdbonly)?

datetime       timetaken httpmethod Status  Sent    Received<BR>
12/19/10 0:10  901338    POST       302 456 24273<BR>
12/19/10 0:18  1817446   POST       302 0   114236<BR>
12/19/10 0:16  246923    POST       400 0   28512<BR>
12/19/10 0:12  220450    POST       302 0   65227<BR>
12/19/10 0:22  400150    GET        200 180835  416<BR>
12/19/10 0:20  335455    POST       400 0   36135<BR>
12/19/10 0:57  213210    POST       302 0   51558<BR>
12/19/10 0:48  352742    POST       302 438 25802<BR>
12/19/10 0:37  958660    POST       400 0   24558<BR>
12/19/10 0:06  202025    POST       302 0   58349<BR>

Answer 1

Тайм-аут выполнения и время, затраченное на время - две разные вещи.Хотя размер несоответствия вызывает беспокойство.

время, затраченное на обработку, включает все сетевое время в запросе / ответе (при определенных условиях .).Время передачи по сети легко превышает количество времени, которое действительно занимает запрос.Хотя обычно я привык к разнице в секунды, а не в минутах.

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

Конечно, при условии, что первый запрос, который вы перечислили, занял все 90 секунд разрешенного времени ожидания, что по-прежнему оставляет 13,5 минуты в окне, потраченном на время, для передачи по существу 24 КБ данных.,Это звучит как серьезная проблема в сети.

Итак, либо у вас серьезная проблема с транспортом, либо где-то в дереве есть другой файл web.config, где обрабатываются запросы, который либо устанавливает для отладки значение true, либо увеличиваетТайм-аут выполнения чего-то астрономического.

Другая возможность состоит в том, что на самой странице либо установлен атрибут debug, либо его собственные значения времени ожидания.

Answer 2

Я наткнулся на эту статью 2 дня назад, когда у меня была такая же проблема. Я попробовал все, это работало на моей локальной машине, но не работало на производственном сервере. Сегодня у меня есть обходной путь, который решает проблему и хотел бы поделиться. Microsoft, похоже, не применяет тайм-аут к IHttpAsyncHandler, и я этим пользуюсь. В моей системе у меня только один обработчик, который занимает много времени, поэтому это решение работает для меня. Мой код обработчика выглядит так:

public class Handler1 : IHttpAsyncHandler
    {
        public bool IsReusable
        {
            get { return true; }
        }

        public void ProcessRequest(HttpContext context)
        {
        }

        public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
        {
            //My business logic is here

            AsynchOperation asynch = new AsynchOperation(cb, context, extraData);
            asynch.StartAsyncWork();
            return asynch;
        }

        public void EndProcessRequest(IAsyncResult result)
        {

        }
}

И мой вспомогательный класс:

class AsynchOperation : IAsyncResult
        {
            private bool _completed;
            private Object _state;
            private AsyncCallback _callback;
            private HttpContext _context;

            bool IAsyncResult.IsCompleted { get { return _completed; } }
            WaitHandle IAsyncResult.AsyncWaitHandle { get { return null; } }
            Object IAsyncResult.AsyncState { get { return _state; } }
            bool IAsyncResult.CompletedSynchronously { get { return false; } }

            public AsynchOperation(AsyncCallback callback, HttpContext context, Object state)
            {
                _callback = callback;
                _context = context;
                _state = state;
                _completed = false;
            }

            public void StartAsyncWork()
            {
                _completed = true;
                _callback(this);
            }
        }

При таком подходе мы фактически ничего не делаем асинхронно. AsynchOperation это просто фальшивая асиновая задача. Вся моя бизнес-логика все еще выполняется в главном потоке, который не меняет поведение текущего кода.

Answer 3

У меня есть теория, но я не уверен, как это доказать.Я сделал что-то похожее на cbcolin и записал время, когда запрос начинается из обработчика событий BeginRequest.Затем, когда время ожидания запроса истекло (в нашем случае через 1 час), оно регистрируется в базе данных и записывается метка времени.

Итак, вот теория: ASP.NET считает только время, которое фактически выполняет поток, а не время, когда он спит.

Таким образом, после BeginRequest поток переходит в спящий режим, пока IIS не получит все тело POST.Затем нить просыпается, чтобы сделать работу, и часы executionTimeout начинают работать.Поэтому время, проведенное в фазе передачи по сети, не учитывается в executionTimeout.В конце концов, истекает время ожидания подключения по всему сайту, и IIS закрывает соединение, что приводит к исключению в ASP.NET.

BeginRequest и даже PreRequestHandlerExecute все вызываются перед телом POSTпередается на веб-сервер.Затем проходит длинный промежуток, прежде чем вызывается обработчик запроса.Так что может показаться, что у .NET был запрос в течение 30 минут, но поток не работал так долго.

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

Теперь о том, как контролировать, как долго запрос может оставаться в фазе передачи, как это, для каждого URL, я понятия не имею.На глобальном уровне мы можем установить minBytesPerSecond в webLimits для приложения.Там нет пользовательского интерфейса для него, что я могу найти.Это должно пнуть очень медленных клиентов в фазе передачи.

Это все еще не решит проблему для атак DoS, которые фактически отправляют данные.