文章编号: 821268 - 最后修改: 2009年7月28日 - 修订: 11.0

争用、 较差的性能和死锁时使 ASP.NET 应用程序从 Web 服务请求

机器翻译查看机器翻译免责声明
查看本文应用于的产品

本页

展开全部 | 关闭全部

症状

当您进行调用 XML Web 服务从一个 ASP.NET 应用您可能会遇到争用、 较差的性能和死锁。 客户端可能会报告请求停止响应 （或"挂起"），或执行一个很长时间。 如果怀疑死锁，可能回收工作进程。 应用程序事件日志中，您可能会收到以下消息。
  • 如果您使用 Microsoft Internet Information Services (IIS) 5.0，应用程序事件日志中收到以下消息：

       Event Type:     Error
   Event Source:   ASP.NET 1.0.3705.0
   Event Category: None
   Event ID:       1003
   Date:           5/4/2003
   Time:           6:18:23 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
      It did not send any responses for pending requests in the last 180 seconds.

  • 如果使用的 IIS 6.0 应用程序事件日志中收到以下消息：

       Event Type:     Warning
   Event Source:   W3SVC-WP
   Event Category: None
   Event ID:       2262
   Date:           5/4/2003
   Time:           1:02:33 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
      unhealthy for the following reason: 'Deadlock detected'.

  • 如果使用的 IIS 6.0 在系统事件日志中收到以下消息：

       Event Type:     Warning
   Event Source:   W3SVC
   Event Category: None
   Event ID:       1013
   Date:           5/4/2003
   Time:           1:03:47 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
      The process id was '<xxxx>'.

在进行调用 HttpWebRequest.GetResponse 方法时，也可能会收到以下异常错误消息：
“ System.InvalidOperationException： ThreadPool 对象来完成该操作中未有足够的自由线程 ”
您还可能会在浏览器中收到以下异常错误消息：
“ HttpException (0x80004005)： 请求超时 ”
注意 本文还适用于直接进行 HttpWebRequest 请求的应用程序。
回到顶端

原因

因为 ASP.NET 限制的辅助线程和调用可以使用来执行请求的完成端口线程数，则可能会出现此问题。

通常，调用 Web 服务使用一个工作线程来执行该代码将请求发送和接收回调从 Web 服务的一个完成端口线程。 但是，如果请求重定向或要求身份验证，呼叫可能使用多达两个工作和两个完成端口线程。 因此，您可以在多个 Web 服务调用发生在同一时间时耗尽托管的 ThreadPool。

渚嬪假设该 ThreadPool 限于 10 的辅助线程，并且所有 10 个工作线程正在执行等待执行回调的代码。 因为排队到该 ThreadPool 任何工作项将被阻止，直到某个线程变为可用，可以永远不会执行回调。

争用的另一个潜在的源是 maxconnection 参数 System.Net 命名空间用来限制连接数。 通常，按预期方式工作此限制。 但是，如果许多应用程序试图同时对单个 IP 地址进行许多请求，线程可能必须等待可用连接。
回到顶端

解决方案

若要瑕佽 в 鍐宠繖浜涢棶棰橈，可以以最适合您的具体情况 Machine.config 文件中调整以下参数：
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
若要成功地解决这些问题，请执行下列操作：
  • 限制可以为每个 CPU 的大约 12 同时执行的 ASP.NET 请求数。
  • 允许 Web 服务回调自由地在 ThreadPool 中使用线程。
  • 选择适当的值为 maxconnections 参数。 您的选择基于 IP 地址和使用的 appdomain 数。
注意 若要限制为每个 CPU 的 12 的 ASP.NET 请求数建议是有点任意的。 但是，此限制已证明适用于大多数应用程序。
回到顶端

maxWorkerThreads 和 maxIoThreads

ASP.NET 使用以下两个配置设置来限制最大的工作线程和使用的完成线程数： 
<processModel maxWorkerThreads="20" maxIoThreads="20">
maxWorkerThreads 参数和 maxIoThreads 参数隐式的 cpu 数相乘。 渚嬪濡傛灉鎮 ㄦ 湁两个处理器最大工作线程数目是下列:
2 * maxWorkerThreads
回到顶端

minFreeThreads 和 minLocalRequestFreeThreads

