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.
- BizTalkServerIsolatedHost: The logical container for HTTP, WCF (BasicHttp, CustomIsolated, WebHttp, and WSHttp) and SOAP Receive Handlers.
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:
Normally we read that we need to create at least 4 host instances:
- 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 ( https://docs.microsoft.com/en-us/biztalk/core/biztalk-server-64-bit-support2 )
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:
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.
- From the power plan page, choose the High-Performance option
- 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:
- Post-Configuration Database Optimizations
- How to exploit the Text In Row table option to boost BizTalk Server Performance
- Microsoft BizTalk Server 2013 Performance Optimization Guide
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’
- BizTalk Server 2013 R2: Installation and Configuration – Important considerations before set up the server (Part 1)
- BizTalk Server 2013 R2: Installation and Configuration – Enable Internet Information Services (Part 2)
- BizTalk Server 2013 R2: Installation and Configuration – Install Windows Identity Foundation (WIF) (Part 3)
- BizTalk Server 2013 R2: Installation and Configuration – Install and configure SMTP Server Feature (Part 4)
- BizTalk Server 2013 R2: Installation and Configuration – Install Microsoft Office Excel 2013 (Part 5)
- BizTalk Server 2013 R2: Installation and Configuration – Install Visual Studio 2013 (Part 6)
- BizTalk Server 2013 R2: Installation and Configuration – Install SQL Server 2014 (Part 7)
- BizTalk Server 2013 R2: Installation and Configuration – Configure SQL Server Database Mail feature (Part 8)
- BizTalk Server 2013 R2: Installation and Configuration – Install and Configure BizTalk Server 2013 R2 (Part 9)
- BizTalk Server 2013 R2: Installation and Configuration – Configure SQL Server Network Configuration protocols (Part 10)
- BizTalk Server 2013 R2: Installation and Configuration – Validate Mail account used by BizTalk to send BAM Alerts (Part 11)
- BizTalk Server 2013 R2: Installation and Configuration – Installing BizTalk Adapter Pack (Part 12)
- BizTalk Server 2013 R2: Installation and Configuration – Install and Configure Microsoft UDDI Services (Part 13)
- BizTalk Server 2013 R2: Installation and Configuration – Install and Configure the Microsoft BizTalk ESB Toolkit (Part 14)
- BizTalk Server 2013 R2: Installation and Configuration – Configure BizTalk Server SQL Jobs (Part 15)
- BizTalk Server 2013 R2: Installation and Configuration – Optimize the BizTalk Server 2013 R2 environment (Part 16)
- BizTalk Server 2013 R2: Installation and Configuration – Optimize the BizTalk Server 2013 R2 environment (Part 17)
- BizTalk Server 2013 R2: Installation and Configuration – Install additional Developer tools (Part 19)