DefaultAppPool与IIS 7中的经典.NET AppPool有什么区别?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (22)

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

此问题只发生在IIS7中,而不是在IIS5中。

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

如果应用程序使用defaultAppPool,则始终会发生这种情况,但如果将App Pool更改为传统的.NET App Pool,则不会发生超时。

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

  • 为什么是这样?
  • Classic .NET AppPool和DefaultAppPool有什么区别?
  • Classic和Integrated之间的管道有什么不同?
提问于
用户回答回答于

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

经典模式遵循以下步骤:

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

2.请求通过ISAPI处理。

3.该请求通过ASP.NET进行处理。

4.请求通过ISAPI传回。

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

集成模式使用:

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

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

按照每次增加web.config中的会话超时

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

用户回答回答于

为了更好地支持WCF,IIS7进行了一些重大更改,其中一个关键部分是新的集成应用程序池。来自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请求处理模型的这种分离会导致某些处理步骤(如身份验证和授权)的重复。此外,托管代码功能(例如表单身份验证)仅适用于您已将脚本映射到aspnet_isapi.dll处理的所有请求的ASP.NET应用程序或应用程序。在将生产环境升级到IIS 7.0并将应用程序分配到集成模式下的应用程序池之前,请确保在集成模式下测试现有应用程序的兼容性。如果应用程序无法在集成模式下工作,则应该只在Classic模式下将应用程序添加到应用程序池。例如,您的应用程序可能依赖于从IIS传递到托管运行时的身份验证令牌,并且由于IIS 7.0中的新架构,该进程会中断您的应用程序。

扫码关注云+社区