Friday, March 18, 2005

Optimizing BizTalk for latency

BizTalk is optimized for throughput, not latency, by default. If you have low volume and want to speed up processing of individual messages, the following settings have helped one of my clients improve how long it took to run a message through BizTalk from several seconds to under a second:

· To decrease HTTP request-response latency, define a DWORD registry key named HttpBatchSize and set the value to 1. Create this registry key in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc.3.0\HttpReceive folder.

This setting specifies the batch size that the HTTP receive adapter uses to submit requests to BizTalk Server. Ordinarily, the HTTP receive adapter waits to accumulate multiple messages to submit at once. It submits messages to BizTalk Server when the maximum batch size is reached, or at the preset waiting time periods. Setting the HttpBatchSize value to 1 causes the HTTP receive adapter to submit messages as soon as they are received.

· 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:


· 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

The tool mentioned in the 2nd bullet item only lets you decrease the MaxReceiveInterval to 100. To decrease it to 50, you will need to run the following SQL command:

use BizTalkMgmtDB
update adm_serviceclass set maxreceiveInterval = 50 where id IN (1,2,3,4)
Reading the information above, you might wonder why this wasn't set this way from the beginning. I found a web page where Scott Woodgate says...

Tuning for Low Latency

It is possible to get sub-second transactions. BizTalk is built for throughput and not latency. At 50-60% CPU utilization, latency goes through the roof. If you can aim for 30-50% CPU utilization you can still attain low-latency.

The MaxReceiveInterval setting controls the latency of each message and HttpBatchSize can be set to 1 to guarantee each message gets processed as it comes in. Lastly, PollingInterval can set to 50-100ms to force frequent polling of the message box to achieve low latency.

so it seems the default settings are configured to process batches of messages, not blazing fast responses to single messages

1 comment:

energed said...

Nice info. Thanks for sharing it.