比较IIS5、IIS6、IIS7的ASP.net请求处理过程

Posted 2023-04-25

参考技术A         SP NET是一个非常强大的构建Web应用的平台 它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用         绝大多数的人只熟悉高层的框架如 WebForms 和 WebServices 这些都在ASP NET层次结构在最高层

　　这篇文章的资料收集整理自各种微软公开的文档 通过比较 IIS IIS IIS 这三代 IIS 对请求的处理过程 让我们熟悉 ASP NET的底层机制 并对请求(request)是怎么从Web服务器传送到ASP NET运行时有所了解 通过对底层机制的了解 可以让我们对 有更深的理解

　　IIS 的 请求处理过程

　　

IIS 的请求处理过程

　　对图的解释

　　IIS x 一个显著的特征就是 Web Server 和真正的 ASP NET Application 的分离 作为 Web Server 的IIS运行在一个名为 InetInfo exe 的进程上 InetInfo exe 是一个Native Executive 并不是一个托管的程序 而我们真正的 ASP NET Application 则是运行在一个叫做 aspnet_wp 的 Worker Process 上面 在该进程初始化的时候会加载CLR 所以这是一个托管的环境

　　ISAPI   指能够处理各种后缀名的应用程序 ISAPI 是下面单词的简写 Internet Server Application Programe Interface 互联网服务器应用程序接口

　　IIS 模式的特点

　　 首先 同一台主机上在同一时间只能运行一个 aspnet_wp 进程 每个基于虚拟目录的 ASP NET Application 对应一个 Application Domain 也就是说每个 Application 都运行在同一个 Worker Process 中 Application之间的隔离是基于 Application Domain 的 而不是基于Process的 　　　 其次 ASP NET  ISAPI 不但负责创建 aspnet_wp Worker Process 而且负责监控该进程 如果检测到 aspnet_wp 的 Performance 降低到某个设定的下限 ASP NET  ISAPI 会负责结束掉该进程 当 aspnet_wp 结束掉之后 后续的 Request 会导致ASP NET ISAPI 重新创建新的 aspnet_wp Worker Process

　　 最后 由于 IIS 和 Application 运行在他们各自的进程中 他们之间的通信必须采用特定的通信机制 本质上 IIS 所在的 InetInfo 进程和 Worker Process 之间的通信是同一台机器不同进程的通信（local interprocess munications） 处于Performance的考虑 他们之间采用基于Named pipe的通信机制 ASP NET ISAPI和Worker Process之间的通信通过他们之间的一组Pipe实现 同样处于Performance的原因 ASP NET ISAPI 通过异步的方式将Request 传到Worker Process 并获得 Response 但是 Worker Process 则是通过同步的方式向 ASP NET ISAPI 获得一些基于 Server 的变量 　

　　IIS 的 请求处理过程

　　

IIS 的 请求处理过程

　　对图的解释

　　IIS x 是通过 InetInfo exe 监听 Request 并把Request分发到Work Process 换句话说 在IIS x中对Request的监听和分发是在User Mode中进行 在IIS 中 这种工作被移植到kernel Mode中进行 所有的这一切都是通过一个新的组件 sys 来负责 　　　注 为了避免用户应用程序访问或者修改关键的操作系统数据 windows提供了两种处理器访问模式 用户模式（User Mode）和内核模式（Kernel Mode） 一般地 用户程序运行在User mode下 而操作系统代码运行在Kernel Mode下 Kernel Mode的代码允许访问所有系统内存和所有CPU指令 　　　在User Mode下 sys接收到一个基于 aspx 的 request 然后它会根据IIS中的 Metabase 查看该基于该 Request 的 Application 属于哪个Application Pool 如果该Application Pool不存在 则创建之 否则直接将 request 发到对应Application Pool 的 Queue中 　　　每个 Application Pool 对应着一个Worker Process w wp exe 毫无疑问他是运行在User Mode下的 在IIS Metabase 中维护着 Application Pool 和worker process的Mapping WAS（Web Administrative service）根据这样一个mapping 将存在于某个Application Pool Queue的request 传递到对应的worker process（如果没有 就创建这样一个进程） 在 worker process 初始化的时候 加载ASP NET ISAPI ASP NET ISAPI 进而加载CLR 最后的流程就和IIS x一样了 通过AppManagerAppDomainFactory 的 Create方法为 Application 创建一个Application Domain 通过 ISAPIRuntime 的 ProcessRequest处理Request 进而将流程进入到ASP NET Http Runtime Pipeline

　　IIS   的 请求处理过程

　　IIS 站点启动并处理请求的步骤如下图

