BizTalk Server Performance Tips: #5 – Host Optimisation

Hi again! My last post on Host Separation was concerned about the practice of separating your hosts into their logical role within the application (send, receive etc) as well as by application. “What next?” I hear you ask… Here’s the opportunity to improve your application’s performance by the following tweaks that you can apply onto your hosts:- 1. Optimise Host Polling Intervals Now you can optimise the polling interval your hosts for messaging or for orchestration based scenarios. If, for example, you have the need for “important” orchestrations to be executed “faster” (i.e. less time spent in MsgBoxDB), then you can even decrease the polling interval further (the minimum being 50ms) The following table gives you an indication of values you can set to optimise the intervals.

Host Messaging Interval Orchestration Interval
“Important” Orchestration Host 250000 50
“Normal” Orchestration Host 250000 500
Send Host 50 250000
Tracking Host 500 250000

These setting are found on the Hosts | General tab in the BizTalk Administration console.   2. Disable Host Tracking Host tracking should be disabled as a general rule of thumb. The exception being if you need to track, and that should be in the dedicated tracking host. This is done by de-selecting the checkbox on the Hosts | General tab in the BizTalk Administration console.   3. Increase Host Instance Threading Values For non-tracking host instances, the default .Net CLR threading values should be increased to improve throughput. These values are found in the Host Instance | .NET CLR tab within the BizTalk Administration Console.

Threading Setting Suggested Value
Maximum Worker Threads 100
Minimum Worker Threads 25

4. Increase Host Process Virtual Memory Throttling Boundary By default, hosts are set to throttle to conserve system resources when their virtual memory allocation exceeds 25% of the available memory of the BizTalk application server. This system default is too low and may cause intermittent processing latency due to BizTalk being in a throttling state. For each of your hosts (except the Tracking host), increase the value to 75%. The process virtual memory setting is found on the Host | Resource-Based Throttling tab within the BizTalk Administration Console.   5. Increase Host Message Queue Size and In-Process Message Count For each of your hosts (except the Tracking host), increase the values as shown in the table below.

Setting Suggested Value
Internal Message Queue Size 10000
In Process Messages 10000

These settings can be found on the Hosts | Resource-Based Throttling tab in the BizTalk Administration console.   I hope these tips help bring out that little (or large) extra bit of performance out of your BizTalk application. Until next tip… be good!

BizTalk Server Performance Tips: #4 – Host Separation

This is more of a recommended practice from me rather than a performance tip, and I know that this topic has been touted by many BizTalkers.

I believe it is very important to separate your hosts by the purpose they serve; not only will this allow for security and performance but also from an operational point of view.

The key separation criteria are:-

  • functionality (receive, send, orchestration and tracking)
  • isolation (per application)

Furthermore, by having separate hosts, you have the opportunity to tune the host specifically for the task at hand; for example, you can optimise the polling interval for the host for messaging scenarios. A bonus to performance without dragging other scenarios (e.g. orchestrations) into the mix and thus not degrading your BizTalk performance.

From an operational point of view, having separated hosts allows for Production Support / BAU work to be carried out with minimal impact on other BizTalk applications. My experience has shown me that I’m usually NOT the only BizTalk consulting company or consultant who’s provided a BizTalk application for the given client; I am one of several, and adhering to this practice ensures that I’m a “good citizen”.

I urge you to read Tord Glad Nordahl’s groovy post over at on this topic.

Until next tip… be good!

BizTalk Server Performance Tips: #3 – Increase HTTP Outbound Connections Limit

Another quick tip for a performance improvement in BizTalk especially when using HTTP to communicate to other web services (in other words, you are using SOAP or WCF based Send Ports).

By default (thanks Microsoft!), a process will only allow two simultaneous outbound HTTP connections to any particular domain (eg, This can severely impact performance.

The key attribute to adjust here is maxconnection and can be found on the <ConnectionManagement> element in Machine.config. The default values are as follows.

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

The default value should be increased in the BizTalk process configuration files – rather than the Machine.config file – and I suggest that it be set it to 12 times the number of CPUs.

Thus, the resultant config entry becomes …. (the IP address has been changed to protect the innocent).

  <add address="" maxconnection="24"/>


Until next tip… be good!

BizTalk Server Performance Tips: #2 – Auto Growth

What’s so important about “Auto Growth”?

Firstly, let’s explore what it is and why it happens.

Auto-growth is an operation by which SQL Server expands the size of a database file (could be either the data file or the transaction log) when it runs out of space. How much depends on the settings that you have chosen; or if you’ve done no changes (which many don’t do), the default values of 1MB for data files and 10% for the log file. The growth settings available to choose for the files from are:-

  1. They can grow by a specific size
  2. Grow based on a percentage of the current size
  3. Not grow at all
  4. Unrestricted growth
  5. Set the growth of a database file to grow no larger than a specified size.

SQL Server, during the auto-growth operation, will block all current transactions until it completes the operation. If SQL Server is asking for a 1MB extension, that won’t take long. But imagine how long it will take if SQL Server was requesting for 2GB disk space?

On top of that, you need to understand that this disk space will not be contiguous (i.e., it won’t be physically right next to the existing database space), but instead will be somewhere else on the disk. You’re introducing disk fragmentation which will slow down SQL Server due to extra number of disk reads and writes that will now be necessary to support BizTalk. The more auto-growth operations you have, the more disk fragmentation!

That’s the theory, now let’s move onto what I reckon should be done and why.

1) Pre-size your BizTalk databases

You need to pre-size your databases so auto-growth is a contingency, not an expected behaviour.

Tim Form, a SQL Server MVP, believes that three years worth of transactions would be the basis of sizing your databases files. He even believes that auto growth is #10 of the Top 13 SQL Server Mistakes and Missteps

2) Pre-define the auto-growth setting for your data and transaction log files

Database auto-growth for both data and transaction log files should be set to 100MB instead of 1MB and 10% (respectively).

So, putting these together is very well summed up in the Microsoft BizTalk Performance Optimisation Guide. The guide states:

  • BizTalk DTADB (BizTalk Tracking database files): Data file having a file size of 2048 MB with 100 MB growth and a log file of 1024 MB with 100 MB growth.
  • BizTalkMgmtdb (BizTalk Management database files): Data file having a file size of 512 MB with 100 MB growth and a log file of 512 MB with 100 MB growth.
  • SSODB: Data file having a file size of 512 MB with 100 MB growth and a log file of 512 MB with 100 MB growth.
  • BizTalkMsgBoxDb (BizTalk MessageBox databases): 8 data files, each having a file size of 2 GB with 100 MB growth and a log file of 20 GB with 100 MB growth.


Here’s a screenshot of the database properties of the BizTalkDTADb with the guidelines in place.

Until next tip… be good!