blocks|key|288064|text|执行超时和耗时是两码事。不过，这种差异的大小令人担忧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|288065|time-taken包括请求/响应中的所有网络时间(在特定conditions下)。网络传输时间很容易超过请求实际花费的时间。不过，通常情况下，我习惯了几秒钟的差异，而不是几分钟。|offset|length|288066|执行超时仅指工作进程处理请求所用的时间；这只是所用时间的子集。它仅适用于将debug属性设置为false(https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/e1f13641(v=vs.100%2529)；它看起来像是这样)的情况。|288067|当然，假设您列出的第一个请求占用了整个90秒的允许超时时间，那么仍然只剩下13.5分钟的时间窗口来传输基本上24k的数据。这听起来像是一个严重的网络问题。|288068|因此，要么您有一个严重的传输问题，要么在树中的某个地方有另一个web.config文件正在处理请求，它要么将debug设置为true，要么将执行超时增加到天文数字。|288069|另一种可能是页面本身设置了debug属性，或者设置了自己的超时值。|288070|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/troubleshoot/iis/time-taken-field-http-log|1|https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/e1f13641(v=vs.100%2529)^0|0|T|A|0|0|1H|2O|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|F|3|G|5|6|7|12|8|@]|9|@$D|13|E|14|1|15]]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|18|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]|V|$5|Q|R|S|A|$T|W]]]]

Execution timeout and time-taken time two different things. Although, the size of the discrepancy is troubling.
time-taken includes all of the network time in the request/response (under certain <a href="https://docs.microsoft.com/en-us/troubleshoot/iis/time-taken-field-http-log" rel="nofollow noreferrer">conditions</a>.). The network transfer time easily outstrips the amount of time a request really takes. Though, normally, I'm used to just seconds of difference not minutes.
Execution timeout refers only to the amount of time the worker process spent processing the request; which is just a subset of time-taken. It only applies if the <a href="https://docs.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/e1f13641(v=vs.100)" rel="nofollow noreferrer">debug attribute is set to false</a>; which it looks like you have.
Of course, assuming the first request you listed took the full 90 seconds of allowed time out, that still leaves 13.5 minutes left in the time-taken window to transfer essentially 24k of data. That sounds like a serious network issue.
So, either you have a serious transport issue or there is another web.config file somewhere in the tree where the requests are being processed that either sets debug to true or increases the execution timeout to something astronomical.
Another possibility is that the page itself has either the debug attribute set or it's own timeout values.

blocks|key|3003404|text|我有一个理论，但我不确定如何证明它。我执行了类似于cbcolin的操作，并从BeginRequest事件处理程序中记录了请求开始的时间。然后，当请求超时时(在我们的例子中是1小时后)，它被记录在数据库中，并记录一个时间戳。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3003405|所以原理是这样的:+ASP.NET只计算线程实际执行的时间，而不是它休眠的时间。|3003406|因此，在BeginRequest之后，线程将进入休眠状态，直到IIS接收到整个POST正文。然后，该线程被唤醒以进行工作，并且executionTimeout时钟开始运行。因此，在网络传输阶段花费的时间不计入executionTimeout。最终达到站点范围的连接超时，IIS关闭连接，从而导致ASP.NET中出现异常。|3003407|在之前，BeginRequest甚至PreRequestHandlerExecute都被称为，帖子的正文被传输到web服务器。那么在请求处理程序被调用之前还有很长的一段时间。因此，可能看起来.NET有30分钟的请求，但线程并没有运行那么长时间。|BOLD|3003408|我将开始记录请求处理程序实际开始运行的时间，看看它是否超过了我设置的限制。|3003409|现在，关于控制一个请求可以停留在传输阶段的时间，就像这样，基于每个URL，我不知道。在全局级别上，我们可以在webLimits中为应用程序设置minBytesPerSecond。我找不到它的用户界面。这应该会在传输阶段踢到超慢客户端。|3003410|这仍然不能解决实际发送数据的DoS攻击的问题。|3003411|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/users/11791/cbcolin|1|http://www.iis.net/ConfigReference/system.applicationHost/webLimits^0|12|C|P|7|0|0|0|4|C|1R|G|2W|G|0|4|C|I|O|1A|24|0|0|11|0|0|39|1I|9|1|0|0|N|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@$9|15|A|16|1|17]]|E|$]]|$1|F|3|G|5|6|7|18|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|19|8|@$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|L]]|D|@]|E|$]]|$1|M|3|N|5|6|7|1N|8|@$9|1O|A|1P|B|L]]|D|@]|E|$]]|$1|O|3|P|5|6|7|1Q|8|@$9|1R|A|1S|B|L]]|D|@$9|1T|A|1U|1|1V]]|E|$]]|$1|Q|3|R|5|6|7|1W|8|@$9|1X|A|1Y|B|L]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1Z|8|@]|D|@]|E|$]]]|T|$U|$5|V|W|X|E|$Y|Z]]|10|$5|V|W|X|E|$Y|11]]]]

