使从 ASP.NET 调用 XML Web services 时应用您可能会遇到争用、 性能下降和死锁。 客户端可能会报告请求停止响应 （或"挂起"） 或需要执...使从 ASP.NET 调用 XML Web services 时应用您可能会遇到争用、 性能下降和死锁。 客户端可能会报告请求停止响应 （或"挂起"） 或需要执行一个很长时间。 如果怀疑死锁，工作进程可能回收。 应用程序事件日志中，可能会收到以下消息。
如果要使用 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 服务...ASP.NET 限制的工作线程和调用可用于执行请求的完成端口线程数可能会发生此问题。
通常，调用 Web 服务使用一个工作线程执行发送请求的代码和从 Web 服务接收回调的一个完成端口线程。 但是，如果请求被重定向，或要求身份验证，调用将可以使用多达两个工作和两个完成端口线程。 因此，多个 Web 服务调用发生在同一时间时可以耗尽托管的 ThreadPool。
是例如假设 ThreadPool 是限制为 10 的工作线程所有 10 个工作线程当前执行正在等待回调执行的代码。 回调可以永远不会执行，因为要排队发送至 ThreadPool 的任何工作项被阻止，直到线程可用。
另一个潜在的源的争用是 System.Net 命名空间用来限制连接数不超过 maxconnection 参数。 通常情况下，此限制正常工作。 但是，如果许多应用程序尝试多请求对单个 IP 地址在同一时间，线程可以等待可用的连接。
解决方案
要解决这些问题，您可以以最适合您的具体情况在 Machine.config 文件中调整以下参数： maxWorkerThreads minWorkerThrea...要解决这些问题，您可以以最适合您的具体情况在 Machine.config 文件中调整以下参数：
maxWorkerThreads
minWorkerThreads
maxIoThreads
minFreeThreads
minLocalRequestFreeThreads
maxconnection
executionTimeout
要成功地解决这些问题，请执行下列操作：
限制在同一时间为每个 CPU 的大约 12 可以执行的 ASP.NET 请求的数量。
允许为自由地在 ThreadPool 中使用线程的 Web 服务回调。
选择为 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 的默认"线程优化"功能创建的工作线程更快得多。 此设置可能会突然被填充后端服务器的队列中导致请求数的突然上升的请求从客户端结束，或类似的突然爆发的 slow-down 由于在 ASP.NET 请求队列的服务请求启用 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 将建议您使用以下配置设置：
设置为 100 的 maxWorkerThreads 参数和 maxIoThreads 参数值。
设置 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 * 的其他使用 （例如为 Web 服务回调） N 完成端口线程可用。
是例如，您有一个服务器，而且四个的处理器并启用超线程。 根据这些公式，您将使用下列值这篇文章中提到的配置设置。
<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50">
<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608">
<connectionManagement>
<add address="[ProvideIPHere]" maxconnection="96"/>
</connectionManagement>
此外时使用此配置，12 连接可用每个 CPU 每个每个 AppDomain 的 IP 地址。 因此，在下面的情形中很少的争用请求正在等待连接，并 ThreadPool 不用完时发生：
网站承载只有一个的应用程序 (AppDomain)。
ASPX 页的每个请求将一个 Web 服务请求。
所有请求都是相同的 IP 地址。
但是，使用此配置时, 涉及到下列项之一的方案将可能使用连接太多：
请求是多个 IP 地址。
请求是重定向 （302 状态代码）。
请求要求身份验证。
从多个 AppDomain 发出请求。
在这些情况下，很好用于 maxconnection 参数和 / minFreeThreads 参数和 minLocalRequestFreeThreads 参数的更高值的较低的值。
状态
这种现象是设计使然。这种现象是设计使然。
参考
有关详细信息，请访问下面的 Microsoft Developer Network (MSDN) 网站： http://msdn2.microsoft.com/...有关详细信息，请访问下面的 Microsoft Developer Network (MSDN) 网站：
http://msdn2.microsoft.com/en-us/library/ms998549.aspx (http://msdn2.microsoft.com/en-us/library/ms998549.aspx)