ASP.NET Web Garden - How Many Worker Processes Do I Need?

What is the best practice for deciding how many worker processes to allow for an ASP.NET web application?

On one server I manage, creating a new AppPool defaults to 10 (maximum) worker processes. Other people suggest that the normal setting is one.

What problem does multiple worker processes solve and what are the techniques for deciding on how many?

Worker processes are a way of segmenting the execution of your website across multiple exe's. You do this for a couple of reasons, one if one of the workers gets clobbered by run time issues it doesn't take the others down. For example, if a html request comes in that causes the process to run off into nothing then only the other requests that are being handled by that one worker processor get killed. Another example is that one request could cause blocking against the other threads handled by the same worker.

As far as how many you need, do some load testing. Hit the app hard and see what happens with only one. Then add some more to it and hit it again. At some point you'll reach a point of truly saturating the machines network, disk, cpu, and ram. That's when you know you have the right balance.

Incidentally, you can control the number of threads used per worker process via the machine.config file. I believe the key is maxWorkerThreads.

Now, beware, if you use session, Session state is not shared between worker processes. I generally recommend avoiding session anyway but it is something to consider.

For all intents and purposes you might consider each worker process as it's own separate web server. Except they are running on the same box.

Memory Leaks

The other biggest advantage is handling memory leaks. Sometimes how much ever you try to optimize your code, but there are memory leaks in the framework itself and other third party libraries. We noticed that eventually our application reaches very high memory and starts giving no memory exceptions.

So we had to set a max virtual memory limit on worker process to like 1GB and allow multiple processes to run. You could set max virtual limit even for single worker process, but this leads to a spikes of slow down, as when worker process is recycled, all requests are slow till the time worker process gains good speed. As our application has internal caching (Entity Framework Query Cache, some object pools), each of these things slows down starting of application. This is where single worker process hurts the most.

If there are multiple worker processes, only one of the process in recycle mode is slow, but others do keep good speed.

Another case when it makes sense to have many worker processes is if your application contains locks that prevent its parallelization. GDI+ based image processing is one of examples.

I found it when I tried to find solution for my problem.