IIS7中的DefaultAppPool和Classic .NET AppPool有什么区别？

Question

我在IIS中遇到超时问题.在web.config中,会话超时设置为60分钟,但在20分钟后会话结束.

此问题仅发生在IIS7中而不是IIS5中.

经过一番调查,我发现这是由于应用程序池的超时.如果应用程序池在没有执行任何操作的情况下保留20分钟,则IIS将结束会话.

如果应用程序使用defaultAppPool,则总会发生这种情况,但如果我将App Pool更改为经典的.NET App Pool,则不会发生超时.

两种模式都有空闲超时,但仅在DefaultAppPool中发生这种情况.

• 为什么是这样？
• 经典.NET AppPool和DefaultAppPool有什么区别？
• 经典和集成之间的管道有什么区别？

Answer 1

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传递到托管运行时的身份验证令牌,并且由于IIS 7.0中的新体系结构,该进程会破坏您的应用程序.

Answer 2

经典池通过使用 IIS 和 ISAPI 的单独处理管道来处理应用程序池中的请求。集成使用集成管道，IIS 和 ASP.NET a（更好的性能）仅使用一个进程利用 IIS 7.0 的改进功能。好的做法是为每个应用程序创建一个新的应用程序池，然后根据应用程序需求单独配置。

经典模式遵循以下步骤：

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

2.通过ISAPI处理请求。

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

4.请求通过ISAPI传回。

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

集成模式使用：

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

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

根据以下内容增加 web.config 中的会话超时

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