2
正如第1章所述,ASP.NETISAPI扩展的具体行为取决于应用程序所选择的进程模型.下面将给出其中的两种.IIS5.0进程模型如果将ASP.NET应用程序部署到WindowsServer2003之前任何一个版本的系统中,就只能选择IIS5.0进程模型.根据该进程模型的策略,aspnet_isapi.dll不处理.aspx文件,而是充当调度程序.它将收集有关被调URL和底层资源的所有信息,并将其发送给另一个特殊进程——名为aspnet_wp.exe的ASP.NET
工作进程.ISAPI扩展与工作进程之间的通信是通过命名管道(namedpipe)完成的.
整个模型如图3.2所示.【91】
工作进程的一个副本始终运行,并承托所有活动的Web应用程序.但在Web服务器使用多个CPU时,情况则不同.如果这样,可以对ASP.NET运行库进行配置,允许多个工作进程运行,每个进程对应一个可用CPU.一台服务器的多个CPU上运行多个进程,这样的模型称为"
网络园"(webgarden),可通过machine.config文件的
区段控制.
当单一工作线程被所有CPU使用,并控制所有Web应用程序时,并不一定表示没有实施进程隔离.事实上,每个Web应用程序是通过其虚拟目录标识的,分别从属于独立的应用程序域(通常称为AppDomain).当某个虚拟目录被客户端第一次请求时,ASP.NET工作进程会创建一个新的AppDomain.之后,ASP.NET运行库将加载所有所需的程序集,并将控制权交给托管(hosted)HTTP管道,后者将对该请求做实际的处理.【92】
如果客户端请求的是一个已在运行的Web应用程序,ASP.NET运行库只是将该请求转发给与其虚拟目录相关联的现有AppDomain.如果处理当前页面的程序集没有被该AppDomain加载,则动态创建它;如果在第一次调用时已经被创建,则直接使用.
3
图3.2基于IIS5.0进程模型的ASP.NET运行时环境
IIS6.0进程模型如果Web服务器的操作系统是WindowsServer2003或更高版本,IIS6.0进程模型是ASP.NET的默认选择.该进程模型的名称已明确指出,该模型需要IIS6.0.然而,在WindowsServer2003计算机上,仍可以使ASP.NET按IIS5.0的方式工作.如果要这样做,可以通过更改machine.config的区段,显式地启用该模型:
注意,我们不提倡切换到过去的IIS5.0进程模型(虽然这样做并没有错).主要原因在于,IIS6.0使用的是一种不同的内核模块管道来处理入站请求,只有在仿真模式下工作才能模仿IIS5.0的行为.IIS6.0管道以一种名为w3wp.exe的工作进程为中心.该可执行程序的副本由分配给同一应用程序池的所有Web应用程序共享.用IIS6.0的术语来讲,应用程序池是共享同一工作线程副本的一组Web应用程序.IIS6.0使我们能够对应用程序池进行定制,以达到托管于Web服务器的各种应用程序所需的隔离程度.w3wp.exe工作进程会加载aspnet_isapi.dll,随后,ISAPI扩展加载公共语言运行时(CLR),启动ASP.NET运行时管道,对请求进行处理.若使用IIS6.0进程模型,ASP.NET内建的工作进程便会被禁用.
4
提示:只有ASP.NET1.1和更高版本能够充分利用IIS6.0进程模型.如果在Windows
Server2003计算
机上安装ASP.NET1.0,那么选择默认设置IIS5.0进程模型.之所以会这样,是因为只有ASP.NET1.1搭载的aspnet_isapi.dll能够识别宿主,并在需要时加载CLR.而ASP.NET1.0包含的aspnet_isapi.dll只能将请求发给ASP.NET工作进程,且不会加载CLR.图3.3展示了IIS6.0处理ASP.NET应用程序和其他Web应用程序的过程.【93】
图3.3IIS6.0中的ASP.NET应用程序和其他Web应用程序的处理过程
IIS6.0以内核级模块的形式实现了其HTTP监听程序.因此,所有的输入(incoming)请求会首先被一个驱动程序(http.sys)管理.第三方代码不能与该监听程序进行交互.这样,即使用户模式出现问题,IIS的稳定性也不会受到影响.http.sys驱动程序会监听请求,并将其追加到相应的应用程序池请求队列中.一个叫"Web管理服务"(WebAdministrationService,WAS)的模块会读取IIS元库,并指示http.sys驱动程序创建请求队列,队列数量与元库中注册的应用程序池的数量一致.【94】
总之,使用IIS6.0进程模型,ASP.NET会运行得更快,因为inetinfo.exe(IIS管理服务)与工作进程之间不需要进行任何进程间通信.HTTP请求直接投递给承托CLR的工作进程.此外,ASP.NET工作进程不是特殊的进程,而仅仅是IIS工作进程的副本.这样,回收进程,缓存页面和监视运行状况的负担会由IIS承受.