由于旧的 ISAPI 过滤器迟早会消亡，我想将 IIS 6 中使用的旧 ISAPI 过滤器重写为用于 IIS 7 的模块。该模块将在全球范围内使用，这意味着它将在每个站点中使用，在安装了 IIS 7.5 的 Windows Server 2008 R2 上，将托管数千个网站并管理大约 50 个应用程序池。
我现在的问题是我应该用托管代码还是非托管代码编写该模块？我对托管代码的担忧之一是 .NET 框架开销导致的大量内存消耗。我不知道这会如何影响服务器的性能。
我已经在托管代码和非托管代码中编写了模块。所以这不是困扰我的决定。但如果没有很大的缺点，我更愿意用 C# 编写模块。
对这个问题有什么建议吗？
【问题讨论】：
标签： iis-7 module unmanaged native managed
Rick Strahl offered sound advice 关于这个主题，我在 learn.iis.net 的文章中多次看到该主题。
了解利用所有这些能力做错事的可能性也很重要。首先请记住，托管代码比 Web 服务器中的本机代码慢。将托管代码引入核心服务器会降低 Web 服务器的性能。具体来说，在集成模式下运行并且存在托管模块时，托管代码和非托管代码之间的上下文切换代价高昂。我与一些 Microsoft 开发人员交谈过，他们正在努力优化这些上下文切换，尝试尽可能多地批量调用托管代码组件，尽可能长时间地保留在托管代码中。
默认情况下托管代码是可选的 - 所有核心模块都是本机代码，因此添加托管模块是您必须做出的明确决定。 如果您已经在使用 ASP.NET，那么这个决定可能是明智之举。但是如果您现在正在运行原始 ISAPI 扩展或模块，您可能需要仔细研究一下看看托管代码在性能方面是否适合。
简而言之，如果所有应用程序都是 ASP.NET，那么为 IIS 编写托管模块应该很少或没有开销——这是一个简单的选择。
但是，如果网站不会加载 CLR，那么为了执行您的模块而这样做会很昂贵，您需要仔细考虑（衡量！）影响以确定性能损失是否值得在开发时提高生产力。
【讨论】：
视情况而定。
如果您可以管理所有应用程序，请进行管理。这允许纯托管堆栈。我会为此而努力；）
关于记忆 - 忘记它。严重地。 IIS 7 核心是托管的，根据需要挂接到旧堆栈中。所以，不管你喜不喜欢，你已经有了 .NET。另外，现代服务器有相当多的内存——即使池运行 32 位（强烈推荐），仍然有 50 个池；）服务器的内存不是 64mb ；）
【讨论】：