IIS7 Modules - managed or native?

Question

Hi all,
as the old ISAPI filters are going to die sooner or later, I want to rewrite an old ISAPI filter that was used in IIS 6 into a module for use in IIS 7. The module will be used globally, meaning it will be used within each site, on a Windows Server 2008 R2 with IIS 7.5 installed, that will host several thousand web sites and managing about 50 application pools.
My question now is if I should write that module in managed or unmanaged code? One of my concerns regarding managed code is the massive memory consumption due to the .NET framework overhead. I don't know how this would effect the server's performance.
I already wrote modules in managed as well as in unmanaged code. So this is not the bothering my decision. But I would prefer to write the module in C# if there are no huge drawbacks.
Any suggestions about that issue?

Answer 1

Depends.

Go managed if you can keep all applications managed. This allows a pure managed stack. I would push for that ;)

Regarding memory - forget it. Seriously. IIS 7 core is managed, hooking in the legacy stack as needed. So, you have .NET already, whether you like it or not. Plus, modern servers have quite a bit of memroy - even with the pools running 32 bit (strongly recommended), there stil lare 50 pools ;) not 64mb RAM for a server ;)

Answer 2

Rick Strahl offered sound advice on this topic which I have seen echoed several times in articles at learn.iis.net.

It’s also important to understand the potential for doing the wrong thing with all of this power. First keep in mind that managed code is slower than native code in the Web server. By introducing managed code into the core server you are slowing down the performance of the Web server. Specifically, the context switches between managed and unmanged code are expensive when running in Integrated Mode and with managed modules present. I’ve talked to some of the Microsoft developers, and they are taking a hard look at optimizing these context switches by trying to batch calls to managed code components as much as possible, staying in managed code as long as possible.

Managed code is optional by default-all the core modules are native code, so adding managed modules is an explicit decision you have to make. If you’re already using ASP.NET then this decision is probably a no-brainer. But if you’re running raw ISAPI extensions or modules today, you’ll probably have to take a long hard look to see whether managed code is going to be a good fit in terms of performance.

In short, if all of the applications are ASP.NET, then there should be little or no overhead from writing managed modules for IIS - an easy choice.

However, if the web sites would not otherwise be loading the CLR, then doing so in order to execute your module will be expensive and you'll want to carefully consider (measure!) the impact to determine if the performance hit is worth the development-time productivity gains.