ASP.NET应用程序中依赖machine.config的配置是怎么样的

这期内容当中小编将会给大家带来有关ASP.NET应用程序中依赖machine.config的配置是怎么样的，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

创新互联是一家专注于成都网站建设、网站建设与策划设计,文山州网站建设哪家好?创新互联做网站,专注于网站建设十载,网设计领域的专业建站公司;建站业务涵盖:文山州等地区。文山州做网站价格咨询:18980820575

由于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:
◆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:
◆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:
◆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的配置是怎么样的了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。