IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有啥区别?
Posted
技术标签:
【中文标题】IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有啥区别?【英文标题】:What is the difference between DefaultAppPool and Classic .NET AppPool in IIS7?IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有什么区别? 【发布时间】:2010-10-20 01:07:38 【问题描述】:我在 IIS 中遇到超时问题。在 web.config 中,会话超时设置为 60 分钟,但 20 分钟后会话结束。
此问题仅在 IIS7 中出现,在 IIS5 中不会出现。
经过一番调查,我发现这是由于应用程序池超时。如果 App Pool 有 20 分钟没有做任何事情,IIS 将结束会话。
如果应用程序使用的是 defaultAppPool,这总是会发生,但如果我将应用程序池更改为经典的 .NET 应用程序池,则不会发生超时。
两种模式都有空闲超时,但只有在 DefaultAppPool 中会发生这种情况。
这是为什么呢? 成为 Classic .NET AppPool 和 DefaultAppPool 有什么区别? Classic 和 Integrated 之间的管道有何区别?【问题讨论】:
【参考方案1】:经典池通过使用 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 中的会话超时时间
请记住,增加这会导致应用程序消耗更多资源,例如内存
【讨论】:
【参考方案2】:我认为你的问题已经有了答案。 IIS 6 和 7 有一个应用程序池超时的概念,这与会话超时不同。
模式之间有什么区别...已经解决。我不确定您关于管道和模式差异的问题如何与您的问题相关 - 超时。
一些观点:空闲超时不会发生在有任何流量的网站上。您可能遇到了仅出现在 QA 站点或您的开发箱中的问题。空闲超时设置的存在是为了节省您的开发箱和每月 5 美元的托管公司的资源,这些公司有很多未充分利用的网站(例如我的博客)。您可能不希望公共站点上的空闲超时。
会话超时 - 在网络配置中设置,如果用户没有访问服务器,他们的会话超时。
空闲超时 20 分钟内根本没有人接触网络服务器,因此请关闭以节省资源。在IIS 6 中,它位于应用程序池的性能选项卡上 - 并且很容易禁用。在 IIS 7 中,您可以在应用程序池高级设置或processModel element 中进行设置。我运行的 IIS 7 不如 IIS 6 多,但看起来从 web.config 中删除元素或设置为 0 会获得无限空闲超时。
【讨论】:
【参考方案3】:DefaultAppPool 会忽略 web.config 中的会话超时设置,但 ASPNet 应用程序池将使用 web.config 中的设置。
【讨论】:
【参考方案4】: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 中的新架构, 该过程会破坏您的应用程序。
【讨论】:
以上是关于IIS7 中的 DefaultAppPool 和 Classic .NET AppPool 有啥区别?的主要内容,如果未能解决你的问题,请参考以下文章
IIS 7sharepoint打不开 HTTP Error 503.DefaultAppPool和sharepoint服务无法启动
从 WCF 服务如何以当前用户而不是 IIS\DefaultApppool 的身份调用第三方 dll 中的方法