ASP.NET 应用程序依赖machine.config的配置

开发 后端
本文介绍ASP.NET 应用程序依赖machine.config的配置,以及介绍ASP.NET 的辅助线程和完成端口线程, 调用可用于执行请求数限制可能发生此问题。

由于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详细介绍
责任编辑:佚名 来源: yesky
相关推荐

2009-07-29 17:01:13

2009-07-28 14:54:47

web.config文ASP.NET应用程序

2009-07-21 10:05:10

ASP.NET配置文件

2009-07-22 17:32:40

ASP.NET应用程序

2009-07-21 15:02:19

ASP.NET应用程序

2009-07-23 13:26:21

2009-07-27 16:09:50

2009-07-20 16:08:04

ASP.NET应用程序

2009-08-05 10:16:54

部署ASP.NET应用

2009-12-10 15:35:10

ASP.Net 2.0

2009-07-29 17:21:10

2009-07-29 10:30:53

Web应用程序ASP.NET

2009-07-27 17:46:42

WCF服务ASP.NET应用程序

2009-07-21 15:14:32

预编译应用程序ASP.NET

2009-07-28 10:11:06

ASP.NET应用程序

2009-07-23 14:25:03

ASP.NET 2.0

2009-07-24 11:25:53

Web应用程序工程ASP.NET MVC

2009-07-22 18:07:55

论坛应用程序ASP.NET MVC

2009-07-22 18:02:27

论坛应用程序ASP.NET MVC

2009-07-23 13:14:20

ASP.NET应用程序
点赞
收藏

51CTO技术栈公众号