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

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?

Solution 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.

Solution 2

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.

Solution 3

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.

Comments

[Tim Long]

In fact, it was a problem with session state that sparked this question (see stackoverflow.com/questions/2147578/…). Thanks for a helpful answer (+1)

[NotMe]

The default setting is normally one. Your server that defaults to 10 must have been modified to change it's defaults.

[Akash Kava]

@ChrisLively, Session State is shared between worker processes, infact Session State is also shared between multiple websites having same cookie name as well.

[NotMe]

@AkashKava: InProc session state, which is the default, is not shared between worker processes. The only way to share it is if you are using out-of-process session state. Which means that you must have a session state server configured.

[AaronLS]

"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" I don't think this is really accurate way to describe it. It seems to imply that a single long running request can block other requests, but within a worker process there are worker threads which ensure that multiple requests can be handled at one time. Probably not what you intended to convey but could be misleading for those who are trying to understand this setting.

[NotMe]

@aaronLS: I believe what I was trying to say is if one thread within a worker process dies a horrible death (exa: uncaught exception) then that one thread will kill the entire worker process - including the other threads currently running. However it will not impact other worker processes (and their threads) that are executing.