I have a theory but I'm not sure how to prove it. I've done something similar to <a href="https://stackoverflow.com/users/11791/cbcolin">cbcolin</a> and logged the time when the request starts from within the <code>BeginRequest</code> event handler. Then when the request times out (1 hour later in our case) it is logged in the database and a timestamp recorded. 

So here is the theory: ASP.NET only counts time that the thread is actually executing, not time that it is asleep. 

So after <code>BeginRequest</code> the thread goes to sleep until the entire POST body is received by IIS. Then the thread is woken up to do work and the <code>executionTimeout</code> clock starts running. So time spent in the network transmission phase is not counted against the <code>executionTimeout</code>. Eventually the site wide Connection Timeout is hit and IIS closes the connection, resulting in an exception in ASP.NET.

<code>BeginRequest</code> and even <code>PreRequestHandlerExecute</code> all get called before the POST body is transferred to the web server. Then there is a long gap before the request handler is called. So it may look like .NET had the request for 30 minutes but the thread wasn't running that long.

I'm going to start logging the time that the request handler actually starts running and see if it ever goes over the limit I set. 

Now as to control how long a request can stay in the transmittions phase like this on a per URL basis I have no idea. On a global level we can set minBytesPerSecond in <a href="http://www.iis.net/ConfigReference/system.applicationHost/webLimits" rel="nofollow noreferrer">webLimits</a> for the application. There is no UI for it that I can find. This should kick ultra slow clients in the transmission phase. 

That still wont solve the problem for DoS attacks that actually send data.

blocks|key|3003549|text|两天前，当我遇到同样的问题时，我偶然看到了这篇文章。我尝试了所有方法，它在我的本地机器上工作，但在生产服务器上不起作用。今天，我有一个解决方法来解决这个问题，并想与大家分享。微软似乎没有对IHttpAsyncHandler应用超时，我利用了这一点。在我的系统上，我只有一个处理程序，这很耗时，所以这个解决方案适合我。我的处理程序代码如下所示：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3003550|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)
++++{+}
}|code-block|syntax|javascript|3003551|和我的helper类：|3003552|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);
++++}
}|3003553|在这种方法中，我们实际上没有异步地做任何事情。AsynchOperation只是一个假的异步任务。我的所有业务逻辑仍然在主线程上执行，这不会改变当前代码的任何行为。|offset|length|style|CODE|3003554|entityMap^0|0|0|0|0|N|F|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I came across this article 2 days ago when I had the same problem. I tried everything, it worked on my local machine but did not work on the production server. Today, I have a workaround that fixes the problem and would like to share. Microsoft seems to not apply timeout to IHttpAsyncHandler and I take advantage of that. On my system, I only have 1 handler that is time-consuming, so this solution works for me.
My handler code looks like this:
<pre><code>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)
 { }
}
</code></pre>
And my helper class:
<pre><code>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);
 }
}
</code></pre>
In this approach, we actually do not do anything asynchronously. <code>AsynchOperation</code> is just a fake async task. All of my business logic is still executed on the main thread which does not change any behavior of the current code.

We just recently noticed that executionTimeout has stopped working on our website. It was definitely working ~last year ... hard to say when it stopped.

We are currently running on:

<ul>
<li>Windows-2008x64</li>
<li>IIS7</li>
<li>32bit binaries</li>
<li>Managed Pipeline Mode = classic</li>
<li>Framework version = v2.0</li>
</ul>

Web.Config has

<pre><code>&lt;compilation defaultLanguage="vb" debug="false" batch="true"&gt;
&lt;httpRuntime executionTimeout="90" /&gt;
</code></pre>

Any hints on why we are seeing Timetaken all the way up to ~20 minutes. Would compilation options for DebugType (full vs pdbonly) have any effect?

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

ASP.Net httpruntime executionTimeout not working (and yes debug=false)

数据库

服务器

Windows

我们最近刚刚注意到executionTimeout已经停止了在我们网站上的工作。去年它肯定是有效的。很难说是什么时候停止的。我们目前正在运行：Windows-2008x64IIS732bit binariesManaged管道模式= classicFramework版本= v2.0Web.Config有<compila...

问ASP.Net httpruntime executionTimeout不工作(当然还有debug=false)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.Net httpruntime executionTimeout不工作(当然还有debug=false)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.Net httpruntime executionTimeout不工作(当然还有debug=false)
EN