69

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?

Tim Long
  • 13,508
  • 19
  • 79
  • 147
  • 1
    I wasn;t sure if this would be more appropriate here or on ServerFault, let me know if I made the wrong choice and I'll move it. – Tim Long Jan 27 '10 at 23:48
  • 4
    Go ahead and ask in both places. I think your question is relevant here. The specifics of ASP.Net deployment often fall into the developer's area of expertise, especially as it pertains to app optimization. – DOK Jan 27 '10 at 23:56
  • 7
    I agree with DOK. Both places are appropriate. Dev's are often the ones that have to tell the network guys how to configure the server. Because of this, they need to have this info. – NotMe Jan 28 '10 at 00:20
  • 1
    I am one of those devs at the moment :) – CokoBWare Oct 21 '14 at 13:33

3 Answers3

66

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.

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • 2
    In fact, it was a problem with session state that sparked this question (see http://stackoverflow.com/questions/2147578/asp-net-session-state-and-multiple-worker-processes). Thanks for a helpful answer (+1) – Tim Long Jan 28 '10 at 17:19
  • 3
    The default setting is normally one. Your server that defaults to 10 must have been modified to change it's defaults. – NotMe Jan 28 '10 at 18:59
  • 1
    @ChrisLively, Session State is shared between worker processes, infact Session State is also shared between multiple websites having same cookie name as well. – Akash Kava Nov 20 '13 at 10:39
  • 12
    @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. – NotMe Nov 20 '13 at 14:42
  • "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. – AaronLS Aug 07 '17 at 16:09
  • 3
    @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. – NotMe Oct 20 '17 at 15:04
6

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.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
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.

Community
  • 1
  • 1
Marat Safin
  • 1,793
  • 20
  • 28