　　步骤 到 是处理应用启动 启动好后 以后就不需要再走这个步骤了

　　

　　

IIS   的 请求处理过程

　　上图的 个步骤分别如下

　　 当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时 HTTP sys 拦截到这个请求 HTTP sys contacts WAS to obtain information from the configuration store

　　 WAS 向配置存储中心请求配置信息 nfig WWW 服务接受到配置信息 配置信息指类似应用程序池配置信息 站点配置信息等等 WWW 服务使用配置信息去配置 HTTP sys 处理策略 WAS starts a worker process for the application pool to which the request was made

　　 The worker process processes the request and returns a response to HTTP sys

　　 客户端接受到处理结果信息

　　W WP exe 进程中又是如果处理得呢？？ IIS 的应用程序池的托管管道模式分两种 经典和集成 这两种模式下处理策略各不相通

　　IIS 以及 IIS 经典模式的托管管道的架构

　　在IIS 之前 ASP NET 是以 IIS ISAPI extension 的方式外加到 IIS 其实包括 ASP 以及 php 也都以相同的方式配置（PHP 在 IIS 采用了两种配置方式 除了 IIS ISAPI extension 的方式 也包括了 CGI 的方式 系统管理者能选择 PHP 程序的执行方式） 因此客户端对 IIS 的 HTTP 请求会先经由 IIS 处理 然后 IIS 根据要求的内容类型 如果是 html 静态网页就由 IIS 自行处理 如果不是 就根据要求的内容类型 分派给各自的 IIS ISAPI extension 如果要求的内容类型是 ASP NET 就分派给负责处理 ASP NET 的 IIS ISAPI extension 也就是 aspnet_isapi dll 下图是这个架构的示意图

　　

　　

IIS 的执行架构图 以及IIS 应用程序池配置成经典模式的执行架构图

　　IIS 应用程序池的 托管管道模式  经典  模式也是这样的工作原理 这种模式是兼容IIS 的方式 以减少升级的成本

　　IIS  应用程序池的 托管管道模式  集成模式

　　

　　

IIS 的执行架构图（集成托管信道模式下的架构）

　　小结

　　IIS 到 IIS 的改进 主要是 HTTP sys 的改进

lishixinzhi/Article/program/net/201311/13216

IIS+ASP.NET MVC必须知道的事

来源：东汉

cnblogs.com/michaeldonghan/p/9277302.html

问题现象

ASP.NET MVC 站点部署在IIS上后，第一个用户第一次访问站点，都会比较慢，确切的说是访问站点的Action页面（即非静态页面，因为静态页面直接由IIS处理返回给用户即完成请求，而Action页面IIS要转交给Aspnet_Wp工作进程，进而涉及相关初始化操作，这些初始化操作是比较慢的。第二次访问站点就不需要再初始化了所以就快了）。

这种第一次访问慢的问题不仅发生在网站第一次部署启动，也发生在站点重启和站点程序池回收（经测试，第一次部署启动初始化所用时间会多一些，然后是站点重启，然后是站点回收）。

1、站点重启包含手动重启和修改web.config配置、修改IIS上站点配置、更新站点bin目录的dll等引起的自动重启。如果你的站点是新上线的web或者会持续修改添加功能的web，那难免会更新dll导致重启。其它编译型语言(比如java)也是如此，更新了服务端组件，都难免要重启站点。这边会分享.net环境下如何优化此问题；

2、站点程序池回收是IIS建议的，本来默认是29小时回收一次。为什么要建议回收呢，大致可以这样理解：一个每日定时回收的机制就像是在发生轻微内存泄露或者其它拖累Worker进程的因素的情况下，刷新IIS的良药，站点回收即节省了资源又提高了稳定性。

然而，自动回收后第一次访问慢的问题困扰了许多人，其实只要稍微设置就可以解决，即没有困扰也拥有了回收的优点。

问题解决

1、先在IIS上设置相应应用程序池的“高级设置”（IIS版本要在8或8以上，要知道IIS10早已出来了，如果你在用IIS很低的版本，然后在报怨IIS，我...），如下图，这样设置后，回收只会发生在凌晨04:00:00

要确定有安装IIS应用程序初始化功能，如下图

2、在IIS上设置站点的“高级设置”，把【预加载已启用】设置为true。

设置完这两步，当站点(自动)回收时，访问站点也是秒开不受任何影响，它的原理是在回收时会保持站点持续运行，这样的回收可以理解为把旧的Worker内容平滑的移到新的Worker上，然后回收掉旧的Worker。

