BizTalk SOAP, HTTP, and HTTP-based WCF Adapters – How many Concurrent Connections are configured by default and how can we change this behavior

Posted: July 11, 2011  |  Categories: Administration Advance Configurations BizTalk

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, then by default each BizTalk server will open only two concurrent HTTP connections to, 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:

         <add address="" maxconnection="20" />
         <add address = "" maxconnection = "2" />
         <add address="*" maxconnection="10" />

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.

Other considerations:

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.

Related links

(This post is mainly for personal tracking, sorry for the duplicate content)

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

2 thoughts on “BizTalk SOAP, HTTP, and HTTP-based WCF Adapters – How many Concurrent Connections are configured by default and how can we change this behavior”

  1. Sandro,
    You might want to make it clear that Max number of outbound connections limit has nothing to do with BizTalk server, not WCF Adapters. It is a default limitation implemented of the .NET stack itself that affects any application that runs on top of .NET. That’s why configuration setting is in section, and it is a property of the ConnectionManagementElement class in the System.Net.Configuration namespace,

    Andrew Slivker

Leave a Reply

Your email address will not be published. Required fields are marked *


Back to Top