By default the SOAP, HTTP, and HTTP-based WCF adapters (and .NET in general) open only two concurrent HTTP connections from each BizTalk server to any specific destination server.
For example, if you have a SOAP send port sending messages to http://www.contoso.com/SomeWebService.asmx, then by default each BizTalk server will open only two concurrent HTTP connections to www.contoso.com, no matter how many messages need to be sent.
This setting conforms to the IETF RFC for the HTTP 1.1 specification, and although it is suitable for user scenarios it is not optimized for high throughput.
Increasing the Number of Concurrent Connections
To increase the number of concurrent connections, you can modify the entry in the BizTalk Server configuration file, BTSNTSvc.exe.config (or BTSNTSvc64.exe.config for 64-bit hosts), on each BizTalk server. You can increase this for the specific servers being called.
The following is an example of the configuration for the maximum connections property:
<configuration> <system.net> <connectionManagement> <add address=" http://www.contoso.com" maxconnection="20" /> <add address = "http://www.northwind.com" maxconnection = "2" /> <add address="*" maxconnection="10" /> </connectionManagement> </system.net> </configuration>
In this sample, we are saying that:
- The endpoint Contoso is configured with 20 concurrent connections
- The endpoint Northwing is configured with 2 concurrent connections
- And the remaining are configured with 10 concurrent connections (change the default value)
Do not increase the value for the maxconnection parameter to such a large value that the Web server being called is overwhelmed with HTTP connections. Perform stress testing by sending requests to each destination Web server to determine a value for maxconnection that will provide good without overwhelming the target Web servers.
The default value for the “maxconnnection” property is 2, the maximum value that can be set for the “maxconnection” property for all URIs is 20.
The “maxconnnection” property has no effect on the connection limit for making calls to local web services. Therefore, local web services always tend to give preference to the requests that come from the local computer over requests that come from other machines. This degrades the throughput of the web service for remote clients.
If the local web services are not making calls to any external systems and their web method processing time is considerably low, package them into a .NET library and call them from within your orchestrations. If those web services are calling external systems or take a considerable amount of processing time, move them off the BizTalk Server Group servers.
(This post is mainly for personal tracking, sorry for the duplicate content)