How to Modify the Default Host Throttling Settings
You can adjust the default throttling settings by modifying the configuration options that are exposed on the Advanced page of the Host Properties dialog box. The default configuration options are suitable for most BizTalk Server processing scenarios. This section describes the available configuration options and when you may want to change the default values.
Display the host throttling configuration options
To access the host throttling configuration properties for a host instance, follow these steps:
-
Open the BizTalk Server Administration Console. To do this, click Start, point to All Programs, point to Microsoft BizTalk Server 2009, and then click BizTalk Server Administration.
-
In the BizTalk Server Administration console, click to expand BizTalk Server 2009 Administration, click to expand BizTalk Group [<servername>:<management database>], click to expand Platform Settings, and then click Hosts. The list of configured hosts is displayed in the right pane of the BizTalk Server Administration console.
-
Right-click the host for which you want to modify the default host throttling settings and click the Properties menu option to display the Host Properties dialog box.
-
Click the Advanced option in the left pane of the Host Properties dialog box to display the Advanced page of the Host Properties dialog box.
Host Properties - Advanced page
| Setting | Description | ||
|---|---|---|---|
|
Maximum number of messaging engine threads per CPU |
This option specifies the maximum number of threads that can be used by the End Point Manager (EPM). The EPM starts with the number of threads equivalent to 10% of this value and adds threads up to the specified value as load increases. The number of threads allocated is reduced as load is reduced or as necessary for throttling. This setting largely affects only inbound (published) messages as the EPM is responsible for receiving messages from adapters and publishing the messages to the MessageBox database. If the EPM thread pool is set to a small number, then the likelihood of a throttling condition is reduced but doing this may also cause resources to be under utilized. It is recommended that you set a thread pool that is large enough to fully utilize available resources during normal load and let the throttling mechanism dynamically reduce available threads if a throttling condition occurs. This value does not include the threads created by the adapters configured to run in the host.
The default value is 20. |
Throttling Thresholds dialog box
This dialog box is displayed by clicking the Settings button in the Throttling Thresholds section of the Advanced page of the Host Properties dialog box. This dialog box items described in this table expose the thresholds above which a throttling condition may be triggered.
| Threshold | Description | ||||||
|---|---|---|---|---|---|---|---|
|
Internal message queue size |
This is the size of the in-memory queue that the host instance maintains as a temporary placeholder for delivering messages. The host retrieves messages from the MessageBox database and places them in this interim queue before they are delivered to the respective components for processing. Setting a large value for this parameter may improve low-latency scenarios to some extent since more messages will be proactively retrieved from the MessageBox database for processing. Since the messages in this queue consume memory, setting this parameter to a smaller value may be desirable for scenarios involving large messages in order to avoid memory based throttling of the process. For example, if the memory consumption of a host instance for an outbound transport remains high despite a low value for In-process message count, the memory consumption could be attributed to the size of the messages residing in the in-memory queue. In this scenario, the queue size should be greatly reduced to avoid memory-based throttling.
This setting affects only outbound (delivered) messages. The default value is 100. |
||||||
|
Database connections per CPU |
Maximum number of concurrent database sessions (per CPU) allowed before throttling begins. The idle database sessions in the common per-host session pool do not add to this count, and this check is made strictly on the number of sessions actually being used by the host instance. This option is disabled by default; typically this setting should only be enabled if the database server is a bottleneck in the BizTalk Server system. You can monitor the number of active Database connections by using the Database session performance counter under the BizTalk:Message Agent performance object category. This setting affects only inbound (published) messages. Enter a value of 0 to disable throttling that is based on the number of database sessions. The default value is 0. |
||||||
|
Threads per CPU |
Total number of threads in the host process including threads used by adapters. If this threshold is exceeded, BizTalk Server will try to reduce the size of EPM thread pool and message agent thread pool. Thread based throttling should be enabled in scenarios where high load can lead to the creation of a large number of threads. This setting affects both inbound and outbound throttling. Enter a value of 0 to disable thread based throttling. The default value is 0. |
||||||
|
In-process messages per CPU |
Maximum number of messages delivered to the End Point Manager (EPM) or XLANG that have not been processed. This does not include the messages retrieved from database but still waiting for delivery in the in-memory queue. You can monitor the number of In-Process Messages by using the In-process message count performance counter under the BizTalk:Message Agent performance object category. This parameter provides a hint to the throttling mechanism for consideration of throttling conditions. The actual threshold is subject to self-tuning. You can verify the actual threshold by monitoring the In-process message count performance counter. This parameter can be set to a smaller value for large message scenarios, where either the average message size is high, or the processing of messages may require a large amount of messages. Such a case would be evident if a scenario experiences memory-based throttling too often and if the memory threshold gets auto-adjusted to a substantially low value. Such behavior would indicate that the outbound transport should process fewer messages concurrently to avoid excessive memory usage. Also, for scenarios where the adapter is more efficient when processing a few messages at a time (for example, when sending to a server that limits concurrent connections), this parameter may be tuned to a lower value than the default. This setting only affects outbound message throttling. Enter a value of 0 to disable throttling based on the number of in-process messages per CPU. The default value is 1,000. |
||||||
|
Message count in database |
Total number of messages published by this host instance to the work, state, and suspended queues of the subscribing hosts. This is calculated as a weighted average as follows:
Publishing batches may be exempt from throttling if the batch also contains message deletion commands and the number of messages to be deleted exceeds the number of messages to be published. Example of such batches may include solicit-response messaging scenarios or for orchestration persistence points following a message receive. The Message count in database setting also indirectly defines the threshold for a throttling condition based on the number of messages in the spool table or tracking table. If the number of messages in the spool table or tracking table exceeds 10 times this value then a throttling condition will be triggered. By default the Message count in database value is set to 50,000, which will cause a throttling condition if the spool table or the tracking table exceeds 500,000 messages. The name of the tracking table in the MessageBox database is TrackingData. The name of the spool table in the MessageBox database is Spool. This parameter only affects inbound message throttling. Enter a value of 0 to disable throttling based on the message count in database parameter. The default value is 50,000. |
||||||
|
Physical memory usage |
Specified as one of:
Since this measures total system memory, a throttling condition may be triggered if non-BizTalk Server processes are consuming an extensive amount of system memory. Enter a value of 0 to disable throttling based on physical memory usage. The default value is 0. |
||||||
|
Process memory usage |
Specified as one of:
When process memory exceeds this threshold, a throttling condition is triggered. Inbound (published) batches are usually exempt from throttling because memory is released when messages are published if the batch contains a dehydration or message completion command and these actions reduce memory consumption. Since the managed runtime performs a intermittent release of memory through offline .NET garbage collection (GC), a .NET GC may be triggered by the throttling mechanism if the memory used approaches or is above the specified threshold value. Since a .NET GC is an expensive operation, the frequency of the GC trigger is moderated. If the memory released by a GC is minimal, the GC trigger may occur only every 120 seconds. Conversely, if a GC is calculated to release more than 25% of used memory, then another GC may be triggered within 15 seconds in high memory usage scenarios. When the in-process message count drops to zero and memory pressure is still high, a GC is forced. The minimum intervals between subsequent GCs are hard-coded and cannot be changed externally.
Enter a value of 0 to disable throttling based on process memory usage. This parameter provides a hint to the throttling mechanism for consideration of throttling conditions. The actual threshold is subject to self-tuning. The self tuning algorithm uses the initial specified value as a starting point and if the system begins throttling, the value is increased or decreased within certain limits of the initial value to try to find an optimal value. For example, if the system is throttling on process memory usage and the throttling condition does not change within a certain time-limit, the threshold is temporarily incremented in an attempt to mitigate the throttling condition. You can verify the actual threshold by monitoring the Process memory usage (MB) performance counter. The default value is 25. |
Message Publishing Throttling Settings dialog box
This dialog box is displayed by clicking the Settings button in the Message Publishing Throttling section of the Advanced page of the Host Properties dialog box.
These settings affect rate based throttling for inbound (published) messages, as described in the following table.
| Threshold | Description |
|---|---|
|
Minimum number of samples |
Minimum number of messages BizTalk Server will sample for the Sampling window duration before considering rate-based throttling. If the actual number of samples in a sampling window fall below this value then the samples are discarded and throttling is not applied. This value should be consistent with a rate at which messages can be published under a medium load. For example, if your system is expected to handle 1,000 documents per second under a medium load, then this parameter should be set to 1,000 * Sample window duration in seconds (or more precisely, 1 * Sample window duration (milliseconds)). If the value is set too low, then the system may experience a throttling condition under low load. If the value is set too high, then there may not be enough samples for this technique to be effective. Enter a value of zero to disable rate based inbound throttling. The default value is 100. |
|
Sampling window duration (milliseconds) |
The time-window measured in milliseconds, which is used to calculate the publishing rate based on the samples collected. The duration should be increased if the latency required for publishing a single message is high. Enter a value of zero to disable rate based inbound throttling. The default value is 15,000. |
|
Rate overdrive factor (percent) |
This controls how much higher you allow the request rate to be than the completion rate before a throttling condition occurs. For example, if messages are being published at a rate of 200 per second and this parameter is set to 125, then the system will allow the publication of up to 250 messages per second (125% * 200 = 250) before applying throttling. Specifying too small a value for this parameter will cause the system to throttle more aggressively and could lead to over-throttling. Specifying too large a value for this parameter will cause under throttling and prevent the throttling mechanism from recognizing a legitimate throttling condition. The default value is 125. |
|
Maximum throttling delay (milliseconds) |
This is the maximum delay BizTalk Server will impose on a message instance due to throttling. The actual delay depends on the severity of the throttling condition. Enter a value of zero to disable inbound throttling. The default value is 300,000. |
Message Processing Throttling Settings dialog box
This dialog box is displayed by clicking the Settings button in the Message Processing Throttling section of the Advanced page of the Host Properties dialog box.
These settings affect rate based throttling for outbound (delivered) messages, as described in the following table.
| Setting | Description |
|---|---|
|
Minimum number of samples |
Minimum number of messages BizTalk will sample for the Sampling window duration before considering rate-based throttling. If the actual number of samples in a sampling window falls below this value then the samples are discarded and throttling is not applied. This value should be consistent with a rate at which messages can be delivered under a medium load. For example, if your system is expected to handle 1,000 documents per second under a medium load, then this parameter should be set to 1,000 * Sample window duration in seconds (or more precisely, 1 * Sample window duration (milliseconds) for this scenario). If the value is set too low, then the system may experience a throttling condition under low load. If the value is set too high, then there may not be enough samples for this technique to be effective. Enter a value of zero to disable rate based outbound throttling. The default value is 100. |
|
Sampling window duration (milliseconds) |
The time-window measured in milliseconds, which is used to calculate the processing rate based on the samples collected. The duration should be increased if the latency required for processing a single message is high. Enter a value of zero to disable rate based outbound throttling. The default value is 15,000. |
|
Rate overdrive factor (percent) |
This controls how much higher you allow the delivery rate to the Orchestration or Messaging engine to be than the completion rate before a throttling condition occurs. For example, if messages are being processed at a rate of 200 per second and this parameter is set to 125, then the system will allow the processing of up to 250 messages per second (125% * 200 = 250) before applying throttling. Specifying too small a value for this parameter will cause the system to throttle more aggressively and could lead to over throttling. Specifying too large a value for this parameter will cause under throttling and prevent the throttling mechanism from recognizing a legitimate throttling condition. The default value is 125. |
|
Maximum throttling delay (milliseconds) |
This is the maximum delay BizTalk Server will impose on a message instance due to throttling. The actual delay depends on the severity of the throttling condition. Enter a value of zero to disable outbound throttling. The default value is 300,000. |
Registry settings that affect default throttling behavior
You can modify the default throttling behavior by creating values under the following key in the BizTalk Server registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc$<HostName>
BizTalk Server checks the values stored in this location of the registry every cache refresh interval, which is set to 60 seconds by default. For information about changing the cache refresh interval see How to Modify Group Properties.
Create the following registry values to modify the default throttling behavior, as described in the following table:
| Name | Type | Description | Comments | ||
|---|---|---|---|---|---|
|
ThrottlingPublishOverride |
DWORD |
Valid Values are: 0: Do not override 1: Initiate throttling condition 2: Do not throttle |
The default value is 0 (Do not override) |
||
|
ThrottlingDeliveryOverride |
DWORD |
Valid Values are: 0: Do not override 1: Initiate throttling condition 2: Do not throttle |
The default value is 0 (Do not override) |
||
|
ThrottlingPublishOverrideSeverity |
DWORD |
Valid values are from 1 through 1,000. |
A higher value increases the severity of an inbound throttling condition initiated when ThrottlingPublishOverride is set to 1. The default value is 100. |
||
|
ThrottlingDeliveryOverrideSeverity |
DWORD |
Valid values are from 1 through 1,000. |
A higher value increases the severity of an outbound throttling condition initiated when ThrottlingDeliveryOverride is set to 1. The default value is 100. |
||
|
AgentThreadPoolSize |
DWORD |
Valid values are from 1 through 50. |
The maximum number of threads (per CPU) that the message agent can allocate to deliver de-queued messages to the XLANG/messaging engine. The message agent has a dynamic thread-pool that shrinks or grows depending on the load. The thread pool always maintains at least 1/10th of the maximum value. For example, if the maximum thread pool size is 20, there will be at least 2 threads allocated even when there is no load. The default value is 20. |
||
|
AgentThreadsPerCpu |
DWORD |
Valid values are from 1 through 20. |
The maximum number of threads per CPU that can compete with each other for CPU time. Since BizTalk is I/O intensive, many threads may be waiting. Nevertheless, this value should be kept low to avoid excessive context switching. The default value is 2. |
||
|
AgentThreadPoolQueueLen |
DWORD |
Valid values are from 20 through 1,000. |
The place holder for work items waiting to be scheduled for a thread. Items waiting in the thread-pool queue consume memory and so this value should be kept low for large message scenarios. The default value is 50. |
||
|
ThrottlingSpoolMultiplier |
DWORD |
Valid values are from 0 through 1,000. |
Specified the factor by which the Message count in database threshold will be multiplied and then compared against the current record count in the spool table to determine whether the system should throttle on spool table size. If this is set to 0, spool table size is not used as a consideration for determining a throttling condition. The default value is 10. |
||
|
ThrottlingTrackingDataMultiplier |
DWORD |
Valid values are from 0 through 1,000. |
Specified the factor by which the Message count in database threshold will be multiplied and then compared against the current record count in the tracking table to determine whether the system should throttle on tracking table size. If this is set to 0, tracking table size is not used as a consideration for determining a throttling condition. The default value is 10. |
||
|
ThrottlingSeverityProcessMemory |
DWORD |
Valid values are from 1 through 1,000. |
Controls the severity of a process memory triggered throttling condition. This is specified in percentage value and this parameter sets the severity of a throttling condition caused when the Process memory usage threshold is exceeded. The default value is 500. |
||
|
ThrottlingSeverityDatabaseSize |
DWORD |
Valid values are from 1 through 1,000. |
Controls the severity of a database sized triggered throttling condition. This is specified in percentage value and this parameter sets the severity of a throttling condition caused when the Message count in database threshold is exceeded. The default value is 1. |
||
|
ThrottlingSeverityInflightMessage |
DWORD |
Valid values are from 1 through 1,000. |
Controls the reaction time of throttling when the In-process size exceeds the threshold. This is specified in percentage value and this parameter sets the severity of a throttling condition caused when the In-process messages per CPU threshold is exceeded. The default value is 75. |
||
|
ThrottlingBatchMemoryThresholdPercent |
DWORD |
Valid values are from 0 through 100. |
Controls the memory threshold beyond which to throttle the publishing of a batch of messages. The batch memory threshold is computed by multiplying this percentage factor by the Process memory usage threshold. If the memory estimated to execute a publishing batch exceeds the batch memory threshold, the batch will be subject to process memory based throttling. Otherwise the batch will be exempt from process memory based throttling even when the total process memory exceeds the Process memory usage threshold. A value of zero indicates that all publishing batches may be subject to process memory based throttling even if the memory estimated to execute the batch is minimal. The default value is 1. |
||
|
ThrottlingLimitToTriggerGC |
DWORD |
Valid values are from 50 through 100. |
Controls when a .NET garbage collection (GC) will be triggered as process memory consumption increases and approaches the threshold. When the memory consumption exceeds this percentage value of the memory threshold, a GC is triggered. The default value is 80. |
||
|
MsgAgentPerfCounterServiceClassID (String Value) |
String |
Valid values are: {226FC6B9-0416-47A4-A8E8-4721F1DB1A1B} (XLANG) - or - {59F295B0-3123-416E-966B-A2C6D65FF8E6} (Messaging) - or - {683AEDF1-027D-4006-AE9A-443D1A5746FC} (Messaging Isolated) |
The default behavior is for the Message Agent to display the performance counters for the most active service class for a given host if multiple service classes are running within the same host instance. To override the default behavior, specify one of the indicated GUIDS to only display performance counters for that service class.
|
It is possible to dynamically control the BizTalk host throttling mechanism by following these steps:
-
Create a custom resource monitoring component to measure system load.
-
Programmatically change these registry values based on the data returned from the monitoring component.
Note