.Net 2.0 and Config MaxConnection Values

”

Nearly all microsoft.com Web sites have ASP.NET applications that make calls to remote Web service clusters. The maximum number of concurrent remote Web service calls that can be made from a single Web server is determined by the maxConnection attribute of the <connectionManagement> element in the machine.config file. In ASP.NET 1.1, by default the maxConnection value was set to 2. This old default maxConnection value was much too low for sites like microsoft.com that have hundreds of different applications that make remote Web service calls. The result was that ASP.NET requests would queue while waiting for the remote Web service calls to complete. (You can view the number of queued ASP.NET requests via the perfmon counter ASP.NET\Requests Queued.) To enable more calls to execute concurrently to a remote Web service (and thereby improve the performance of applications on the site), we increased the maxConnection value to 40 for our quad processor Web servers. (The general recommended value for maxConnection is 12 times the number of CPUs, but tune this to suit your specific situation.)

In ASP.NET 2.0, however, you no longer need to configure maxConnection manually as it is now automatically scaled and set. This is a result of the new configuration section for the processModel tag in machine.config (for more information about the processModel element, see “processModel Element (ASP.NET Settings Schema))”.

Copy Code

<system.web>
    <processModel autoConfig="true" />
</system.web>

With autoConfig enabled in machine.config (this is the default setting), ASP.NET sets the value of the maxConnection parameter to 12n (where n is the number of CPUs). Enabling autoConfig also causes the following: the maxWorkerThreads parameter and the maxIoThreads parameter are set to 100, the minFreeThreads parameter is set to 88n, the minLocalRequestFreeThreads parameter is set to 76n, and the minWorkerThreads is set to 50.

Prior to making use of autoConfig in ASP.NET 2.0 to automatically scale and set values for maxConnection and the other attributes in the list, be sure to remove any manually set values for these parameters as these values would be used instead of the autoConfig values. This is something to keep in mind when migrating from ASP.NET 1.1 (where maxConnection needed to be explicitly set) to ASP.NET 2.0, where there are defaults.

Again, the autoConfig values for maxConnection and the other attributes listed previously are somewhat arbitrary and may not work for absolutely every instance, but I have found that these limits work well for nearly all microsoft.com applications.

If you decide that you need to tune the maxConnection value manually, be cautious when increasing its value as this can lead to an increase in CPU utilization. This increase is caused by the fact that more incoming requests can be processed by ASP.NET instead of having them wait for their turn to call the Web service. Of course, you should remember that the maxConnection attribute does not affect local Web service calls, only remote calls.

” from : http://technet.microsoft.com/en-us/magazine/cc160896.aspx

Interesting I came across this code fragment, wonder if it works….

System.Net.ServicePointManager.DefaultConnectionLimit=<your value here>