ASP.NET 还包含以下确定多少工作线程和完成端口线程必须可用于启动远程请求或本地请求的配置设置： 
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
如果没有足够线程可用，在请求排队直到足够的线程可以自由地发出请求。 因此，ASP.NET 将不会执行多个下列的请求数在同一时间：
(maxWorkerThreads * number of CPUs）-minFreeThreads
注意minFreeThreads 参数和 minLocalRequestFreeThreads 参数不隐式相乘的 cpu 数量。
回到顶端

minWorkerThreads

作为 ASP.NET 1.0 Service Pack 3 和 ASP.NET 1.1 的 ASP.NET 还包含以下确定多少工作线程可能会进行可立即用于远程请求提供服务的配置设置。 
<processModel minWorkerThreads="1">
通过此设置控制线程可以创建以多快速率比从 CLR 的默认"线程优化"功能创建的工作线程。 此设置使 ASP.NET 能够可能突然被填充到后端服务器突然从客户端或类似的请求将导致在队列中的请求数突然上升的突发上 slow-down 由于 ASP.NET 请求队列的服务请求。 minWorkerThreads 参数的默认值为 1。 我们建议您将为 minWorkerThreads 参数值设置为下列值。 
minWorkerThreads = maxWorkerThreads / 2
榛樿鎯呭喌涓嬶，minWorkerThreads 参数不存在在 Web.config 文件或 Machine.config 文件中。 此设置隐式乘以 cpu 数量。
回到顶端

maxconnection

maxconnection 参数确定多少能连接到特定的 IP 地址。 参数如下显示： 
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="65.53.32.230" maxconnection="12">
</connectionManagement>
本文前面所讨论的参数的设置是所有在进程级别。 但是，maxconnection 参数的设置应用于 AppDomain 级别。 榛樿鎯呭喌涓嬶，因为此设置适用于 AppDomain 级别可以创建两个连接的最大到特定的 IP 地址从每个 AppDomain 中您的进程。
回到顶端

executionTimeout

ASP.NET 使用以下配置设置将限制请求执行时间: 
<httpRuntime executionTimeout="90"/>
您还可以通过使用 Server.ScriptTimeout 属性设置此限制。

注意 如果增加 executionTimeout 参数的值，您可能还具有修改 processModel responseDeadlockInterval 参数的设置。
回到顶端

建议

此节中推荐的设置可能无法工作的所有应用程序。 但是，以下附加信息可能帮助您进行适当的调整。

如果建立的一个 Web 服务调用单个 IP 地址从每个 ASPX 页 Microsoft 建议使用以下配置设置：
  • 设置 maxWorkerThreads 参数和 maxIoThreads 参数的值为 100。
  • 设置为 maxconnection 参数的值 12 * N （其中 N 是您拥有的 cpu 数目）。
  • 设置要 minFreeThreads 参数的值 88 * N，并使用 minLocalRequestFreeThreads 参数 76 * N。
  • minWorkerThreads 的值设置为 50。 记住 minWorkerThreads 不是在默认情况下配置文件中。 您必须添加它。
这些建议的某些涉及一个简单的公式，涉及在服务器上的 cpu 数量。 代表公式中的 cpu 数目的变量是 N。 对于这些设置如果具有超线程启用，则必须使用逻辑 cpu 数而不是物理的 cpu 数目。 渚嬪如果您有四处理器服务器与启用超线程，N 的值的公式中将为 8 而不是 4。

注意 当您使用此配置时，您可以执行 12 ASP.NET 请求，每个 CPU 的最大同时因为 100 88 = 12。 因此，至少 88 * N 辅助线程和 88 * N 完成端口线程是可用的其他使用 （如 Web 服务回调所为）。

渚嬪有四个处理器和启用超线程服务器。 基于这些公式，您将在本文中提到的配置设置为使用下列值。 
<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

此外时使用此配置，12 连接都是每个 CPU 每个 IP 地址为每个 AppDomain 可用的。 因此，在以下情形中很少的争用发生请求正在等待连接，并在 ThreadPool 未用完时：
  • 在 Web 承载只有一个应用程序 (AppDomain)。
  • 每个请求的 ASPX 页使一个 Web 服务请求。
  • 所有请求都都以相同的 IP 地址。
然而时使用此配置，涉及下列选项之一的方案可能会使用太多的连接：
  • 请求将多个 IP 地址。
  • 请求被重定向 （302 状态代码）。
  • 请求需要身份验证。
  • 从多个 appdomain 发出请求。
鍦 ㄨ 繖浜涙儏鍐典笅最好 maxconnection 参数和更高的值，用于 minFreeThreads 参数和 minLocalRequestFreeThreads 参数使用较低的值。
回到顶端

状态

此行为是设计使然。
回到顶端

更多信息

如果您遇到较差的性能和 asp.net 的 IIS 7.0 上争用，请参阅下面的 Microsoft 博客：

IIS 7.0 和 6.0 上的 ASP.NET 线程用法
http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx (http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx)
在 IIS 7.0 中的 ASP.net 挂起
http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx (http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx)
回到顶端

参考

有关详细信息请访问下面的 Microsoft 开发网络 (MSDN) 的网站：
http://msdn2.microsoft.com/en-us/library/ms998549.aspx (http://msdn2.microsoft.com/en-us/library/ms998549.aspx)
回到顶端
这篇文章中的信息适用于:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
回到顶端
关键字：?
kbmt kbprb KB821268 KbMtzh
回到顶端
机器翻译机器翻译
注意：这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇，语法或文法的问题，就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量，但是我们不保证机器翻译的正确度，也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版： 821268? (http://support.microsoft.com/kb/821268/en-us/ )
回到顶端
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性，不作任何声明。 所有该等文件及有关图形均"依样"提供，而不带任何性质的保证。Microsoft和/或其各供应商特此声明，对所有与该等信息有关的保证和条件不负任何责任，该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下，在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中，Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。
 

Get Help Now

Contact a support professional by E-mail, Online, or Phone

文章翻译

 

Related Support Centers