构建高性能.NET应用 配置高可用IIS服务器 第二篇.pdf

AgileSharp-构建高性能.NET 应用之配置高可用IIS 服务器-第二篇 构建高性能.NET 应用之配置高可用IIS 服务器-第二篇IIS 请求处理模型 在IIS 中，Http 监听者(http.sys)和请求处理者由两个系统服务在控制着。一个是WWW 服 务，另外一个就是Windows Process Activation 。 对于WWW 服务，它主要是监控IIS 的配置文件，将新的配置信息用到HTTP.sys 和WAS 上。 同时它也维持一些性能计数器，把一些数据反应到计数器中，所以，很多的时候，我们可以查看 性能计数器来获取一些与IIS 性能相关的信息。 对于Windows Process Activation ，这个服务的作用就是激活和唤起进程来处理请求，同时 它也对正在运行的处理进程进行管理，例如资源的回收，以及控制着性能相关的一些限制。 在IIS6 中，上面的讲述的功能都是包含在WWW 服务中的，在IIS 7 中，就将上面的功能 分开了。到了这里，我感觉再讲下去，大家可能要犯糊涂了，为了使得后文的讲述更加的方便和 大家的理解更加的深入，这里很有必要把IIS 的架构讲讲，也非常有必要把IIS 6 和IIS 7 进行比较。 首先，我们就来看看IIS 6 的请求的处理模型，如下图所示： 在上图中，我们可以看到： AgileSharp() 安捷雨希提供性能优化，架构设计咨询，内训，解决方案 AgileSharp-构建高性能.NET 应用之配置高可用IIS 服务器-第二篇 1. IIS6 的请求处理模型中包含了两个管道：一个是IIS6 的处理管道，一个是ASP.NET 的 处理管道。 2. 每一个请求的处理都要经过两个管道。当请求经过IIS 的管道的时候，IIS6 就是根据它 的metabase 里面的配置信息来决定把请求给那个来处理。如果是请求与ASP.NET 相关 的内容的，那么请求就会被交个aspnet_isapi.dll 来处理，然后aspnet_isapi.dll 就加载 CLR 运行时，并且开启ASP.NET 的处理管道。 3. 在两个管道中，有一些相同的处理流程，例如身份验证。 另外，ASP.NET 允许我们在处理管道中注册自己的module 或者handler，这一点朋友们都 应该很清楚了。我们一般在ASP.NET 的应用程序级别的事件中注册我们自己的逻辑，当ASP.NET 触发这些事件的时候，我们的代码就运行了。 IIS6 中引入了两个不同的处理管道，引发了下面的问题： 1. 导致了一定程度的重复处理。例如，两个管道中都有身份验证的组件，那么一个请求 就要被验证两次。 2. 因为ASP.NET 的管道在IIS 的管道之后，所以对于每个请求的处理决定完全是由 aspnet_isapi.dll 这个组件来控制的，也就是说ASP.NET 的处理管道无法在早期对请求如 何进行处理下决定。 3. 一旦把请求交给了ASP.NET 的处理管道之后，IIS 的处理管道要等到ASP.NET 处理完毕 之后才能接着处理，而且，一旦ASP.NET 管道处理完之后，ASP.NET 的处理管道无法影 响后续的IIS6 的处理管道。 4. 只有把请求交给了aspnet_isapi.dll 之后，ASP.NET 处理管道才开始启动，并且请求的内 容只能是与ASP.NET 相关的，例如aspx 页面等。ASP.NET 处理管道无法处理对非 ASP.NET 内容的请求，例如图片，脚本等。也就是说：程序在一定的程度上无法对非 ASP.NET 的资源进行验证与授权的保护。 既然IIS6 有上面的一些问题，IIS7 的出现就解决了上述的问题。IIS 7 移除了对aspnet_isapi， 并且将IIS 和ASP.NET 的进行了集成，成为一个管道，如下： AgileSharp() 安捷雨希提供性能优化，架构设计咨询，内训，解决方案 AgileSharp-构建高性能.