BizTalk Server 2013 R2: Installation and Configuration – Optimize the BizTalk Server 2013 R2 environment (Part 18)

This next posts will focus on optimizing some BizTalk Server 2013 R2 configurations. The following recommendations can be used to increase BizTalk Server performance or just to make the platform more resilient to failures. The optimizations listed in this topic are applied after BizTalk Server has been installed and configured.

Configure host and Host instances

One of the tasks that we need to do in all our new BizTalk environment over and over again is creating and configuring the Host, Host Instances and of course the adapter handlers.

BizTalk Server provides great flexibility for addressing high availability, because you can strategically dedicate logical hosts to run specific areas of functionality such as receiving messages, sending messages or processing orchestrations.
By default the BizTalk configuration will create two BizTalk Host and Host Instances:

  • BizTalkServerApplication: This is the default Host and Host Instance created during configuration that will do all the work on the BizTalk Server, i.e. is the default send and receive handler for all installed adapters (other than HTTP, WCF (BasicHttp, CustomIsolated, WebHttp and WSHttp) and SOAP Receive Handlers), and is also used for processing orchestration and tracking.
BizTalk Server 2013 R2 BizTalkServerApplication Host
  • BizTalkServerIsolatedHost: The logical container for HTTP, WCF (BasicHttp, CustomIsolated, WebHttp, and WSHttp) and SOAP Receive Handlers.
BizTalk Server 2013 R2 BizTalkServerIsolatedHost Host

Although a single BizTalk Host can contain items that receive, send, and process messages, it is considered a best practice to create different hosts for each function to create security boundaries and for easier management and scalability. In particular, we recommend that you use different hosts for processing and for receive/send operations. And that you separate trusted and non-trusted items.

As the official documentation specify, 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.

Separating host instances by functionality also provides some of 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.

However, this also may bring some potential drawbacks if too many host instances are created because each host instance is a Windows service (BTSNTSvc.exe or BTSNTSvc64.exe), which generates additional load against the MessageBox database and consumes computer resources (such as CPU, memory, threads), so you need to be careful.

The following figure will provide you with a general overview of the relationship between servers, hosts and host instances, however, is not intended to be the best practices. This architecture will depend on many factors and will change from client to client:

BizTalk Server 2013 R2 Host and Host Instances

Normally we read that we need to create at least 4 host instances:

  • Sending
  • Receiving
  • Processing
  • And tracking

but that’s not absolutely true because, at least since BizTalk Server is supported in 64 bits, we typically use 64-bits versions and in this case we also need to create at least one Host Instance that will run on 32-bits because FTP adapter, SQL adapter, POP3 adapter and MIME Decoder on 64-bit host instances is not supported by the product ( )

We can define that one of the best practices for hosts and host instances is the following:

  • BizTalkServerTrackingHost: 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.
  • BizTalkServerReceiveHost: This host will be responsible for processing messages after they are picked up in a receive location.
  • BizTalkServerReceive32Host: has the same goal as the previous however this must have the “32-bits only” option selected so that we can run the 23-bits adapters.
  • BizTalkServerSendHost: This host will be responsible for processing messages before they are sent out to the send port.
  • BizTalkServerSend32Host: has the same goal as the previous however this must have the “32-bits only” option select so that we can run the 32-bits adapters.
  • BizTalkServerApplication: This host will be responsible for process messages based on the instructions in orchestrations that need to run in 32-bits.
  • BizTalkServerApplication64Host: This host will be responsible for process messages based on the instructions in all or most common orchestrations.

Note: You can create other Application Host if you want to separate process base in some application logic.

You can read more about this topic in more details in my previous post: PowerShell to Configure BizTalk Server Host and Host Instances according to some of the Best Practices or in TechNet Wiki: BizTalk Server Best Practices: Create and Configure BizTalk Server Host and Host Instances.

You can find a simple script to configure Host, Host Instances and Adapter Handlers described earlier in this post optimized for BizTalk Server 2013 R2 (and also 2013) in TechNet Gallery:

Power Mode

The different performance states are dynamically managed by Windows in conjunction with hardware and platform firmware to respond to varying workload requirements. The 3 default power plans exposed by Windows provide varying tradeoffs of performance vs. power consumption. For example, if the High-Performance power plan is selected, Windows places the system in the highest performance state and disables the dynamic scaling of performance in response to varying workload levels. Therefore, special care should be taken before setting the power plan to High Performance as this can increase power consumption unnecessarily when the system is underutilized.

