文章作者：勇敢的风 信息来源：邪恶八进制安全小组 这个问题已经困扰我很久了，由于时间太长我也记不起来到底有多久了，反正很长时间。近来由于我的针对个人提供空间服务的站点《个人家园》再次出现该问题，我不得不对此问题重新考虑。 以前在MS的官方站点上搜索到关于ASP假死的一个解决方法： asp x?scid=kb;zh-cn;831464" target=_blank>http://support.microsoft测试数据/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、设定应用程序池应根据下设站点的总访问量来设定，不好意思的是我不知道多少的访问量应设定一个应用程序池。
查看更多关于关于IIS 6.0 ASP假死问题的重新考虑与认识（完整篇的详细内容...