Vertical Scalability with multiple app pools

Question

We are running a ASP.Net application that is also calling some legacy COM objects. We are running into an issue where with increased number of users COM object is creating a bottle neck since it is executing on same thread/process as the app pool.

We currently have a hardware load balancer in place and use sticky sessions to balance the load between 2 servers. Unfortunately this does not seem to be enough. We did some testing using multiple app pools, each running same application, and performance seems to improve significantly.

I have couple of questions.

1. Is it wise to add multiple app pools, all pointing to the same physical files?
2. We would still use hardware load balancer. All requests comming to app.xxxxxx.com would get redirected to for example app1.xxxxxx.com, app2.xxxxxx.com, app3.xxxxxx.com, app4.xxxxxx.com . Each one being an app pool on the same server. Is this a common practice?
3. Server has 16 cores. Would setting processor affinity make sense, to dedicate each app pool to run on 4 cores?
4. We are stuck using InProc sessions. Because of this we are not even considering using Web Garden. Plus from what I read Web Garden is more for improving availability than performance.

I am a developer by trade and it fell on me to research/perform these tasks and a lot of this has been a learning process for me.

Thanks

Answer 1

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.