The request structure of ASP.NET tries to achieve a balance between the number of threads and available resources. A application that uses sufficient CPU power is known that will determine the number of requests to be performed simultaneously based on the CPU power available for the request. This technology is called threaded gates. But under certain conditions, the thread door control algorithm is not very effective. Gearing gates can be monitored in PerfMon by using the Pipeline Instance Count performance counter associated with the ASP.NET Applications Performance Object.
When the page calls an external resource, such as database access or XML Web Services request, the page request usually stops and releases the CPU. If a request is waiting to be processed, there is a thread in the thread pool to be free, then this is waiting for the request will begin to be processed. Unfortunately, sometimes this may cause a large number of requests on the web server and a number of waiting threads that are waiting for, and they have an adverse effect on server performance. Typically, if the gate control is the response time of external resources, it is allowed to wait for resources to wait for resources, and there is no help to the throughput of the web server.
To mitigate this situation, you can manually set the number of threads in the process by changing the MAXWORKERTHREADS and Maxioth attributes of the Machine.config> node.
Note that the auxiliary thread is used to process the ASP.NET request, and the IO thread is used to serve data from files, databases, or XML Web Services. The value assigned to these attributes is the maximum number of each CPU thread in the process. For dual-processor computers, the maximum number is twice the setting value. For the quadratic computer, the maximum value is four times the setting value. In any case, it is best to change the default value for computers with four or eight CPUs. For computers with one or two processors, the default value can, but for more processor's performance, one hundred or two hundred threads in the process are more harmful.
Note that too many threads in the process tend to reduce the speed of the server, because additional context exchange results in the operating system to spend the CPU cycle in the maintenance thread rather than the processing request.
