Resources For IT Professionals
Page Details
  • First published by
  • When: 27 Feb 2012 5:58 AM
  • Last revision by (Microsoft)
  • When: 13 Sep 2013 11:27 AM
  • Revisions: 66
  • Comments: 59
Options

Revision #15

Wiki  >  TechNet Articles  >  BizTalk Server: Performance Tuning & Optimization  >  Revision #15
BizTalk Server: Performance Tuning & Optimization
You are currently reviewing an older revision of this page.
Go to current version

Table of Contents

Introduction

Tuning is a bit more art than science. No single tuning technique solves every problem, and very often techniques interact. The approach should always be methodical, including baseline and differential testing particularly when justifying capital expenditures.


Performance limitations should be viewed as a series of roadblocks. Removing one roadblock doesn’t clear the road, but simply makes it easier to drive. Not until all of the roadblocks have been removed does performance truly jump.

A word of caution. It’s important to understand each tuning technique, both what it does and why it works. Running application of the included scripts, registry files, etc. is not recommended and could lead to serious consequences for the target system. It is not recommended at all to change the settings to the production server directly. It is always recommended to perform the changes in UAT or DEV and then perform the changes in production in controlled manner following change process of your enterprise.

On this article we are trying to keep everything which is related to performance tuning & optimization of Microsoft BizTalk Server. Most of the concepts are valid across BizTalk Server versions , however it is always recommend to refer the production documentation of the applicable product version. 


Few Problems 


At some point of time, We face issues in our BizTalk Farm and then we think ways to identify and resolve those issues and we start searching for BizTalk Performance Tuning and Optimization options. The issues could be one of following or somewhere similar: 

  • BizTalk is performing slower ,when we drop the messages or during high volume of messages
  • Large no of messages are causing memory errors in BizTalk farm
  • Prolonged BizTalk Throttling
  • BizTalk receive location is not picking up the files
  • BizTalk Database Jobs are taking too much time to complete
  • Response time of message processing is increasing. There is a high latency in environment
  • It seems BizTalk is not able to process any message, The messages or service instance are in Active/Running State, however nothing is happening
  • SOAP Adapter is taking long time call a Web Service
  • Orchestration/Receive Port is taking  long time to debatch a large message
  • BizTalk production farm has suddenly started behaving strangle

Few Requirements

It is true, at some point of time, We start getting queries,thought or requirement similar to below and then we look for options to scale or optimize the BizTalk Server:

  • Looking for creating scalable BizTalk solutions
  • Trying to achieve a particular latency for a BizTalk application
  • Requirement to process 1000 messages in 1 seceond by a BizTalk application
  • Requirement of processing large messages in BizTalk Server
  • Planning to change the performance throughput
  • Trying to determine/test maximum sustainable throughput ( MST ) of my BizTalk farm
  • Trying to figure if BizTalk farm can support next 20+ applications which are going to be deployed in future
  • How should I decide if My BizTalk farm needs to be tuned or optimized
  • How  should I decide if BizTalk production farm needs to be scaled-up or scaled-out


What Should We Do

First Few Steps

 

If  you have anything similar in the list above (Few Problems), Then you should start with doing below things

  • Check SQL Server Agent and BizTalk Server Jobs Status of the BizTalk SQL Server Instance - The agent should always be running and all the BizTalk Jobs should be enabled from the day one in your production Farm , If there are any issues refer this in-depth wiki , "BizTalk Server:Databases: Survival Guide"
  • The Biztalk Host instance that has the "allow Host tracking" option set is stopped - If the host is stopped , then it should be started without any delay. As a practice there should always one dedicted "Tracking Host" should be running in BizTalk Farm.
  • Record count of the Spool table- the row count in the tables should not be too much or it should not keep growing. Check the record count of the Host Instance Queue tables. Refer "Understanding Host Queue Tables" article for more details
  • Free space of the Data and log file drives on SQL Server, as there should be enough free space in the log and data files drive on SQL Server.
  • Size of BizTalkDTADb database - Need to make sure the size is not too much of this database, It is a standard practice to keep an eye on the size of this database. Refer the following articles:
  • Excessive Disk I/O Latency (on SQL Server) - If the incoming rate of data into the MessageBox database is faster than which the system can process and move the data to the BizTalkDTADb database, backlog can build up in the MessageBox database. If the backlog continues to grow unabated, this is a very serious problem and system performance will degrade over time. One way to alleviate this problem is to install faster disks and/or upgrade the hardware to help ensure that the system is capable of recovering from any message backlogs experienced over time.

Review of Solution Design

Start reviewing the application design and architecture. Sometime a design change may have huge impact over the application performance. Following should be the starting reference points while reviewing the design and code of BizTalk solutions

  • Code of Custom Pipeline component
  • Are we using XMLDom to load the messages in pipeline
  • What is the method used to read the values in incoming message , Use streaming while reading the message or use XpathReader
  • Code of Orchestration
  • Design of MAP used in transformation of large messages
  • Are we using Enterprise Integration Patterns or not while designing solutions
  • What kind of Custom Code we are using?
  • Can we use inline send port instead of normal send ports?
  • How we are calling Business Rule engine in our BizTalk Orchestrations?
  • How many scopes have been used in orchestration
  • What kind of instrumentation or tracing is used

References for Code Review/Solution Design

Review Everything Else!


MSDN


Tools

Blogs

Hot Fixes

  • KB2627804 - Hotfix that improves the performance of the tracking feature in BizTalk Server
Revert to this revision