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:

· 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 http://go.microsoft.com/fwlink/?linkid=30076

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
go
update adm_serviceclass set maxreceiveInterval = 50 where id IN (1,2,3,4)
go

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

Code Camp 3 Presentation

I just gave a presentation at Code Camp 3 and the material should be posted eventually at the MSDN code camp downloads page. When that happens, I'll post a notice here.

Topic of my session...
Using the Microsoft Patterns & Practices Enterprise Library
The just released Enterprise Library from the Patterns & Practices group at Microsoft provides assistance in many facets of enterprise class applications - security, logging, caching, error handling, cryptography and data access. This session covers the benefits of using these application blocks, how to incorporate them in your development practices and what can be learned from them even if they are not applicable to your project.

If you attended and have any questions on the topic, fee free to email me personally and I'll try to answer all questions here. In the meantime, I'm going to be posting some quickstart tutorials on this site soon.

Be careful about server names (avoid underscores)

Helping out an old friend and former co-worker, we ran into an issue where he was unable to save anything in session state between requests in ASP.NET.

Well, we eventually figured out the issue - his server had an underscore in the name....

http://support.microsoft.com/default.aspx?scid=kb;EN-US;316112

PRB: Session Variables Do Not Persist Between Requests After You Install Internet Explorer Security Patch MS01-055

SYMPTOMS

After you install security patch MS01-055 for Microsoft Internet Explorer 5.5 or 6.0, you may encounter the following problems:

•	Session variables are lost.
•	Session state is not maintained between requests.
•	Cookies are not set on the client system.

Note These problems can also occur after you install a more recent patch that includes the fix that is provided in security patch MS01-055.

CAUSE

Security patch MS01-055 prevents servers with improper name syntax from setting cookies names. Domains that use cookies must use only alphanumeric characters ("-" or ".") in the domain name and the server name. Internet Explorer blocks cookies from a server if the server name contains other characters, such as an underscore character ("_").

Because ASP session state and session variables rely on cookies to function, ASP cannot maintain session state between requests if cookies cannot be set on the client.

This issue can also be caused by an incorrect name syntax in a host header.

I guess you do learn something new everyday.

This took a long time to figure out. It wasn't until he noticed that using numeric IP's worked that he found this article.

He installed the 1.0 .NET framework on the Windows 2003 Server, so I assumed it was related to that. But the issue occurred under both the 1.0 and 1.1 runtime.

For now, he is going to use cookieless=true session state to get around this issue until the servername can be changed.