问DefaultAppPool和IIS7中的经典.NET AppPool有什么不同？

EN

IIS7有一些重大的变化，以更好地支持WCF，其中一个关键部分是新的集成应用程序池。来自PDC的这次会议从让WCF服务表现得更好的角度讨论了其中一些挑战：http://channel9.msdn.com/pdc2008/TL38/

这个页面很好地概述了IIS7架构：http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/。关于下面两种不同类型的应用程序池的用途，我已经包含了本文中的一些关键信息：

集成应用程序池模式

当应用程序池处于集成模式时，您可以利用IIS和ASP.NET的集成请求处理体系结构。当应用程序池中的工作进程收到请求时，该请求将通过一个有序的事件列表。每个事件都会调用必要的本机和托管模块，以处理请求的某些部分并生成响应。在集成模式下运行应用程序池有几个好处。首先，将IIS和ASP.NET的请求处理模型集成到一个统一的流程模型中。此模型消除了以前在IIS和ASP.NET中重复的步骤，如身份验证。此外，集成模式支持对所有内容类型提供托管功能。

标准应用程序池模式

当应用程序池处于经典模式时，IIS 7.0将像在IIS 6.0辅助进程隔离模式下一样处理请求。ASP.NET请求首先在IIS中经过本机处理步骤，然后被路由到Aspnet_isapi.dll，以便在托管运行时中处理托管代码。最后，通过IIS将请求路由回以发送响应。这种IIS和ASP.NET请求处理模型的分离导致了一些处理步骤的重复，例如身份验证和授权。此外，诸如表单身份验证之类的托管代码功能仅可用于ASP.NET应用程序或其脚本映射了要由aspnet_isapi.dll处理的所有请求的应用程序。在将生产环境升级到IIS 7.0并在集成模式下将应用程序分配到应用程序池之前，请确保在集成模式下测试现有应用程序的兼容性。如果应用程序无法在集成模式下工作，则只应在经典模式下将该应用程序添加到应用程序池中。例如，您的应用程序可能依赖于从IIS传递到托管运行库的身份验证令牌，并且由于IIS7.0中的新体系结构，该进程会中断您的应用程序。

传统池通过对IIS和ISAPI使用单独的处理流水线来处理应用程序池中的请求。集成使用集成的管道，IIS和ASP.NET a(更好的性能)利用了IIS7.0的改进功能，只使用一个进程。好的做法是为每个应用程序创建一个新的应用程序池，然后根据应用程序需求分别进行配置。

经典模式遵循以下步骤：

1.传入的HTTP请求通过IIS核心接收。

2.通过ISAPI处理请求。

3.通过ASP.NET处理请求。

4.请求通过ISAPI传回。

5.请求通过IIS核心传回，HTTP响应最终在IIS核心中传递

集成模式使用：

1.传入的HTTP请求通过IIS core和ASP.NET接收。

2.适当的处理程序执行请求并传递HTTP响应

根据需要增加web.config中的会话超时

​

请记住，增加此值会导致应用程序消耗更多资源，例如内存

我认为你的问题已经有了答案。IIS 6和7有应用程序池超时的概念，这不同于会话超时。

模式之间的区别是什么？已经解决了。我不确定你关于管道和模式差异的问题与你的问题--超时--有什么关系。

一些观点:空闲超时不会发生在任何流量的网站上。你可能遇到了一个问题，这个问题只出现在QA站点或你的开发框中。空闲超时设置的存在是为了节省你的开发箱和每月5美元的主机公司的资源，这些公司有很多未充分使用的网站(例如我的博客)。您可能不希望在公共站点上出现空闲超时。

Session timeout -在web配置中设置，如果用户未访问服务器，则其会话超时。

空闲超时无人接触web服务器达20分钟，因此关闭以节省资源。在IIS 6中，这是在应用程序池的性能选项卡上-并且很容易禁用。在IIS7中，您可以在应用程序池高级设置或processModel element中设置。我运行的IIS7没有IIS6多，但是它看起来像是从web.config中删除元素，或者设置为0，会得到无限的空闲超时。