Q. How Many Worker Processes Do I Need?
Q. Do i need Web Garden for more reliablity?
A.
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.
Creating a Web garden for an application pool can also enhance performance in the following situations:
• Robust processing of requests: When a worker process in an application pool is tied up (for example, when a script engine stops responding), other worker processes can accept and process requests for the application pool.
• Reduced contention for resources: When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to a worker process in the Web garden. This helps smooth out workloads and reduce contention for resources that are bound to a worker process.
For even greater reliability, you can configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker process is called a Web garden. The worker processes in a Web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue to process requests.
Q. Do i need Web Garden for more reliablity?
A.
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.
Creating a Web garden for an application pool can also enhance performance in the following situations:
• Robust processing of requests: When a worker process in an application pool is tied up (for example, when a script engine stops responding), other worker processes can accept and process requests for the application pool.
• Reduced contention for resources: When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to a worker process in the Web garden. This helps smooth out workloads and reduce contention for resources that are bound to a worker process.
For even greater reliability, you can configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker process is called a Web garden. The worker processes in a Web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue to process requests.
No comments:
Post a Comment