Performance Tuning the Connected Services Framework Components

Connected Services Framework

A number of configuration settings affect the performance of the Connected Services Framework components, including ASP.NET settings, Registry settings, Microsoft Active Directory® load balancing, Active Directory indexing, Microsoft BizTalk® settings for Profile Manager, threading configuration, and more. These setting and the recommended strategies for setting them are outlined below.

ASP.NET Settings

The following ASP.NET settings are recommended in the Machine.config or Web.config file for all the Connected Services Framework components:

  • maxconnection                         50 * Number of CPUs

  • maxiothreads                           250
  • maxworkerthreads                     250
  • minfreethreads                         125 * Number of CPUs
  • minlocalrequestfreethreads        125 * Number of CPUs

These settings are designed to support allowing a large number of requests to be processed by Microsoft Internet Information Services (IIS) and ASP.NET without any interference from the Connected Services Framework components. Internally, the Connected Services Framework components use their own thread pool for all application level processing, so the threads in the IIS threadpool can be used for the delivery of messages to the Web services and the management of the sending of messages to other services.  

For a detailed discussion on these parameters, please see:

The default ASP.NET settings tend to limit the number of incoming requests to ASP.NET in order to throttle requests and allow local, processing requests to complete. In the case of the Session component, there is little processing on the machine itself because it is a router for messages destined for services on other machines. Session has to be able to accept and process those requests with no blockage or timeouts waiting for threads to clear.

These configuration settings can be adjusted for your installation by observing the ASP.NET applications performance counters. The request/sec and the requests in application queue counters are especially helpful for observing performance. The ASP.NET counters request execution time, request queued, request wait time, and requests rejected are also useful in determining the health of the system.

For further information about these performance counters, please see:


Registry Settings

The following registry setting should be updated to deal with connection timeouts:


Set this setting to 65534 to allow for the maximum number of connections. The issues behind this change are thoroughly discussed in the following article:


Active Directory Load Balancing 

If you have specified a preferred a domain controller to be used while configuring Identity Manager, then you may want to redirect the non Identity Manager load on that domain controller to any other domain controllers in the domain. This way you can load balance the domain controllers in your domain.

Please explore the following link to achieve this task:


Active Directory Indexing

For higher performance, the following attributes need to be indexed in Active Directory. These are the attributes that the Connected Services Framework Identity Manager component queries. Please note that one or more of these attributes may already be indexed as a result of the Active Directory installation:

  • User-Principal-Name

  • SAM-Account-Name

  • Upn-Suffixes

  • Object-Category

  • Common-Name

For further information on indexing Active Directory attributes, please see the following article:


BizTalk Settings for Profile Manager Component Performance

Verify the implementation of all of the previous ASP.NET settings, and consider changing the configuration of the TCP/IP MaxUserPort settings as well.

Outbound Message Throttling

In order to reduce problems resulting from bursts of messages, which cause unpredictable spikes in message traffic and the associated resource starvation, BizTalk can be configured to throttle the outbound requests from the send ports. Modify the following columns in the adm_ServiceClass table of the BizTalkMgmtDb database for the Messaging InProcess Service class:

  • HighWatermark

  • LowWatermark

During testing, setting HighWatermark to 2 and LowWatermark to 1 enabled the ProfileManager PropagateAttribute to accept hundreds of payload messages simultaneously without causing the send ports to time out. For a typical scenario, you can start with HighWatermark = 50 and LowWatermark = 25, and then make the appropriate adjustment based on your scenario.

