执行超时和耗时是两个不同的概念。尽管如此，差异的大小令人不安。
time-taken包括请求/响应中的所有网络时间（在特定的conditions.下）。网络传输时间很容易超过请求实际花费的时间。尽管，通常，我习惯于只相差几秒而不是几分钟。
执行超时仅指辅助进程处理请求所花费的时间;这只是耗时的一个子集。它只适用于debug attribute is set to false;看起来你已经有了
当然，假设您列出的第一个请求占用了90秒的允许超时时间，那么在传输24 k数据的时间窗口中仍然剩下13.5分钟。这听起来是一个严重的网络问题。
因此，要么您有一个严重的传输问题，要么在树中的某个地方存在另一个web.config文件，在该文件中处理的请求要么将debug设置为true，要么将执行超时增加到天文数字。
另一种可能性是页面本身设置了debug属性或它自己的超时值。

我有一个理论，但我不确定如何证明它。我做了一些类似于cbcolin的事情，并记录了请求从BeginRequest事件处理程序中开始的时间。然后当请求超时时（在我们的情况下是1小时后），它被记录在数据库中并记录了时间戳。
理论是这样的：ASP.NET只计算线程实际执行的时间，而不计算线程休眠的时间。
因此，在BeginRequest之后，线程进入睡眠状态，直到IIS接收到整个POST主体。然后，线程被唤醒并开始工作，executionTimeout时钟开始运行。因此，在网络传输阶段花费的时间不会计入executionTimeout。最终，站点范围的连接超时被命中，IIS关闭连接，导致ASP.NET中的异常。
BeginRequest甚至PreRequestHandlerExecute都在POST主体被传输到Web服务器之前被调用。然后在请求处理程序被调用之前有一个很长的间隙。所以看起来可能像.NET有30分钟的请求，但线程并没有运行那么长时间。
我将开始记录请求处理程序实际开始运行的时间，看看它是否超过了我设置的限制。
现在，关于控制一个请求可以在每个URL的基础上在传输阶段停留多长时间，我不知道。在全局层面上，我们可以在webLimits中为应用程序设置minBytesPerSecond。我找不到它的UI。这应该会在传输阶段踢出超慢的客户端。
这仍然不能解决实际发送数据的DoS攻击的问题。

我遇到了这篇文章2天前，当我有同样的问题.我尝试了一切，它在我的本地机器上工作，但没有在生产服务器上工作.今天，我有一个解决方案，解决了这个问题，并希望分享.微软似乎没有应用超时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只是一个假的异步任务。我所有的业务逻辑仍然在主线程上执行，这不会改变当前代码的任何行为。

IIS执行超时停止工作（pre-Core）ASP.NET在内部HTTP操作变为异步之后。当HTTP操作是同步的时，运行时只是观察请求的线程存活了多长时间，如果太长就杀死它，这是可行的，因为一个线程总是绑定到一个请求。但是一旦框架发展到HTTP操作变为异步的时候，超时模型不再起作用，因为一个线程最终要处理多个请求，所以你不能在某个时间后安全地杀死一个线程。
https://serverfault.com/questions/1068281/asp-net-iis-requests-not-timing-out-after-executiontimeout-value/1128469