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

文章编号: 821268 - 查看本文应用于的产品

症状

当您从 ASP.NET 应用程序调用 XML Web 服务时，您可能会遇到争用、 较差的性能和死锁。客户端可能会报告请求停止响应 （或"挂起"），或需要很长时间才能执行。如果怀疑死锁，则可能是回收工作进程。在应用程序事件日志中可能会收到以下消息。

• 如果您使用的 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： 要完成此操作的线程池对象中没有足够的空闲线程。"

在浏览器中，您还可能收到以下异常错误消息：

"HttpException (0x80004005)： 请求超时。"

注意这篇文章也适用于直接进行HttpWebRequest请求的应用程序中。

原因

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

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

例如，假设线程池仅限于 10 个工作线程，并且所有 10 个工作线程当前正在执行正在等待回调来执行代码。因为要排队发送至线程池的任何工作项将被阻止，直到线程变为可用，可以永远不会执行回调。

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

解决方案

若要解决这些问题，可以在 Machine.config 文件以最适合您的具体情况调整以下参数：

• maxWorkerThreads
• minWorkerThreads
• maxIoThreads
• minFreeThreads
• minLocalRequestFreeThreads
• maxconnection
• executionTimeout

要成功地解决这些问题，请执行以下操作：

• 限制可以为每个 CPU 的大约 12 同时执行的 ASP.NET 请求数。
• 允许 Web 服务回调用于自由线程的线程池。
• 选择适当的maxconnections参数的值。您的选择基于 IP 地址和使用的应用程序域的数量。

注意若要限制为每个 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参数确定多少能连接到特定的 IP 地址。参数即会出现，如下所示：

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。

注意您在使用此配置时您可以执行的每个 CPU 的 12 ASP.NET 请求的最大值在同一时间，因为 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 发出请求。

例如，您有一个服务器具有四个处理器和启用超线程。基于这些公式，将使用本文中提及的配置设置的下列值。

状态

此行为是设计使然。

更多信息

如果您遇到较差的性能和使用 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

IIS 7.0 中的 ASP.net 挂起

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

属性

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

这篇文章中的信息适用于:

• Microsoft .NET Framework 2.0
• Microsoft ASP.NET 1.1
• Microsoft ASP.NET 1.0

关键字： 

kbmt kbprb KB821268 KbMtzh 

http://support.microsoft.com/kb/821268