查找 ASP.Net 超时原因（在长时间操作期间）答案

【问题标题】：Finding ASP.Net Timeout Reason (During lengthy operations)查找 ASP.Net 超时原因（在长时间操作期间）
【发布时间】：2011-06-21 17:57:04
【问题描述】：

我有一个 asp.net 网络应用程序。它通过 WCF 与业务层通信。有一个冗长的数据库操作（需要两个小时）。这是一个通常的同步调用。最初，我曾经获得与 WCF 超时相关的异常。对于这些异常，曾经在 UI 页面中抛出异常（说“Socket Timeout”）。我在服务和客户端中都使用 WCF 绑定设置解决了这个问题。

现在，（恰好）一小时后，我在浏览器窗口中收到错误消息。即使我们的应用程序有一个自定义应用程序错误页面，它也没有显示自定义错误。由于 UI 中没有抛出异常，我认为这可能是由于 ASP.Net 超时而不是 WCF。我也没有在事件查看器中看到任何相关的日志。

我可以使用哪些方法/工具来确定超时的确切原因？

是浏览器设置/asp.net设置/iis设置问题吗？

IE 错误消息：您正在查找的页面当前不可用。该网站可能遇到技术问题，或者您可能需要调整您的浏览器设置。注意：底部显示“找不到服务器或 DNS 错误”

注意：此功能仅在一个月内使用一次。这是管理员的功能。所以花两个小时对我们来说是可以的。

注意：我有以下 WCF 配置。服务（receiveTimeout="05:30:00"）和客户端（receiveTimeout="05:30:00" 和 sendTimeout="05:30:00"）。

注意：无法导航到我们的自定义错误页面，也没有抛出异常。

注意：我正在使用 Visual Studio 2005 进行开发。

注意：WCF 是自托管的，用于测试。

注意：在 WCF 中是 NetTCPBinding

下面列出了应用程序中使用的一些配置值：

<httpRuntime maxRequestLength="20000" executionTimeout="900"/>

  <forms loginUrl="Default.aspx" name=".ASPNETAUTH" protection="None" path="/" timeout="30" defaultUrl="Home.aspx">

  </forms>

</authentication>

和-

<roleManager defaultProvider="MyRoleProvider" enabled="true" 
cacheRolesInCookie="true" cookieName=".ASPROLES" cookieTimeout="30" cookiePath="/"   cookieRequireSSL="false" cookieSlidingExpiration="true" cookieProtection="All">
  <providers>
    <clear/>
    <add name="MyRoleProvider" type="My.AccessControl.ServiceLayer.MyRoleProvider"  />
  </providers>
</roleManager>

注意：我打算在 IE 中禁用“显示友好的 HTTP 错误消息”。我还计划在 system.web 中设置 customErrors mode=”Off” 以进一步测试它。

【问题讨论】：

考虑将它分成一个单独的进程，一个 web 请求不会存活 2 小时......
这是如何在 iis 中托管的？还是开发服务器？如果它在 iis 中，可能会检查您的连接超时设置
用不同的浏览器得到同样的结果吗？
这种情况每月只发生一次。这是管理员的功能。所以两个小时对我们来说是可以的。目前它在开发服务器中。 [好点..我会用 chrome 测试它。无论如何，我认为它不是特定于浏览器的]

标签： c# .net asp.net wcf iis

【解决方案1】：

首先，浏览器只会等待网络服务器响应并开始产生响应。 IE 7/8，我相信 60 分钟后保释。不知道关于 IE 9。有关详细信息，请参阅KB181050 文章。 Firefox、Chrome、Safari、Opera 在决定服务器上不存在之前愿意等待的时间可能都不同。

坦率地说，我认为在决定服务器不会回答之前等待 60 分钟非常长。 5分钟应该绰绰有余。如果您请求一个网页并且超过一两分钟没有收到来自服务器的任何响应，您会假设什么：您通常不会假设服务器已经崩溃并取消请求吗？

无论如何，当浏览器放弃请求时，它会关闭套接字，你会从浏览器中得到一个错误页面。你不会在服务器端看到任何东西：它仍然在愉快地磨掉。不过，我假设 IIS 会注意到套接字何时断开。希望届时 IIS 将终止请求。

第二，IIS 本身只会等待很长时间，然后才决定处理请求时出现了问题。我相信你应该得到一个例外。

您究竟为什么希望您的用户（和他们的网络浏览器）等待 HTTP 请求超过 2 小时？

设置您的管理应用程序，以便将此类请求排队并由某种守护进程异步处理（或生成一个线程来执行异步处理。交回某种票证，以便请求页面可以定期轮询以查看是否长时间运行的请求已完成：此时，交回构成请求的实际响应的任何内容。

在客户端浏览器上，通过 AJAX 帖子生成此类请求。让客户端javascript使用返回的票每30秒左右轮询一次，直到请求完成。瞧！不再有浏览器超时。

【讨论】：

【解决方案2】：

如果您可以将其托管在 IIS 服务器上，您可以尝试使用 FailedRequestTracing 模块。

http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis-7/

我以前用它来解决超时问题。

【讨论】：

当然，我会尽最大努力使用 FailedRequestTracing 进行测试。同时，您能否建议一些配置值，我可以在其中查找潜在问题（可能是 1 小时的默认设置）？

【解决方案3】：

会话是否会超时或（网络）应用程序在一小时后关闭？

【讨论】：

【解决方案4】：

你最好需要实现双工服务来实现 WCF 和 ASP.net 之间的通知和 AJAX 来实现客户端和 Web 服务器之间的通知

【讨论】：

【解决方案5】：

通过 HTTP 等待您自己描述为两小时操作的整个概念在 git-go 中存在缺陷。正如其他海报所提到的，您需要重新考虑您的策略。在一些排队的过程中启动它，然后为用户提供一些方法来轮询完成，甚至向他们发送带有链接的电子邮件通知是一种方法。

顺其自然。

【讨论】：