Question

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?

Answer 1

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.