.NET程序生产环境下的调试（Production Debugging）（二）

ASP.NET的进程模型和性能监控

ASP.NET进程模型

ASP.NET进程模型就是说一个HTTP Request到IIS以及返回到客户端response的路径。这个进程模型可以在.NET的machine.config中配置。
IIS 5.x进程模型

IIS 5.x进程模型控制ASP.NET请求如何通过IIS并最后由Aspnet_wp.exe来处理的过程。下图就是这个工作过程：

InetInfo和Aspnet_wp执行文件都加载Aspnet_isapi.dll。下面就是处理一个ASP.NET请求的步骤：
1、接收到ASP.NET请求容纳后将它传给ASP.NET ISAPI。在请求加到请求表之后，通过命名管道传送给Aspnet_wp.exe工作进程。
2、工作进程接受到请求之后，它返回一个确认消息并更新请求表，将该请求置为executing状态。（一个处于executing状态的请求在当前的工作进程没有执行完全后，是不可以重新分配到其他工作进程的。）
3、当前的工作进程负责执行这个请求，不过可能需要回调IIS用来获取一些数据，比如服务器变量。
4、页面响应通过IIS异步的发送给客户端。接下来，请求表更新该请求已经结束。

IIS5.x中，aspnet_isapi.dll用来读取machine.config文件中进程模型设置，如果<processModel>里面的内容发送改变，IIS必须重新启动。（IIS 6.0在默认情况下是不用<processModel>里面的内容的。）

ASP.NET HTTP运行时设置的一些参数可以控制ASP.NET的运行状态：

属性	描述
appRequestQueueLimit	ASP.NET 将为应用程序排队的请求的最大数目。当没有足够的自由线程来处理请求时，将对请求进行排队。当队列超出了该设置中指定的限制时，将通过“503 - 服务器太忙”错误信息拒绝传入的请求。 executionTimeout 指示在被 ASP.NET 自动关闭前，允许执行请求的最大秒数。
executionTimeout	指示在被 ASP.NET 自动关闭前，允许执行请求的最大秒数。
maxRequestLength	指示 ASP.NET 支持的最大文件上载大小。该限制可用于防止因用户将大量文件传递到该服务器而导致的拒绝服务攻击。指定的大小以 KB 为单位。默认值为 4096 KB (4 MB)。
minFreeLocalRequestFreeThreads	ASP.NET 保持的允许执行新本地请求的自由线程的最小数目。该线程数目是为从本地主机传入的请求而保留的，以防某些请求在其处理期间发出对本地主机的子请求。这避免了可能的因递归重新进入 Web 服务器而导致的死锁。
minFreeThreads	允许执行新请求的自由线程的最小数目。ASP.NET 为要求附加线程来完成其处理的请求使这些线程保持自由状态。

IIS 5.x的性能监控

当ASP.NET的进程模型打开后，性能监控就开始使用（machine.config中<processModel>）。每2秒钟InetInfo检查每个ASP.NET工作进程的内存大小，完成的请求数量和最后一个响应的时间。当任意一个工作进程的内存大小达到一定的比例时（默认总物理内存的60%，可以通过<processModel>的一个属性来设置），InetInfo会将该Aspnet_wp.exe进程的所有请求挂起，然后启动一个新的进程来处理，然后回收这个老的进程。如果在<processModel>中配置了logLevel属性，将会在系统日志中记录这次重起。
如果在调试的时候进程性能监控是开着的，在你捕获到问题所在之前这个进程可能已经被回收了。如果想让进程在有调试器调试的情况下判断是否回收，可以设置HKLM\Software\Microsoft\ASP.NET\UnderDebugger这个DWORD注册表值。

IIS 6.0在Windows .NET Server (RC1)下的进程模型

在IIS 6.0的“工作进程隔离模式”允许的情况下，所有配置好的Web应用在应用程序池中分组，每个池运行在一个单独的w3wp.exe进程中。在这种新的模式下，Aspnet_Isapi.dll被装载到每个工作进程中，而不是装载到InetInfo.exe中。这样的做法有更高的稳定性，因为如果Aspnet_isapi.dll除了问题，它也只是影响一个工作进程，而不是将整个Web服务器宕掉。

从客户端来的对.aspx和.asmx的请求是由HTTP.sys接收的，这是个kernel级的侦听器，用来处理IIS6.0的所有HTTP信息。接着HTTP.sys将这些请求直接转发到相应的ASP.NET应用的工作进程中。ASP.NET结束请求处理之后，响应由HTTP.sys发回到客户端。

IIS 6.0应用程序池
同IIS5.x一样，IIS 6.0对proactive和reactive回收是区别对待的。IIS对那些已知的情况进行proactive回收，对于那些未知情况或者动态变化的情况进行reactive回收。IIS 6.0检查时间、完成的请求数量、计划时间和使用的内存大小来判断是否进行proactive回收。默认情况下，只有当内存超标的回收才记录在系统日志中，要想记录所有的回收日志，在 \Inetpub\Adminscript目录下运行：
cscript adsutil.vbs set w3svc/apppools/[defaultapppool]/LogEventOnRecycle 0xffffffff
下面的表格是IIS 6.0应用程序池的一些设置参数。

设置参数	描述
Idle Timeout	用来控制IIS是否关闭空闲工作进程。任何一个应用程序池中工作进程空闲达到设定的时间后将被关闭。
Request Queue Limit	用来控制请求队列的大小。这个设置用来防止大量的请求在队列中堆积而造成服务器过载。
CPU Monitoring	用来指定当CPU利用率到达一定值时需要做什么动作
Web Garden	用来控制应用程序池中工作进程的数目
Enable Pinging	用来指定Web Administration Service(WAS)多久来检测应用程序池中每个工作进程的状态
Enable Rapid Fail Protection	用来配置当一定数目的系统崩溃发生时，IIS将该应用程序池从服务中移掉。如果工作进程从服务中移掉，HTTP.sys将给请求返回503错误。
Startup Time Limit	指定允许一个进程启动的时间，如果进程在这个时间限制到达后还没有启动起来，IIS就认为该进程不能正常启动，然后关闭它。关闭进程会在系统日志中记录。
Shutdown Time Limit	指定WAS如何处理在关闭时挂起的工作进程。如果一个工作进程在特定的时间没有关闭，WAS将直接关闭该进程。

孤立出错的ASP.NET的工作进程

如果ASP.NET工作进程不能满足健康工作的标准或者这些进程不能正确响应详细，Web Administration Service (WAS)将会关闭这些进程。这样的话会对调试造成影响，因为在调试器附加前，它已经被关闭了。

不过你可以重新设置WAS，不让它关闭出错的工作进程，只是不让它们处理请求，这就是所谓的孤立出错进程。一个孤立的工作进程从应用程序池中移除了，但是它还保留着它的出错状态为后期调试使用。这种情况下，WAS会新开一个工作进程来处理请求。要设置WAS来孤立出错的工作进程，在\Inetpub\Adminscripts目录下运行：
cscript adsutil.vbs set w3svc/apppools/orphanworkerprocess 1
上面的命令会对所有的应用程序池设置了孤立属性。如果仅对一个特定的应用程序池做设置，运行下面的命令：
cscript adsutil.vbs set w3svc/apppools/<应用程序池名>/orphanworkerprocess 1
如果这样设置了WAS，出错的W3wp.exe将不再被WAS关闭。