Iis – limit IIS to use one rather than two processors

I'd be inclined to choose the 2x nelaheim processors configuration. You've said you'll be running a lot of websites which can translate to a lot of web application threads, and 2 4 core processors translates to a lot of multi-tasking ability, and the throughput on the newest intel processors is much improved over their older processors. You should also see some very good memory performance from that architecture too, which should help with serving website content nice and quickly.

You have a fairly unique situation where COM becomes a bottleneck so that you can't simply scale up. Ideally improving performance with the COM objects or replacing them with managed code would scale even better, but you're on the right track for a COM performance workaround.

1. IIS is able to handle hundreds of app pools, so that's not a problem. It will add a few MB of RAM with each app pool but no extra performance overhead.

2. Sure. By app pool, I assume that each is a full site with its own app pool. That's all good.

3. If you don't have to, don't change the processor affinity because it means that you need to maintain and tweak it forever. If the CPU utilization is pretty flat, then you're good with the defaults. If you have other applications on the server or if you see a big imbalance, then consider processor affinity. IIS does a good job of utilizing them for the most part though, so it's best to let it do the heavy work if possible.

4. As you say, sticky sessions addresses that, so you're good. Web gardens may have solved your COM issues if you didn't have InProc session state to worry about. As a side, you can consider using ASP.NET's state server. Have each server use the local state server and have the load balancer use sticky sessions with 1 binding per server. That would address session state (as long as everything serializes, which it usually does) and it will allow you to easily play with the web garden settings without having to mess with the load balancer.