Determining the optimum number of BizTalk Hosts

Friday, July 8, 2011
post by Marcel

This post is written to get an overview of the different aspects one should take into consideration when creating multiple BizTalk hosts. There is no one-size-fits-all optimum for each BizTalk project. Generally it is a good practice to have a separate host for Receiving, Sending, Processing and Tracking and then add additional hosts as machine resources allow and tuning and managing require.

The BizTalk Host object represents a logical set of zero or more runtime processes in which you can deploy services, pipelines, and other artifacts. The Host object also represents a collection of runtime instances (zero or more) where the deployed items physically run.

After you create a host (a logical container), you can add physical BizTalk servers (host instances) to the host.

Items—such as adapter handlers, receive locations (including pipelines), and orchestrations—contained in BizTalk hosts can perform the following functions:

Receiving. These items do the initial processing of messages after they are picked up in a receive location. When a host contains a receiving item, such as a receive location or pipeline, it acts as a security boundary, and the message decoding and decrypting occurs in a pipeline within the host.
Sending. These items do the final processing of messages before they are sent out to the send port. When a host contains a sending item, such as a send port or pipeline, the host acts as a security boundary, and the message signing and encryption occurs in a pipeline within the host.
Processing. These items process messages based on the instructions in an orchestration.
One BizTalk Host can contain items that receive, send, and process messages. It is recommended that you create different hosts for each function to create security boundaries and facilitate management. In particular, it is recommended that you use different hosts for processing and for receive/send, and that you separate trusted and non-trusted items.

Separating Host Instances by Functionality

In addition to the high availability aspects of the host instance configuration, you should separate sending, receiving, processing, and tracking functionality into multiple hosts. This provides flexibility when configuring the workload in your BizTalk group and is the primary means of distributing processing across a BizTalk group. This also allows you to stop one host without affecting other hosts. For example, you may want to stop sending messages to let them queue up in the MessageBox database, while still allowing the inbound receiving of messages to occur. Also, orchestration and adapter functionality should be separated into different BizTalk Server hosts to minimize resource contention.

Separating host instances by functionality also provides the following benefits:

· Each host instance has its own set of resources such as memory, handles, and threads in the .NET thread pool.
· Multiple BizTalk Hosts will also reduce contention on the MessageBox database host queue tables since each host is assigned its own work queue tables in the MessageBox database.
· Throttling is implemented in BizTalk Server at the host level. This allows you to set different throttling characteristics for each host.
· Security is implemented at the host level; each host runs under a discrete Windows identity. This would allow you, for example, to give Host_A access to FileShare_B, while not allowing any of the other hosts to access the file share.

This host should be run on at least two computers running BizTalk Server (for redundancy in case one fails). Depending on the type of host either fail-over or clustering should be used.

Disadvantages of additional hosts
While there are benefits to creating additional host instances, there are also potential drawbacks if too many host instances are created. Each host instance is a Windows service (BTSNTSvc.exe), which generates additional load against the MessageBox database and consumes computer resources (such as CPU, memory, threads).

Several performance counters are reported per host.

Host consumes memory (at least 200MB (?) per host)

Polling receive adapters will poll for each host that they are enlisted in

SQL connections: Each host instance will poll the db at intervals of 500ms.

Too many hosts will:

· Cause a heavy load on the SQL Server and possibly will prevent processing of messages
· Consume too much memory on the BizTalk servers leading to a throttling situation (reduces performance)
· Too many receive hosts that poll the receive location will degrade the performance
· Too much granularity in performance counters. This has negative impact on the overall view an administrator has.

Tune the Host polling interval
BizTalk Server uses a polling mechanism to receive messages from its host queues in the MessageBox. The MaxReceiveInterval value in the adm_ServiceClass table of the BizTalk Management (BizTalkMgmtDb) database is the maximum value in milliseconds that each BizTalk host instance will wait until it polls the MessageBox. The adm_ServiceClass table contains a record for the following service types:

XLANG/S – for BizTalk orchestration host instances
Messaging InProcess – for in-process host instances
MSMQT – for MSMQT adapter host instances
Messaging Isolated – for out of process host instances, used by the HTTP, SOAP, and certain WCF receive adapter handler

