构建高性能.NET应用之配置高可用IIS服务器-第二篇 IIS请求处理模型

2019-04-14 18:18发布

         IIS 中,Http监听者(http.sys)和请求处理者由两个系统服务在控制着。一个是WWW 服务,另外一个就是Windows Process Activation   对于WWW服务,它主要是监控IIS的配置文件,将新的配置信息用到HTTP.sysWAS上。同时它也维持一些性能计数器,把一些数据反应到计数器中,所以,很多的时候,我们可以查看性能计数器来获取一些与IIS性能相关的信息。   对于Windows ProcessActivation,这个服务的作用就是激活和唤起进程来处理请求,同时它也对正在运行的处理进程进行管理,例如资源的回收,以及控制着性能相关的一些限制。          IIS6中,上面的讲述的功能都是包含在WWW服务中的,在IIS 7中,就将上面的功能分开了。到了这里,我感觉再讲下去,大家可能要犯糊涂了,为了使得后文的讲述更加的方便和大家的理解更加的深入,这里很有必要把IIS 的架构讲讲,也非常有必要把IIS 6IIS 7进行比较。          首先,我们就来看看IIS6的请求的处理模型,如下图所示:     640?wx_fmt=png
         在上图中,我们可以看到: 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,并且将IISASP.NET的进行了集成,成为一个管道,如下: 640?wx_fmt=png
一个请求的处理流程变的简单了,效率应该会提高。事实也确实如何,并且一个请求的线程切换次数也变少了,这极大的提升了性能(不用把请求从IIS的线程切换到ASP.NET的处理线程)。 通过改进,IIS 7解决了上述我们提到的几个问题: 1.      集成管道中不会包含重复的组件。 2.      ASP.NETmodulehandler可以在管道的如何地方发挥作用,从而使得我们可以对请求的处理流程进行完全的控制。 3.      可以处理对非ASP.NET内容的请求。 相关内容
作者介绍:汪洋,哪合伙CEO,曾大汉电子商务有限公司首席技术官,副总裁,负责公司产品、技术、运营,参与商业模式设计。华康移动医疗前CTO,副总裁,首席架构师。微软MVP

.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注 640?wx_fmt=jpeg 赞赏 人赞赏