To determine the optimal settings, please consult the BizTalk documentation. The following is an excerpt from Microsoft BizTalk Server 2004 Performance Characteristics white paper ( on these two settings:

“HighWatermark, LowWatermark. These two settings determine the outbound processing rate for messages. They represent high and medium stress-level thresholds, respectively. Both settings define the number of messages processed by BizTalk Server 2004, but not yet consumed by subscribers. When BizTalk Server processes more messages (not yet consumed) than specified by the HighWatermark threshold, it stops processing messages from the message box until the number of active messages decreases below the LowWatermark threshold.

Note: These settings are per CPU processor. On a dual-processor server, with the LowWatermark threshold set to 100, BizTalk Server 2004 will be at medium stress level until the number of active messages decreases below 200.”

End-to-End Latency

Based on the BTS Performance Characteristics white paper.

“To decrease end-to-end latency, reduce the MaxReceiveInterval value in the adm_ServiceClass table of the BizTalkMgmtDb database from the default value of 500 to a value less than 100 (or any positive integer) for the following service classes:

  • XLANG/s

  •  Messaging In-Process

  • Messaging Isolated

These settings specify the maximum polling interval (in milliseconds) at which the messaging agent polls the message box. Microsoft does not support the direct modification of these values; you must use the tool at

By reducing the default values from 500 to 100, the latency of Service Logic sometimes can be reduced by around 50%.

You can further reduce the end-to-end latency for a single message by setting the BatchSize to be 1 for the aforementioned service classes. Before doing this, you need to be aware that setting the BatchSize to such a small number will have adverse effect on throughput; please read the following paragraph for more discussion.

It’s important to note that BizTalk is designed and optimized for maximum throughput, not for minimum latency, so there is a limit that you can achieve to reduce latency. It’s also important to note that while those settings help reducing latency, they might hurt throughput. One has to analyze the performance requirements to achieve the right balance.

The following best practices may help to improve performance:

  • Turn off any unnecessary tracking, especially message body tracking.
  • Use separate hosts (logical groups) for receiving messages (RxHost), processing messages (PxHost), and transmitting messages (TxHost). Configure a dedicated host (TrkHost) to move tracking data from the Message Box to the DTADb, and ensure that the Host Tracking check box is selected for this host and disabled for other hosts. You can have multiple host instances running on the same server box if the CPU utilization is low. If the CPU utilization becomes high, consider having separate server boxes running different hosts. Scaling out can be further achieved by adding multiple BizTalk servers (host instances) for a single host within a single BizTalk group.


Using BizTalk Server 2004 Service Pack 1 Improvements for Consuming Web Services Under Load

With SP1 you can control how BizTalk uses the .NET thread pool when consuming Web services. You need to create the following Registry keys:

HKLM\SYSTEM\CurrentControlSet\Services\BTSSvc[appguid]\CLR Hosting
MaxWorkerThreads: DWORD
MaxIOThreads: DWORD
MinWorkerThreads: DWORD
MinCompletionPortThreads: DWORD
MinIOThreads: DWORD

By setting the appropriate values for these values, you can optimize how BizTalk uses the .NET thread pool when consuming Web services.

The following are sample settings for a four CPU box:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{8C6C0034-E23C-4507-9261-E91EF41125C9}\CLR Hosting\MaxWorkerThreads (REG_DWORD) = 300
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{8C6C0034-E23C-4507-9261-E91EF41125C9}\CLR Hosting\MaxIOThreads (REG_DWORD) = 300
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{8C6C0034-E23C-4507-9261-E91EF41125C9}\CLR Hosting\MinWorkerThreads (REG_DWORD) = 220
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{8C6C0034-E23C-4507-9261-E91EF41125C9}\CLR Hosting\MinIOThreads (REG_DWORD) = 220  

If these parameters are not setup appropriately, you will see that the Web services don’t process the messages in a timely manner under heavy loads. See the following articles for more discussions:


Threading Configuration

The number of threads used by each process to handle incoming requests is configurable at run time if desired. By default each process gets 10 threads. These threads will be used for all request operations; the threads passed into the application by IIS are not used for processing and return immediately. This figure may be adjusted at run time with the appSettings configuration value in the Web.config:

    <add key="DefaultMaxWorkerThreads" value="10" />

Note that all the threads will be created at initialization time and this is a hard limit of the number of worker threads used by the process. Do not make this number too large as it will result in extra overhead.

The Connected Services Framework Identity Manager component is most likely to require extra threads as it is called a lot and has longer running transactions to Active Directory as well as the Biztalk Single Sign-On (SSO) database.