回收应用程序池



8.4.1  回收应用程序池

使用IIS 5.0时，如果一个运行于低隔离模式或运行于中隔离模式的Web网站发生了一次失效，那么重启网站的唯一方法就是重启整个IIS。这样做会导致IIS突然停止服务，所以，在重启过程中到达的请求都将发生失效。

IIS 6.0引入了一种革命性的概念，即重叠处理的概念。基于重叠处理的概念，即使一个应用程序池被回收，所有后来到达的请求仍然可以继续得到服务。IIS 7.0仍然支持这个概念。如果某个应用程序池被回收，那么现有的工作进程并没有马上退出，而是启动第二个工作进程，一旦第二个工作进程启动成功，Http.sys随即将所有的新请求发送给这个新的工作进程。当现有的工作进程处理完所有请求之后即关闭退出。因为Http.sys可以在将到达的请求发送给新的工作进程之前，完成对已到达请求进行排队处理的操作，因此，在回收应用程序池的过程中，不会发生丢失页面请求的现象。

图8-5解释了DefaultAppPool在回收时的情况。注意：当PID为3168的进程已经启动时，一个PID为3920的老进程仍然在运行。只有当PID为3168的新进程处于Running状态时，新的请求才会被发送给这个进程。因此，在短暂时间内，当我们刷新IIS Manager时，可能会看到PID为3168的进程处于Running状态，同时，PID为3920的进程处于Stopping状态。

（点击查看大图）图8-5

尽管在回收应用程序池的过程中不会发生页面请求丢失现象，也不会出现页面请求发生失效的情况，但是对回收过程而言，确实可能存在不良影响，这是因为在回收应用程序池的过程中，所有保存在工作进程中的数据都将丢失。默认情况下，ASP.NET保存了会话状态数据和进程内缓存数据(我们称之为InProc数据)。这些数据的有效时间与工作进程的存活时间完全相同，因此在回收应用程序池的过程中，必须重新创建这些数据。所以，必须考虑在进程外保存会话状态数据。可以在StateServer、SqlServer，或其他外部会话状态存储区中保存会话状态数据。此外，当启动一个新的工作进程时，可能会发生加载性能问题。此时，IIS和ASP.NET的各个方面内容都必须加载到工作进程中，因此总的来说加载时间还是比较长的，常常需要耗费几秒钟的时间。因此，与应用程序池正常运行情况相比，应用程序池回收之后运行的第一个页面常常要花费更多时间才能正常运行。

进程重叠功能为管理员提供了前所未有的支持。这也意味着：在回收一个应用程序池的过程中，我们只会受到极小的不良影响。特别是当会话状态处于未使用的情况下，或会话状态数据保存在进程外的情况下，影响会更小一些。