IIS6 和 IIS7 中 ASP.NET 应用程序的应用程序池最佳实践
我的公司目前使用 IIS6 来运行 ASP.NET 应用程序，但最终将使用 IIS7。是否有任何可以在 IIS6 中实施并延续到 IIS7 的 AppPools 推荐实践？例如，我们应该开始在 IIS6 中使用 AppPool 自定义标识吗？
My company is currently using IIS6 to run ASP.NET applications but will eventually use IIS7. Are there any recommended practices for AppPools that can be implemented now in IIS6 that will carry over to IIS7? For example, should we begin using AppPool custom identities in IIS6?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第一个问题是“这重要吗？”在大多数情况下，您对应用程序池所做的任何操作都不会转移到 IIS7，因为大多数管理员不会就地升级，因此您必须重新创建内容，至少在某种程度上是这样。
就 IIS7 的不同之处而言，唯一想到的是 IIS7 默认情况下将每个站点放入其自己的池中，这在 IIS6 上手动执行是非常非常好的事情。
两者都有默认的 20 分钟应用程序池空闲超时和每日回收，如果您的应用程序是纯粹托管的（没有 COM 依赖项的 ASP.NET），则没有什么意义 - 这是 ASP.OLD 时代的遗留物，当你需要回收网络服务器以进行自卫健身。我建议取消这些限制，看看事情进展如何——如果你需要恢复回收，你总是可以的。 IIS6 和 IIS7 都为您提供了一些其他选项，可以在必要时强制回收。
First question is "does it matter?" In most cases, whatever you do vis-a-vis app pools will not be carried over to IIS7 because most admins would not upgrade in place so you would have to recreate things, at least to some extent.
Insofar as what IIS7 does differently, the only thing that comes to mind is that IIS7 puts each site in it's own pool by default, which is a very, very good thing to do manually on IIS6.
Both also have a default 20 minute app pool idle timeout and a daily recycle which, if your apps are purely managed (ASP.NET with no COM dependencies), makes little sense -- that is a holdover from the era of ASP.OLD when you needed to recycle the web server for self-defensive fitness. I would advise removing these limits and seeing how things go -- if you need to restore the recycle, you always can. And both IIS6 and IIS7 give you some other options to force a recycle should it become necessary.