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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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 - это просто поддельная задача asyn. Вся моя бизнес-логика по-прежнему выполняется в основном потоке, который не изменяет никакого поведения текущего кода.