In some cases, you may experience degraded overall performance on a machine when running with the default (Balanced) power plan. The issue may occur irrespective of platform and may be exhibited on both native and virtual environments. The degraded performance may increase the average response time for some tasks and cause performance issues with CPU-intensive applications

To change a power plan:

  • Press the “Windows key” to switch to the Start screen and type “Power Options” and click on “Power Options” option from the Search menu.
Windows Server 2012 R2 Power Options Menu
  • From the power plan page, choose the High-Performance option
Windows Server 2012 R2 Power Options High Performance
  • Close the Power Option window.

Consider setting the ‘text in row’ table option to boost BizTalk Server Performance

SQL Server provides a table option called text in a row to declare that the contents of the fields of type text, ntext, or image data whose dimensions are smaller than those of a data page (8Kb) must be stored in a data row. By setting this option on BizTalkMsgBoxDb tables (Parts table, Spool table, and DynamicStateInfo Tables), you can increase message throughput when working with small messages which have a small context and orchestrations that have a small persistence size. This makes reading and writing the in-row strings about as fast as reading or writing limited size varchar, nvarchar, or varbinary strings. Similarly, when the values are stored off-row, the Database Engine incurs an additional page read or write.

How to exploit the Text in Row table option in BizTalk Server

The following section explains how and when applying the text in row table option to boost BizTalk performance.

  • Parts Table: When the message size is smaller than the dimensions of a data page that are of 8kb, applying the text in row table option on the Parts table can lead to BizTalk Server performance improvement.
  • Spool Table: When the average size of the message context is less than 8 kb, enabling the text in row table option on the Spool table helps you reduce the number of accesses when reading messages from the MessageBox along with their context. To apply this option to the Spool table, you must eliminate unnecessary context properties and distinguished fields to reduce the size of the message context lower than 8 Kb.
  • DynamicStateInfo Tables: These tables, one for each host, contain a field of type image called imgData that contains binary-serialized orchestration state when they encounter a persistence point during their execution. When the internal state of orchestrations within a host HostA is so small that its size once serialized is less than 8 kb, the text in row technique can successfully be applied to the DynamicStateInfo_HostA table. Therefore we recommend that you keep the internal state of orchestrations as small as possible. This technique can significantly reduce the time that is spent by the XLANG Engine to serialize, persist, de-serialize and restore the internal state of orchestration in a case of persistence point.

See more about this topic in the following resources:

You can use the following settings sample that in your environment:

  • EXEC sp_tableoption N’Spool’, ‘text in row’, ‘6000’
  • EXEC sp_tableoption N’Parts’, ‘text in row’, ‘6000’

Related links

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

2 thoughts on “BizTalk Server 2013 R2: Installation and Configuration – Optimize the BizTalk Server 2013 R2 environment (Part 18)”

  1. Below is a script that will enable text-in-row , remember that if you create a new host you need to run the script again if you want that host to be able to use text-in-row.

    USE BizTalkMsgBoxDb
    DECLARE @tablename VARCHAR(512)
    DECLARE @InRowCount INT

    SELECT table_name FROM information_schema.tables where table_name like ‘%DynamicStateInfo%’ or table_name = ‘Parts’ or table_name = ‘Spool’

    OPEN dbcursor
    FETCH NEXT FROM dbcursor INTO @tablename

    SET @InRowCount = OBJECTPROPERTY (OBJECT_ID(@tablename), ‘TableTextInRowLimit’ )
    IF (@InRowCount = 0)
    EXEC sp_tableoption @tablename, ‘text in row’, ‘6000’
    select @tablename , OBJECTPROPERTY (OBJECT_ID(@tablename), ‘TableTextInRowLimit’ )
    FETCH NEXT FROM dbcursor INTO @tablename
    SELECT count(table_name) AS ‘Number of tables with Text-In-Row enabled’ FROM information_schema.tables where table_name like ‘%DynamicStateInfo%’ or table_name = ‘Parts’ or table_name = ‘Spool’
    SELECT table_name AS ‘Tables with Text-In-Row enabled’ FROM information_schema.tables where table_name like ‘%DynamicStateInfo%’ or table_name = ‘Parts’ or table_name = ‘Spool’

Leave a Reply

Your email address will not be published. Required fields are marked *


Back to Top