An interesting change which you might have missed in .NET 2.0 is about the autoConfig setting for the <processModel> element. The customer was running out of available connections while accessing a remote web service and was trying to apply what’s suggested in Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications but apparently the change had not effect: a memory dump shown still 12 available connections even if he set MaxConnection=96. Interesting to note that reverting the application to .NET 1.1 the problem disappeared.
The different behavior is determined by the autoConfig value, which affects only ASP.NET applications and not Console, WinForm etc… (while the <processModel> threading configuration in .NET 1.x affected all .NET apps running on the machine):
Specifies whether to automatically configure the following settings to achieve optimal performance based on the machine configuration:
The values are set according to the KB article at http://support.microsoft.com/?id=821268.
This attribute does not affect the .NET Framework client applications; only ASP.NET applications.
The autoConfig attribute can be one of the following values.
- True: Indicates that ASP.NET automatically configures the attributes in the preceding list to achieve optimal performance based on the machine configuration.
- False: Indicates that ASP.NET should use the explicitly defined values for the attributes in the preceding list.
The default in the Machine.config file is True, unless there is a previously existing configuration.
If you don’t like this auto threading feature you can simply set autoConfig=”false” or set System.Net.ServicePointManager.DefaultConnectionLimit=<your value here>
Quote of the day:
The male is a domestic animal which, if treated with firmness, can be trained to do most things. - Jilly Cooper