因为ASP.NET 处理进程在machine.config装备文件中的装备为< processModel autoConfig="true" />，这意味着你的ASP.NET 应用程序运用的功用参数依靠于machine.config的装备。
下面几个参数是主动装备的：
1. maxWorkerThreads 和 maxIoThreads
2. minFreeThreads 和 minLocalRequestFreeThreads
3. minWorkerThreads
4. maxconnection
5. executionTimeout

这几个参数会和你的应用程序产生这样的症状相关“争用、 功用下降和死锁进行 Web 服务恳求从 ASP.NET 应用程序时”：

进行从 ASP.NET 应用程序, 调用 XMLWeb 服务时或许会遇到争用、 功用下降和死锁。 客户或许陈述恳求中止呼应 （或 " 挂起 "）或需求很长时刻来履行。 假如置疑死, 或许回收辅佐进程。 应用程序事情日志中或许会收到以下音讯。

假如您运用 MicrosoftInternet 信息服务 (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 目标以完结 operation.ö 中：
还或许在浏览器收到以下反常错误信息：
恳求守时 out.ö ôHttpException (0 x 80004005)：
留意 本文还适用于应用程序直接使 HttpWebRequest 恳求。

原因

因为 ASP.NET 的辅佐线程和完结端口线程， 调用可用于履行恳求数约束或许产生此问题。

对 Web 服务调用一般, 运用一个辅佐线程来履行代码发送恳求和一个完结端口线程以从 Web 服务接回收调。 可是, 假如恳求重定向或需求验证, 调用或许运用多达两辅佐和两完结端口线程。 一起产生多个 Web 服务调用时, 因而您可耗费保管 ThreadPool。

例如, 假定 ThreadPool 仅限于 maxworkerthreads, 10， 而且当时履行一切 10 作业线程正在等候回调来履行代码。 因为作业项排队以 ThreadPool 堵塞线程可用之前可从不履行回调。

其他潜在源抢夺是 maxconnection 参数， System.Net 命名空间用于约束的衔接数。 此约束一般, 按预期作业。 可是, 假如许多应用程序测验使许多恳求到单个 IP 地址一起, 线程或许需求等候一个可用衔接。

处理方案

Machine.config 文件以最合适您状况中要处理这些问题, 可调整以下参数：
◆maxWorkerThreads
◆minWorkerThreads
◆maxIoThreads
◆minFreeThreads
◆minLocalRequestFreeThreads
◆maxconnection
◆executionTimeout

要成功处理这些问题, 请按照下列过程操作：
◆约束一起到大约 12 每 CPU 履行， ASP.NET 恳求的数量。
◆答应 Web 服务回调用于 ThreadPool 中自在线程。
◆挑选一个适当值关于 maxconnections 参数。 根据您挑选的 IP 地址和 AppDomains 运用数。

留意：主张来约束每 CPU 12 ASP.NET 恳求的数量是有点恣意。 可是, 此约束已证明可以合适大多数应用程序。 以上介绍ASP.NET 应用程序依靠machine.config的装备。

【修改引荐】

1. 微软发布ASP.NET MVC 2预览版 多项功用更新
2. ASP.NET服务器自定义控件安全原则
3. ASP.NET编程标准之编码标准浅析
4. 关于ASP.NET Session的一点知道
5. ASP.NET编程东西ASP.NET Web Matrix具体介绍