ASP.Net的httpRuntime executionTimeout不工作(是的调试= FALSE) [英] ASP.Net httpruntime executionTimeout not working (and yes debug=false)

查看:1332
本文介绍了ASP.Net的httpRuntime executionTimeout不工作(是的调试= FALSE)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们最近刚刚发现executionTimeout已经停止在我们的网站工作。它肯定是工作〜去年...很难说,当它停了下来。

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

我们目前正在运行的:


  • Windows的2008x64

  • IIS7

  • 32位二进制代码

  • 托管管道模式=经典

  • Framework版本V2.0 =

Web.Config中有

Web.Config has

<compilation defaultLanguage="vb" debug="false" batch="true">
<httpRuntime executionTimeout="90" />

为什么我们看到Timetaken一路攀升至约20分钟均提示。将编译为DEBUGTYPE选项(全VS pdbonly)有什么影响?

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?

日期时间timetaken列举HTTPMethod状态发送频率

10年12月19日0:10 901338 POST 302 456 24273

10年12月19日0:18 1817446 POST 302 0 114236

10年12月19日0:16 246923 POST 400 0 28512

10年12月19日0:12 220450 POST 302 0 65227

10年12月19日0:22 400150获得200 180835 416

10年12月19日0:20 335455 POST 400 0 36135

10年12月19日0:57 213210 POST 302 0 51558

10年12月19日0:48 352742 POST 302 438 25802

10年12月19日0:37 958660 POST 400 0 24558

10年12月19日0:06 202025 POST 302 0 58349

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

推荐答案

执行超时和时间所用的时间两回事。虽然差异的大小是令人不安的。

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.

执行超时仅指时间的工作进程花费在处理请求的金额;这仅仅是的时间所取的子集。它只有在调试属性设置为false 适用;它看起来像你。

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.

当然,假设你花了上市打满90秒允许的时间出的第一个请求,仍然留下了时间窗口取左基本传输数据的24K13.5分钟。这听起来像一个严重的网络问题。

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.

所以,要么你有一个严重的传输问题,或有另一个web.config文件中的某个地方在请求正在处理,要么调试设置为true或增加执行超时的东西天文树。

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.

这篇关于ASP.Net的httpRuntime executionTimeout不工作(是的调试= FALSE)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