关于IIS 6.0 ASP假死问题的重新考虑与认识（完整篇）

文章作者：勇敢的风
信息来源：邪恶八进制安全小组

  这个问题已经困扰我很久了，由于时间太长我也记不起来到底有多久了，反正很长时间。近来由于我的针对个人提供空间服务的站点《个人家园》再次出现该问题，我不得不对此问题重新考虑。

  以前在MS的官方站点上搜索到关于ASP假死的一个解决方法： http://support.microsoft.com/default.aspx?scid=kb;zh-cn;831464 在看到该补丁前的解决方法是采用IIS5隔离模式，看到该补丁后原以为问题该解决了，可是还是不行。

  这些天在看系统日志的时候发现每当ASP假死后在系统日志中会出现一条错误信息和一条警告信息，如下：
=============================================================
错误信息：
服务 World Wide Web Publishing Service 意外停止。这发生了 2 次。
来源：Service Control Manager
-------------------------------------------------------------
警告信息：
为应用程序池 DefaultAppPool 提供服务的进程 ID 为 5088 的 worker 进程已经请求回收，因为 worker 进程达到了允许的运行时间限制。
来源：W3SVC
=============================================================

  看到以上信息再结合原始的解决方法，猜想该问题为应用程序池造成的，因为采用隔离模式时是没有应用程序池的，于是开始寻找有关于应用程序池的资料，并得到一下认识：

  1、工作进程：靠，真不知道MS是怎么起名的，命名是ASP的Session所产生的连接数，他却叫做工作进程。
  2、回收工作进程：清空所有采用该应用程序池的站点中当前使用Session对象。
  3、解决方法应该就是怎么回收（猜想）；

  于是将应用程序池中的回收方式做一下修改：只采用定时回收的方法，在0:00、12:00、19:00三个时间进行回收。至于效果如何且看使用后分解。

（未完...）

-------------------------------------------------------------------------------------------------
（续）

    经过一个多月的测试再未发现出错，说明该方法确实可行，简单总结一下：

  1、以上设定有弊端：仅仅这样设定是不够的，因为当该应用程序池下的站点越来越多时，以上设定可能将会出现问题。
  2、对于访问量过大的站点应单独开设应用程序池。
  3、每个应用程序池下设定的站点不要过多。
  4、设定应用程序池应根据下设站点的总访问量来设定，不好意思的是我不知道多少的访问量应设定一个应用程序池。