我在 IIS 中遇到超时问题。在 web.config 中,会话超时设置为 60 分钟,但 20 分钟后会话结束。
此问题仅在IIS7中出现,在IIS5中不会出现。
经过一番调查,我发现这是由于应用程序池超时造成的。如果应用程序池有 20 分钟没有执行任何操作,IIS 将结束会话。
如果应用程序使用defaultAppPool,这种情况总是会发生,但如果我将应用程序池更改为经典的.NET应用程序池,则不会发生超时。
两种模式都有空闲超时,但是only在 DefaultAppPool 中会发生这种情况。
- 为什么是这样?
- 经典 .NET AppPool 和 DefaultAppPool 之间有什么区别?
- 经典和集成的管道有什么区别?
IIS7 进行了一些重大更改,以更好地支持 WCF,其中关键部分之一是新的集成应用程序池。 PDC 的本次会议从使 WCF 服务性能更好的角度讨论了其中一些挑战:http://channel9.msdn.com/pdc2008/TL38/ http://channel9.msdn.com/pdc2008/TL38/
此页面很好地概述了 IIS7 架构:http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/ 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 中的新架构,
该过程会破坏您的应用程序。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)