但是要注意，回收会导致站点内存信息丢失，因此如果你的设计是把session放在内存，则就要设置永不自动回收，那只要在第1步的基础上把【特定时间】清空即可。

不过我个人会建议你不要设计session放内存，你更新个dll导致站点重启，内存也是清空的，你不如把session放在memcache/redis中，如果你的系统还没用上这些，那你就用cookie代替session吧，cookie更灵活适用的场景也更多。

现在回收的问题完美解决了，接下来说说站点重启。站点重启肯定是要重新加载配置重新加载dll（不想重新加载dll的，看文章最后一段），初始化是免不了，默认重启后第一个用户第一次访问站点会触发初始化，那么我们可以在站点启动/重启时，系统自动发一个站点请求，让系统自己尝尝第一次访问慢的问题。

IIS站点启动时机自动请求站点

1、启动站点时触发的时机

创建一个类，继承自IProcessHostPreloadClient接口，其Preload方法就是启动站点时触发。然后在里面自动访问站点，如下代码：

public class ApplicationPreload : System.Web.Hosting.IProcessHostPreloadClient

{

     public void Preload(string[] parameters)

     {         

         try

         {

             //自动请求的url，其中http://localhost:8001 最好配置在config中，这边只是演示。

             string url = "http://localhost:8001/home2/about";

             using (var webClient = new WebClient())

             {

                 webClient.DownloadStringAsync(new Uri(url));//要异步请求

             }

         }

         catch (Exception e)

         {

             MvcApplication.DoLogToTxt("Preload Error:" + e.Message);

         }

     }

}

2、修改IIS配置文件，让IIS能识别到刚写的ApplicationPreload类

打开IIS配置文件：%WINDIR%System32inetsrvconfigapplicationHost.config 

<applicationPools>

    <add name="MyAppWorkerProcess" managedRuntimeVersion="v4.0" startMode="AlwaysRunning" /> <!-- 上面我们在IIS程序池界面中有设置过startMode项为AlwaysRunning-->

</applicationPools>

<!-- ... -->

<sites>

    <site name="MySite" id="1">

        <application path="/" serviceAutoStartEnabled="true" serviceAutoStartProvider="ApplicationPreload" />

    </site>

</sites>

<serviceAutoStartProviders>

    <add name="ApplicationPreload" type="WebApplication1.ApplicationPreload, WebApplication1" />

</serviceAutoStartProviders>

最后一个条目的type，其中WebApplication1.ApplicationPreload是应用程序中实现IProcessHostPreloadClient接口的类的全名，WebApplication1是程序集名称。 

设置完这两步也就搞定了启动站点时自动访问站点。 

探讨

在上面设置之前，我测试只更新站点部分dll，第一次访问需要1~4秒，测试的站点是含有CMS源码的站点，不算小了。

之前有个面试官说他们公司站点更新一个dll，第一次访问需要10~30秒，甚至更久，这样正在访问站点的用户就要等待，然后一直在报怨IIS和.Net，想要投奔java的怀抱（这里不比较两种语言，它们各自有自己的优势），我问他是不是在Global.asax里Application_Start做了太多自己的初始化，要么有些初始化在用户访问到时处理负担分担出去，要么Application_Start异步处理初始化动作，但是他说这些自己的初始化都是用户访问前必须初始化好的。

这应该是自己系统设计不够好不能怪.NET，如果是用了七七八八的第三方组件，比如EF初始化慢，那就换成轻量级的Dapper，然后好好学习一下《N种提升Asp.Net Mvc性能的方法》不要闭门造车。

（你们更新一个站点的dll，第一次访问需要多少秒呢？）

那么，在上面设置之后 ，如果更新站点dll后第一次访问需要1~4秒的情况下，系统自动帮你做了第一次访问，很可能正在访问的用户就不怎么察觉得出来站点有重启过。

如果是高并发访问的大型网站，那就应该有负载均衡（IIS可以用NLB做负载均衡，或考虑CDN或DNS解析时就做负载均衡），应该有分布式等。

最后 ，如果你的站点是因为更新dll而导致站点重启，而且对此问题深恶痛绝，那么可以用.NET的动态加载dll来解决，不是用AppDomain动态加载和卸载dll（这个太麻烦），而是用Assembly.LoadFile加载dll。

比如Controller所在的dll是MvcA.dll，它引用了LibA.dll，当这两个dll都有修改时，如何让站点加载到这两个最新版本的dll。

这个可以解决的，如果实际应用中需要此需求的人多（请回复评论），我会再整理分享出来。 

看完本文有收获？请转发分享给更多人

关注「DotNet」，提升.Net技能