ASP.Net httpruntime executionTimeout不工作(当然还有debug=false)
我们最近刚刚注意到executionTimeout已经停止了在我们网站上的工作。去年它肯定是有效的。很难说是什么时候停止的。
我们目前正在运行：
- Windows-2008x64
- IIS7
- 32bit binaries
- Managed管道模式= classic
- Framework版本= 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>回答 3
Stack Overflow用户
发布于 2010-12-20 23:10:35
执行超时和耗时是两码事。不过，这种差异的大小令人担忧。
time-taken包括请求/响应中的所有网络时间(在特定conditions下)。网络传输时间很容易超过请求实际花费的时间。不过，通常情况下，我习惯了几秒钟的差异，而不是几分钟。
执行超时仅指工作进程处理请求所用的时间；这只是所用时间的子集。它仅适用于将debug属性设置为false(https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/e1f13641(v=vs.100%29)；它看起来像是这样)的情况。
当然，假设您列出的第一个请求占用了整个90秒的允许超时时间，那么仍然只剩下13.5分钟的时间窗口来传输基本上24k的数据。这听起来像是一个严重的网络问题。
因此，要么您有一个严重的传输问题，要么在树中的某个地方有另一个web.config文件正在处理请求，它要么将debug设置为true，要么将执行超时增加到天文数字。
另一种可能是页面本身设置了debug属性，或者设置了自己的超时值。
Stack Overflow用户
发布于 2011-06-21 02:20:25
我有一个理论，但我不确定如何证明它。我执行了类似于cbcolin的操作，并从BeginRequest事件处理程序中记录了请求开始的时间。然后，当请求超时时(在我们的例子中是1小时后)，它被记录在数据库中，并记录一个时间戳。
所以原理是这样的: ASP.NET只计算线程实际执行的时间，而不是它休眠的时间。
因此，在BeginRequest之后，线程将进入休眠状态，直到IIS接收到整个POST正文。然后，该线程被唤醒以进行工作，并且executionTimeout时钟开始运行。因此，在网络传输阶段花费的时间不计入executionTimeout。最终达到站点范围的连接超时，IIS关闭连接，从而导致ASP.NET中出现异常。
在之前，BeginRequest甚至PreRequestHandlerExecute都被称为，帖子的正文被传输到web服务器。那么在请求处理程序被调用之前还有很长的一段时间。因此，可能看起来.NET有30分钟的请求，但线程并没有运行那么长时间。
我将开始记录请求处理程序实际开始运行的时间，看看它是否超过了我设置的限制。
现在，关于控制一个请求可以停留在传输阶段的时间，就像这样，基于每个URL，我不知道。在全局级别上，我们可以在webLimits中为应用程序设置minBytesPerSecond。我找不到它的用户界面。这应该会在传输阶段踢到超慢客户端。
这仍然不能解决实际发送数据的DoS攻击的问题。
Stack Overflow用户
发布于 2013-04-16 20:08:38
两天前，当我遇到同样的问题时，我偶然看到了这篇文章。我尝试了所有方法，它在我的本地机器上工作，但在生产服务器上不起作用。今天，我有一个解决方法来解决这个问题，并想与大家分享。微软似乎没有对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)
{ }
}和我的helper类：
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只是一个假的异步任务。我的所有业务逻辑仍然在主线程上执行，这不会改变当前代码的任何行为。
https://stackoverflow.com/questions/4490017
复制相似问题