Menu
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:
Web.Config has
<compilation defaultLanguage="vb" debug="false" batch="true"> <httpRuntime executionTimeout="90" /> 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?
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> 
693
The executionTimeout attribute of <httpRuntime> defines the maximum amount of time in seconds that a request is allowed to run before it is automatically terminated by ASP.NET. The default value is 90 seconds.
The ExecutionTimeout property indicates the maximum number of seconds a request is allowed to execute before being automatically shut down by ASP.NET. The default is 110 seconds.
The wcf did not execute longer than maybe 20~30 minutes. So I changed the idle timeout setting of application pool in IIS manager then it worked! In IIS manager, choose your application pool and right click on it and choose advanced settings then change the idle timeout setting to any minutes you want.
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 conditions.). 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 debug attribute is set to false; 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.
131
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