By default, this value is set to 500 milliseconds, which is optimized for throughput rather than low-latency. In certain scenarios, latency can be improved by reducing this value.

Changes to this value impact all instances of the associated service type, therefore, take care to evaluate the impact on all host instances before changing this value.
This value is only used if the MessageBox has no remaining unprocessed messages. If there is a constant backlog of unprocessed messages in the MessageBox, BizTalk Server will attempt to process the messages without waiting on the polling delay. After all messages are processed, BizTalk Server will begin polling using the value specified for MaxReceiveInterval.
In a BizTalk Server environment with a high ratio of host instances to MessageBox database instances, decreasing the value for MaxReceiveInterval may cause excessive CPU utilization on the SQL Server computer that houses the MessageBox database instance. For example, if the MaxReceiveInterval is decreased to a low value (< 100) in a BizTalk Server environment with a single MessageBox and > 50 host instances, CPU utilization on the SQL Server may climb above 50%. This phenomenon can occur because the overhead associated with continually polling host queues is significant. If you reduce MaxReceiveInterval to a value less than 100, you should also evaluate the impact that this has on your SQL Server computer’s CPU utilization.

Quote: “(having many BizTalk hosts) seems like a bad solution. They will most likely see serious performance issues in the SQL layer as each host instance is “polling” for work. I have seen situations where many (maybe around 40) host instances were creating so much chatter with the MsgBox database that even when NO messages were being processed the CPU on the SQL box was at about 60%. Now, the customer did have the MaxReceiveInterval turned way down as well.”

Configuring a Dedicated Tracking Host
BizTalk Server is optimized for throughput, so the main orchestration and messaging engines do not actually move messages directly to the BizTalk tracking or BAM databases, as this would divert these engines from their primary job of executing business processes. Instead, BizTalk Server leaves the messages in the MessageBox database and marks them as requiring a move to the BizTalk Tracking database. A background process (the tracking host) then moves the messages to the BizTalk Tracking and BAM databases.

Advantages of Using a Dedicated Tracking Host
A BizTalk Host that hosts tracking is responsible for moving the DTA and BAM tracking data from the MessageBox database to the BizTalk Tracking (DTA) and BAM Primary Import databases. This movement of tracking data has an impact on the performance of other BizTalk artifacts running in the same host that is hosting tracking. Thus, you should use a dedicated host that does nothing but host tracking.

Using a dedicated tracking host also allows you to stop other BizTalk hosts without interfering with BizTalk Server tracking.

Best practices
Make your plan on how to separate hosts beforehand and how to name them. It is not possible to rename hosts.

Create separate hosts for different functions.

· Receiving
· Sending
· Processing
· Tracking

Add hosts for protocol or application specific requirements.

· Prioritization
· Batching vs. messaging
· Low latency
· Protocols that require clustering
· Protocols that require scale-out
· Separate hosts for applications with known or expects problems
When problematic applications are in a separate host, crashes will not affect applications in other hosts.
· Licensing of adapters
Certain 3rd party adapters are licensed separate from BizTalk Server. Separating per host can be a cost-effective deployment scheme.

MSDN: Hosts

MSDN: Host instances

Microsoft BizTalk Server Operations Guide BizTalk Server Performance Optimization Guide


  1. Hi,

    Thanks for an informative post.

    I have a question that I can't find the answer to anywhere and wondered if you knew the answer.

    Imagine we have a single host running two host instances (on two physical clustered machines). If we use an in-memory variable in an orchestration such as an array (purely for example) - if we add something to that variable on one host instance is it 'visible' on the other host instance? or do the two host instances have separate sets of memory?

    I suspect their memory is separate which will cause us problems as we have some applications that use global variables like these to store error information etc that other orchestrations might need to use!

  2. i'm not sure about your requirement but here is how biztalk handles memory

    As soon as a BizTalk host is started, a default AppDomain is created.
    All the code for processing send and receive ports will run in this AppDomain which includes any custom pipeline component and maps – where you would be able to implement and use any caching.
    Orchestrations run in an XLANG/s specific AppDomain which is created as soon as the first orchestration is run, This includes any maps called from your orchestration.
    This AppDomain will be shared by all orchestrations and applications running in that host.

    Soto answer your question YES it is possible if all the orchestrations or transforms accessing the global variables are running under the same App Domain


Post Your Comment...