Contents

Microsoft BizTalk Server Performance Optimization Guide....................................................................10

Which versions of BizTalk Server does the guide cover?....................................................................10
What's in it?........................................................................................................................................ 10
Acknowledgements............................................................................................................................. 11

Getting Started....................................................................................................................................... 11
In This Section.................................................................................................................................... 12

Performance Factors.............................................................................................................................. 12
Message size...................................................................................................................................... 12
Schema complexity............................................................................................................................. 13
Map complexity................................................................................................................................... 13
Pipeline components........................................................................................................................... 13
Tracking data...................................................................................................................................... 15
Message-persistence frequency......................................................................................................... 15
Transport adapters.............................................................................................................................. 15
Business activity monitoring (BAM) performance factors....................................................................16
BAM disk usage configuration......................................................................................................... 16
BAM EventStream APIs................................................................................................................... 16
BAM performance counters............................................................................................................. 17
Host configuration............................................................................................................................... 17
Separation of sending, receiving, processing, and tracking functionality.........................................17
Orchestrations..................................................................................................................................... 18
Serializing, deserializing, or loading large messages into memory..................................................18
Use of promoted properties to access message tags or attributes from an orchestration...............18
Performance impact of orchestration persistence points.................................................................18
Effects of orchestration dehydration................................................................................................ 19
Performance impact of Orchestration complexity............................................................................19
Performance implications of using logical ports bound to physical ports.........................................19
Use of appropriate .NET classes in your orchestrations..................................................................19
Use of the Call Orchestration shape versus the Start Orchestration shape.....................................20
Using XmlReader with XLANGMessage versus using XmlReader with XmlDocument...................21
Considerations when using maps in orchestrations.........................................................................24
Impact of correlated messages on throttling....................................................................................25
Example....................................................................................................................................... 25
Recommendation......................................................................................................................... 26
Performance implications of delivery notification................................................................................26
Flat file processing performance considerations.................................................................................26
Business Rules Engine (BRE) performance factors............................................................................26
 Fact types........................................................................................................................................ 26
Data table vs. data connection........................................................................................................ 27
Fact retrievers.................................................................................................................................. 27
Rule priority..................................................................................................................................... 27
Update calls..................................................................................................................................... 27
Usage of logical OR operators......................................................................................................... 28
Caching settings.............................................................................................................................. 28
SideEffects property........................................................................................................................ 29
Instances and selectivity.................................................................................................................. 29
Performance metrics........................................................................................................................... 29
BizTalk Server performance metrics................................................................................................30
SQL Server performance metrics.................................................................................................... 30
See Also.............................................................................................................................................. 30

Performance Tools................................................................................................................................. 30
BizUnit 3.0 and BizUnit Designer........................................................................................................ 30
Performance Analysis of Logs (PAL)................................................................................................... 31
SQLIO................................................................................................................................................. 31
Microsoft BizTalk LoadGen 2007........................................................................................................ 31
Visual Studio Team Suite Testing Tools............................................................................................... 31
Windows Server 2003 Performance Advisor.......................................................................................31
BizTalk Server Orchestration Profiler.................................................................................................. 32

Phases of a Performance Assessment................................................................................................... 32

In This Section.................................................................................................................................... 34

Phase 1: Scoping the Assessment........................................................................................................ 34

Considerations before beginning the performance assessment.........................................................34
Message load.................................................................................................................................. 34
Develop a brief detail of the scenarios to be tested.........................................................................34
Identify which adapters will be used................................................................................................ 35
Estimate time required for the performance assessment.................................................................35
Documenting the performance assessment........................................................................................ 35
Goals and objectives....................................................................................................................... 36
Is the desired performance attainable?............................................................................................36
Hardware information to consider during scope phase....................................................................38
Software information to consider during the scope phase...............................................................38
Determine if code changes are within the scope of the performance assessment..........................39
Roles and responsibilities................................................................................................................... 39
Define all deliverables that are required at the onset of the performance assessment.......................43

Phase 2: Planning the Assessment....................................................................................................... 47

Solution milestones timeline................................................................................................................ 47
Non-Microsoft software considerations...............................................................................................49
 Physical space and other logistics...................................................................................................... 50

Phase 3: Preparing for the Assessment................................................................................................ 50

Detailed design of the solution platform.............................................................................................. 51
Detailed architecture diagram............................................................................................................. 53
Message flow diagrams...................................................................................................................... 53
Third-party software details................................................................................................................. 54
Detailed lab hardware stack................................................................................................................ 54
Detailed lab software stack................................................................................................................. 55

Phase 4: Building the Assessment Environment...................................................................................55

Obtain all build-lab infrastructure at least a week in advance of the lab start date..............................56
Configure third-party software systems...............................................................................................56
Install and configure the BizTalk Server environment.........................................................................56
Install the BizTalk Server application to be tested...............................................................................56
Implement automated build and load testing.......................................................................................57
Configure performance monitoring...................................................................................................... 57
Establish and document the solution’s baseline performance.............................................................58

Phase 5: Executing the Assessment..................................................................................................... 58

Step 1: Run automated tests............................................................................................................... 58
Step 2: Document and evaluate test results........................................................................................58
Step 3: Modify the configuration of BizTalk Server, third-party systems, or solution artifacts to tune for
performance based on the test results.............................................................................................58
Step 4: Record all changes made to the environment........................................................................58
Step 5: Repeat this cycle until goals are achieved..............................................................................59
Step 6: Summarize test results at the end of each day.......................................................................59
Step 7: Update the project plan as timeline goals are met..................................................................59

Finding and Eliminating Bottlenecks....................................................................................................... 59

In This Section.................................................................................................................................... 59

Best Practices for Avoiding Bottlenecks.................................................................................................59

SQL Server Guidelines....................................................................................................................... 60
See Also.............................................................................................................................................. 61

Investigating Bottlenecks........................................................................................................................ 61
What is the source of the problem?.................................................................................................... 61
Using an iterative approach to testing.................................................................................................61
Testing consistency............................................................................................................................. 62
Expectations: throughput vs. latency.................................................................................................. 63
Scaling................................................................................................................................................ 64

System Level Bottlenecks...................................................................................................................... 64

Creating a snapshot of the baseline configuration..............................................................................64
 Initial troubleshooting.......................................................................................................................... 67
High-level system bottlenecks............................................................................................................. 67
Disk I/O bottlenecks......................................................................................................................... 67
Performance counters for measuring disk I/O bottlenecks...........................................................70
Disk I/O tuning options................................................................................................................. 72
CPU bottlenecks.............................................................................................................................. 73
You may have a CPU bottleneck if…............................................................................................ 73
Performance counters for measuring CPU bottlenecks................................................................74
Resolving CPU bottlenecks.......................................................................................................... 75
Memory bottlenecks......................................................................................................................... 76
You might have a memory bottleneck if…....................................................................................76
Performance counters for measuring memory bottlenecks..........................................................76
Resolving memory bottlenecks..................................................................................................... 78
Network I/O bottlenecks................................................................................................................... 79
You might have a network I/O bottleneck if…...............................................................................79
Performance counters for measuring network I/O bottlenecks.....................................................79
Resolving network I/O bottlenecks............................................................................................... 80

Bottlenecks in the BizTalk Server Tier.................................................................................................... 80

Bottlenecks in the receive location...................................................................................................... 80
Processing bottlenecks....................................................................................................................... 81
Transmitting bottlenecks..................................................................................................................... 81
Tracking bottlenecks........................................................................................................................... 82
Other................................................................................................................................................... 82
BizTalk system performance counters................................................................................................82
CPU contention............................................................................................................................... 83
Spool table growth........................................................................................................................... 83
Memory starvation........................................................................................................................... 83
Disk contention................................................................................................................................ 84
Other system resource contention................................................................................................... 84
Downstream bottlenecks................................................................................................................. 85
Throttling impact.............................................................................................................................. 85
BizTalk application counters................................................................................................................ 85
Where do I start?............................................................................................................................. 86
Backlog buildup................................................................................................................................... 86
F1 profiler............................................................................................................................................ 87
L2/L3 cache........................................................................................................................................ 87
64-Bit performance bottlenecks.......................................................................................................... 87
Using BAM to identify bottlenecks and high-latency issues................................................................88

Bottlenecks in the Database Tier............................................................................................................ 88

In This Section.................................................................................................................................... 89

How to Identify Bottlenecks in the MessageBox Database....................................................................89

 Spool table growth.............................................................................................................................. 89
Application queue table growth........................................................................................................... 90
TrackingData table growth.................................................................................................................. 90
See Also.............................................................................................................................................. 91

How to Identify Bottlenecks in the Tracking Database............................................................................91

See Also.............................................................................................................................................. 92

How to Identify Bottlenecks in the BAM Database.................................................................................92

See Also.............................................................................................................................................. 92

How to Avoid Disk Contention................................................................................................................ 92

See Also.............................................................................................................................................. 94

Automating Testing................................................................................................................................. 94
In This Section.................................................................................................................................... 95

Why Is It Important to Test?.................................................................................................................... 95

Testing as “overhead”......................................................................................................................... 95
Testing methodology and timelines..................................................................................................... 97
Testing effectively and efficiently......................................................................................................... 98

Automating the Build Process................................................................................................................ 99

Overview of the build process............................................................................................................. 99
Build verification testing.................................................................................................................... 100
Functional testing.............................................................................................................................. 101
Positive tests................................................................................................................................. 102
Negative tests................................................................................................................................ 102
Automation is key.............................................................................................................................. 102

Using BizUnit for Automated Testing.................................................................................................... 103

In This Section.................................................................................................................................. 103

Stages of a BizUnit Test Case.............................................................................................................. 103

Setup Stage...................................................................................................................................... 104
Execution Stage................................................................................................................................ 104
Cleanup Stage.................................................................................................................................. 104

Defining Tests Using an XML Configuration File...................................................................................105

Overview of defining a BizUnit test case using XML configuration....................................................105
Full test case example................................................................................................................... 108

Automating Performance and Stability Testing.....................................................................................110

BizTalk Server performance testing, step-by-step.............................................................................110
The Microsoft BizTalk LoadGen 2007 tool......................................................................................... 111
Overview of LoadGen.................................................................................................................... 111
 Sample LoadGen configuration file................................................................................................ 112
Using BizUnit to drive LoadGen..................................................................................................... 113
The complete BizUnit LoadGen sample configuration file.............................................................121

Using BizUnit with the Business Process Management Scenario........................................................125

In This Section.................................................................................................................................. 125

Overview of the BPM Scenario............................................................................................................. 126

The BPM scenario............................................................................................................................ 126
Overview of the BPM scenario...................................................................................................... 126
Design patterns used within the BPM scenario.............................................................................127

BPM Scenario Architecture................................................................................................................... 129

High-level architecture overview of the BPM scenario......................................................................129

BPM Message Flow and Entry Points.................................................................................................. 131

BPM message flow and explanation of entry points to the system...................................................131
BPM message flow: high-level view of components used.................................................................132

Walkthrough: Using BizUnit to Test the BPM Scenario.........................................................................133

Objectives of testing the BPM scenario............................................................................................. 133
Prerequisite software required.......................................................................................................... 133
Creating a BizUnit testing project in Visual Studio 2005...................................................................133
Structuring the project....................................................................................................................... 135
Creating the test case configuration.................................................................................................. 136
Running BizUnit tests in a specific order........................................................................................... 149
Conclusion........................................................................................................................................ 151

Optimizing Performance....................................................................................................................... 151

In This Section.................................................................................................................................. 151

Optimizing Operating System Performance......................................................................................... 152

General guidelines for improving operating system performance.....................................................152
Install the latest BIOS, storage area network (SAN) drivers, network adapter firmware and network
adapter drivers........................................................................................................................... 152
Disable hyper-threading on BizTalk Server and SQL Server computers........................................152
Assign the MSDTC log file directory to a separate dedicated drive...............................................153
Configure antivirus software to avoid real-time scanning of BizTalk Server executables and file
drops.......................................................................................................................................... 153
Disable intrusion detection network scanning between computers in the BizTalk Server environment
................................................................................................................................................... 153
Defragment all disks in the BizTalk Server environment on a regular basis...................................154
If antivirus software is installed on the SQL Server computer(s), disable real-time scanning of data
and transaction files................................................................................................................... 154
Configure MSDTC for BizTalk Server............................................................................................154
 Configure firewall(s) for BizTalk Server.......................................................................................... 154
Install appropriate COM+ and MSDTC hotfix rollup packages.......................................................154
Install Windows Server 2003 SP2 to address problems that may occur with PAC verification for
services...................................................................................................................................... 155
Use the Interrupt Filter Configuration tool to bind network adapter interrupts to specific processors
on multiprocessor computers..................................................................................................... 155
Use the NTFS file system on all volumes......................................................................................156
Do not use NTFS file compression................................................................................................ 157
Review disk controller stripe size and volume allocation units.......................................................157
Monitor drive space utilization....................................................................................................... 158
Implement a strategy to avoid disk fragmentation.........................................................................158
Optimize Windows Server performance for background services.................................................158
Disable non-essential services...................................................................................................... 159
Manually load Microsoft Certificate Revocation lists......................................................................160
Synchronize time on all servers..................................................................................................... 161
Configure the Windows PAGEFILE for optimal performance.........................................................161
Remove CPU-intensive screen savers.......................................................................................... 162
Registry settings that can be modified to improve operating system performance...........................162
Increase available worker threads.................................................................................................162
Disable Windows Server 2003 SP 1 and SP2 denial of service checking.....................................164
Disable LDAP client signing requirements for computers in a secure intranet environment..........164
Increase space available for the master file table..........................................................................165
Change registry settings to maximize server service performance................................................165
Disable short-file-name (8.3) generation........................................................................................ 167
Optimize data throughput for network applications........................................................................168
Disable random driver verification.................................................................................................169
Disable NTFS last access updates................................................................................................169
Applying registry settings with the operating system optimization Windows PowerShell script.........170

Optimizing Network Performance......................................................................................................... 171

General guidelines for improving network performance....................................................................172
Add additional network cards to computers in the BizTalk Server environment.............................172
Implement network segmentation.................................................................................................. 172
Where possible, replace hubs with switches.................................................................................172
Remove unnecessary network protocols.......................................................................................172
Scalable Network Pack.................................................................................................................. 173
Network adapter drivers on all computers in the BizTalk Server environment should be tuned for
performance............................................................................................................................... 173
Registry settings that can be modified to improve network performance..........................................175
Applying registry settings with the network optimization Windows PowerShell script.......................191

Optimizing Database Performance....................................................................................................... 192

In This Section.................................................................................................................................. 192
Pre-Configuration Database Optimization............................................................................................ 192
Considerations for the version and edition of SQL Server................................................................193
Database planning considerations.................................................................................................... 194
If using SQL Server 2000, install the cumulative hotfix package for SQL Server 2000 SP4 build 2187
...................................................................................................................................................... 194
If using SQL Server 2005, install the latest service pack and cumulative update..............................194
Install SQL Service Packs on both BizTalk Server and SQL Server..................................................194
If using 32-bit SQL Server, configure SQL Server to use AWE.........................................................195
Set Min and Max Server Memory...................................................................................................... 195
Split the tempdb database into multiple data files of equal size on each SQL Server instance used by
BizTalk Server................................................................................................................................ 196
Enable Trace Flag T1118 as a startup parameter for all instances of SQL Server............................196
Do not change default SQL Server settings for max degree of parallelism, SQL Server statistics, or
database index rebuilds and defragmentation...............................................................................196

Post-Configuration Database Optimization..........................................................................................196

Pre-allocate space for BizTalk Server databases and define auto-growth settings for BizTalk Server
databases to a fixed value instead of a percentage value.............................................................197
Verify the BizTalk Server SQL Agent Jobs are running.....................................................................197
Configure Purging and Archiving of Tracking Data............................................................................198
Monitor and reduce DTC log file disk I/O contention.........................................................................198
Separate the MessageBox and Tracking Databases........................................................................199
Optimize filegroups for the BizTalk Server databases.......................................................................199
Install the BizTalk Server hotfix described in Microsoft Knowledge Base article 944234, “FIX: The
CPU usage remains high for a long time on a computer that is running SQL Server and BizTalk
Server 2006”.................................................................................................................................. 199

Optimizing Filegroups for the Databases............................................................................................. 200

Overview........................................................................................................................................... 200
Databases created with a default BizTalk Server configuration.........................................................201
Separation of data files and log files.................................................................................................203
The 80/20 rule of distributing BizTalk Server databases...................................................................204
Manually adding files to the MessageBox database, step-by-step....................................................204
Sample SQL script for adding filegroups and files to the BizTalk MessageBox database.................208

Optimizing BizTalk Server Performance...............................................................................................210

General guidelines for improving BizTalk Server performance..........................................................210
Create multiple BizTalk Server hosts and separate host instances by functionality.......................210
Configure a dedicated tracking host............................................................................................... 211
Increase the number of SOAP and HTTP adapter concurrent connections...................................212
Manually define worker and I/O thread values for Web applications that host orchestrations
published as a Web service........................................................................................................ 213
Define CLR hosting thread values for BizTalk host instances........................................................214
 Disable tracking for orchestrations, send ports, receive ports, and pipelines when tracking is not
required...................................................................................................................................... 217
Decrease the purging period for the DTA Purge and Archive job from 7 days to 2 days in high
throughput scenarios.................................................................................................................. 217
Install the latest service packs....................................................................................................... 217
Do not cluster BizTalk hosts unless absolutely neccessary...........................................................217
Low-latency scenario optimizations.................................................................................................. 217
Increase the BizTalk Server host internal message queue size.....................................................218
Optimize orchestration latency by reducing the number of persistence points, if possible............218
Reduce the MaxReceiveInterval value in the adm_ServiceClass table of the BizTalk Server
management database............................................................................................................... 218
MQSeries adapter performance optimizations..................................................................................219
Adjust the value for the MQSeries receive adapter polling threads...............................................219
Disable transaction support on MQSeries receive locations where not required...........................219
MQSeries low-latency configuration.............................................................................................. 219
Performance optimizations in the BizTalk Server documentation......................................................220

Windows PowerShell Scripts................................................................................................................ 220

Optimizing operating system performance registry settings..............................................................220
Optimizing network performance registry settings............................................................................223
Microsoft BizTalk Server Performance
Optimization Guide
Welcome to the first edition of the Microsoft® BizTalk® Server Performance Optimizations Guide. We
created this guide to provide in depth information for optimizing the performance of a BizTalk Server
solution. Full end-to-end performance testing is frequently overlooked during enterprise application
deployment. Knowing that Microsoft has built a scalable messaging infrastructure, many organizations
that use BizTalk Server spend little or no time conducting performance testing of their own applications.
BizTalk Server applications consist of many parts, which may include custom-built components as well
as those provided by Microsoft. It is impossible for Microsoft to performance test every possible
combination of these components. Therefore, fully and properly conducting a performance test of your
application is a critical step of any deployment. The purpose of this guide is to consolidate and provide
prescriptive guidance on the best practices and techniques that should be followed to optimize BizTalk
Server performance.
To download a copy of this guide, go to http://go.microsoft.com/fwlink/?LinkId=120792.

Which versions of BizTalk Server does the guide

cover?
We wrote this guide with both BizTalk Server 2006 and BizTalk Server 2006 R2 in mind. The topics
apply to both versions unless specifically noted.

What's in it?
Guidance for optimizing performance, based upon hands-on experience of IT professionals that have
worked extensively with BizTalk Server. This guide includes:
 Getting Started: The Getting Started section provides an overview of the BizTalk Server functional
components that can affect performance. This section also describes the phases of a BizTalk
Server performance assessment.
 Finding and Eliminating Bottlenecks: The Finding and Eliminating Bottlenecks section describes
various types of performance bottlenecks as they relate to BizTalk Server solutions and information
about how to resolve the bottlenecks.
 Automating Testing: The Automating Testing section provides detailed steps that you should
follow when engaging in end-to-end testing to assess the performance of a BizTalk Server solution.
This topic describes the importance of testing BizTalk solutions, how to implement an automated
build process, how to use BizUnit to implement automated testing and how to use LoadGen and
BizUnit together to perform load testing.
 Optimizing Performance: The Optimizing Performance section provides guidance for optimizing
performance of specific components in a BizTalk Server environment.

Acknowledgements
We in the BizTalk Server User Education team gratefully acknowledge the outstanding contributions of
the following individuals for providing both technical feedback as well as a good deal of content for the
BizTalk Server Performance Optimization Guide:
Authors
 Ewan Fairweather, Microsoft
 Rob Steel, Microsoft
Contributors
 Paolo Salvatori, Microsoft
 Ben Pearce, Microsoft
Reviewers
 Stephan Pepersack, Microsoft
 Justin Langford, Coeo
 Kevin B. Smith, Barclays Capital
 Christian Bolton, Coeo
 Brian Gregor, Microsoft
 Robert Hogg, Blackmarble
 John Plummer, Microsoft
 Niklas Engfelt, Microsoft
 Everett Yang, Microsoft
 Clint Huffman, Microsoft
 Shane Creamer, Microsoft
 Young Jun Hong, Microsoft
 Guy Lau, Microsoft

Getting Started
This section describes performance factors that typically come into play in a BizTalk Server
environment, tools that can be used to measure the performance of a BizTalk Server solution, and the
phases of a BizTalk Server performance assessment.
In This Section
 Performance Factors
 Performance Tools
 Phases of a Performance Assessment

Performance Factors
This topic describes the performance factors for the most commonly used components of a BizTalk
Server solution. Some components are used by most BizTalk solutions while others are optional. An
understanding of these factors will assist with the decision making process to maximize the
performance of a production BizTalk Server environment.

Message size
While BizTalk Server imposes no restriction on message size, practical limits and dependencies might
require you to minimize the size of your messages because large messages require more processing
resources. As message size increases, overall throughput (messages processed per second)
decreases. When designing your scenario and planning for capacity, consider the average message
size, message type, and number of messages BizTalk Server processes. Do not use unnecessarily long
attribute and tag names; if possible, keep the length under 50 characters. For example, do not use a
200-character tag name for a message size of only 1 byte.
If the in-memory size of a received message exceeds the number of bytes specified for the Large
message fragment size that is configurable on the Group Properties page for the BizTalk Group in
the BizTalk Server Administration console, then the message is split into fragments of the specified size
and the fragments are written into the MessageBox under the context of a Microsoft Distributed
Transaction Coordinator (MSDTC) transaction as follows:
1. If the incoming message is being published under the context of an existing MSDTC transaction,
then this transaction is used when writing the message fragments to the MessageBox. For
example, if the incoming message is being published by a transactional adapter configured to
require transactions then the existing transaction would be used when writing the message
fragments to the MessageBox.
2. If the incoming message is not being published under the context of an existing MSDTC
transaction, then a new MSDTC transaction is created to write the message fragments to the
MessageBox database. In this scenario, the following considerations apply:
 Increase the value for Large message fragment size to reduce the frequency with which large
messages are fragmented and reduce the incidence of creating the associated MSDTC
transactions. This should be done because excessive use of MSDTC transactions is expensive
from a performance standpoint. Note that increasing this value may also increase the amount
of available memory that is used.
  If it takes longer than the maximum allowable MSDTC transaction timeout of 60 minutes to
write a message to the MessageBox, then the transaction times out, an error occurs, and the
attempt to write the message fails and is rolled back. The Large message fragment size value
should be increased enough to avoid this problem when processing very large messages.
Depending on available memory, this value should be increased up to a maximum value of
1000000 bytes.
 Each message fragment in a message creates one or more SQL Server database locks against
the MessageBox database. When the number of locks exceeds several hundred thousand, it is
possible that SQL Server will generate “out of lock” errors. If this problem occurs, increase the
value for Large message fragment size to reduce the number of fragments (which decreases
the number of SQL Server database locks made against the MessageBox database) or
consider housing your MessageBox database on a 64-bit version of SQL Server. The number
of available locks is significantly higher on the 64-bit version of SQL Server than on a 32-bit
version of SQL Server. The following formula can be used to estimate the maximum number of
messages per interchange when the MessageBox database is housed on a 32-bit version of
SQL Server:
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)

For more information on how BizTalk Server processes large messages, see “How BizTalk Server
Processes Large Messages” in the BizTalk Server 2006 R2 help at http://go.microsoft.com/fwlink/?
LinkID=102620.

Schema complexity
The throughput for message parsing (especially flat-file parsing) is affected by the complexity of the
schemas. As schema complexity increases, overall performance decreases. When designing schemas,
reduce the length of node names and move promoted properties to the top of the schema to reduce
retrieval time to increase performance.

Map complexity
Depending on the complexity of the maps, map transformation can be resource intensive. As map
complexity increases, overall performance decreases. To improve overall performance, minimize the
number of links and functoids used in your maps, especially functoids that call external resources such
as the DB Lookup functoid.

Pipeline components
Because pipeline components have a significant impact on performance (for example, a pass-through
pipeline component performs up to 30 percent better than an XML assembler/disassembler pipeline
component), make sure that any custom pipeline components perform optimally before implementing
them in your deployment. Minimize the number of pipeline components in your custom pipelines if you
want to maximize the overall performance of your BizTalk application.
You also can improve overall performance by reducing the message persistence frequency in your
pipeline component and by coding your component to minimizing redundancy. Every custom assembly
and in particular artifacts that could potentially disrupt performance, like custom tracking components,
should be tested separately under heavy load condition to observe their behavior when the system is
working at full capacity and to find any possible bottlenecks.
If you need to read the inbound message inside a pipeline component, avoid loading the entire
document into memory using an XmlDocument object. The amount of space required by an instance of
the XmlDocument class to load and create an in-memory representation of a XML document is up to 10
times the actual message size. In order to read a message, you should use an XmlTextReader object
along with an instance of the following classes:
 VirtualStream (Microsoft.BizTalk.Streaming.dll) - The code for this class is located in two
locations under the Pipelines SDK as follows:
SDK\Samples\Pipelines\ArbitraryXPathPropertyHandler and
SDK\Samples\Pipelines\SchemaResolverComponent\SchemaResolverFlatFileDasm.
 ReadOnlySeekableStream (Microsoft.BizTalk.Streaming.dll).
 SeekAbleReadOnlyStream - The source code for this class is located in two locations under the
Pipelines SDK as follows: SDK\Samples\Pipelines\ArbitraryXPathPropertyHandler and
SDK\Samples\Pipelines\SchemaResolverComponent\SchemaResolverFlatFileDasm.
If XLANG/s is generating an XML message, then we recommend not using the XMLTransmit pipeline on
the send side. Doing so incurs processing overhead. We recommended that you use the PassThru
pipeline on the send side in all cases except where additional pipeline processing is required.
Use the PassThruReceive and the PassThruTransmit standard pipelines whenever possible. They do
not contain any pipeline component and do not perform any processing of the message. For this
reason, they ensure maximum performance in receiving or sending messages. You can use a
PassThruReceive pipeline on a receive location if you need to publish a binary document to the BizTalk
MessageBox and a PassThruTransmit pipeline on a send port if you need to send out a binary
message. You can also use the PassThruTransmit pipeline on a physical send port bound to an
orchestration if the message has been formatted and is ready to be transmitted. You will need to use a
different approach if you need to accomplish one of the following actions:
 Promoting properties on the context of the inbound XML or Flat File message
 Applying a map inside the receive location
 Applying a map in a orchestration subscribing the message
 Applying a map on a send port subscribing the message
To accomplish one of these actions, you must probe and discover the document type inside the receive
pipeline and assign its value (namespace#root-name) to the MessageType context property. This
operation is typically accomplished by a disassembler component as the Xml Disassembler component
(XmlDasmComp) or the Flat File disassembler component (FFDasmComp). In this case, you need to
use a standard (e.g. XmlReceive pipeline) or a custom pipeline containing a standard or a custom
disassembler component.
Inside a receive pipeline, you should promote items to the message context only if you need them for
message routing (Orchestrations, Send Ports) or demotion of message context properties (Send Ports).
If you need to flow metadata with a message, and you don't use them for routing or demotion purposes,
use the IBaseMessageContext.Write method instead of the IBaseMessageContext.Promote method.
Acquire resources as late as possible and release them as early as possible. For example, if you need
to access data on a database, open the connection as late as possible and close it as soon as possible.
Use the C# using statement to implicitly release disposable objects or the finally block of a try-catch-
finally statement to explicitly dispose your objects. Instrument your source code to make to make your
components simple to debug.
If you need to extract information from a message using an XPath expression, avoid loading the entire
document into memory using an XmlDocument object just to use the SelectNodes or SelectSingleNode
methods. Instead, you should:
 Load the message using an instance of the SeekAbleReadOnlyStream class.
 Create an instance of the XPathReader .NET class that you can find in the
Microsoft.BizTalk.XPathReader.dll assembly.
 Use the methods (ReadUntilMatch, Match, etc.) of the XPathReader instance to find out matches.

Tracking data
The amount of message tracking can have a significant impact on performance. As the number of items
tracked and the amount of tracking data increases, overall performance decreases. We recommend
putting the Tracking database on a separate server. It is important that you ensure the SQL agent jobs
are running. In addition, run the tracking service (TDDS) to move tracking data from the MessageBox
database to the Tracking database (BizTalkDTADb) and monitor the Tracking database for disk growth.
Archive and clean up the Tracking database regularly by backing up and deleting old files.

Message-persistence frequency
BizTalk Server commits all write operations to the MessageBox database, which stores messages and
state information for particular message instances. This persistence allows BizTalk Server to ensure
data integrity, security, and reliability. As message-persistence frequency increases, overall
performance decreases. Whenever possible, reduce the frequency at which data needs to be persisted
to the message box. For example, group multiple message-persistence points into one scope.

Transport adapters
While scenarios define the particular transport adapters that are required, transport adapters have
different settings that you can modify to improve performance. For example, orchestration and adapter
functionality should be separated into different BizTalk Server hosts to minimize resource contention.
For more information, refer to the article BizTalk Server 2006: Comparative Adapter Study at
http://go.microsoft.com/fwlink/?LinkId=116888 and Configuration Parameters that Affect Adapter
Performance at http://go.microsoft.com/fwlink/?LinkId=108785.
Business activity monitoring (BAM) performance
factors
BAM disk usage configuration
BAM incurs significant overhead when a BizTalk system is under load due to the significant amount of
data that is persisted to the BAM database. Therefore, judicious use of disk I/O techniques for the BAM
database critically important.

BAM EventStream APIs

Four types of EventStreams are available for use in a BizTalk BAM scenario:
 DirectEventStream (DES)
 BufferedEventStream (BES)
 OrchestrationEventStream (OES)
 MessageEventStream (MES)
You should choose one of these APIs based on the following factors:
 If your concern is latency, choose DES, where data is persisted synchronously to the BAM Primary
Import database.
 If your concern is performance and throughput of event insertion, choose an asynchronous API
(BES, OES or MES).
 If you are writing an application that runs on a computer that does not have BizTalk Server installed,
use DES and BES, these APIs can be used in non-BizTalk applications.

Note
There are scenarios in which you may want to mix EventStream types. For example, for
pipeline processing, you may want to capture the particular data in BAM regardless of
whether the pipeline is rolling back its transaction. In particular, you may want capture data
about how many messages failed or how many retries occurred during pipeline processing.
To capture the data in this situation you should use BES.
 If your application runs on a computer on which BizTalk Server is installed, use MES and OES.
(These APIs are available only from BizTalk applications.)

Note
OES is the equivalent of MES but for BizTalk orchestrations.
 If you want BAM event persistence to be in sync with pipeline transaction, you should use a
Messaging Event Stream (MES).
All the asynchronous EventStreams (BES, MES, and OES) persist data first to the BizTalk MessageBox
database. Periodically the data is processed and persisted to the BAM Primary Import database by the
Tracking Data Decode Service (TDDS).
For more information about the BAM EventStream APIs, see “EventStream Classes” in the BizTalk
Server 2006 R2 documentation at http://go.microsoft.com/fwlink/?LinkId=115092.

BAM performance counters

For a detailed list of the performance counters for BAM, see “BAM Performance Counters” in the
BizTalk Server 2006 documentation at http://go.microsoft.com/fwlink/?LinkId=115093.

Host configuration
Host configuration has a significant impact on performance. BizTalk Server supports the isolation of
individual components (including orchestrations, adapters, pipelines, and tracking) into separate hosts,
which are logical entities with specific functionality. Careful consideration should be given to the host
design of a BizTalk Server solution. How a project decides to allocate processing to hosts and host
instances can be a determining factor for that solution’s performance capability. Below are some key
heuristics to consider during creation of host design.

Separation of sending, receiving, processing, and tracking

functionality
Configure the deployment topology such that different functionality runs in dedicated host instances.
This way each host instance gets its own set of resources (on a 32-bit system, 2GB virtual memory
address space, handles, threads). If the server is powerful enough (sufficient CPU headroom, memory)
to host multiple host instances, they can all be configured to run on the same physical machine. If not,
this also makes it easy to scale-out by moving the host instances to dedicated servers. Running the
same functionality on multiple servers also provides a highly available configuration.
The tracking host instance is responsible for moving both BAM and HAT data from the MessageBox
database (TrackingData table) to the BizTalkDTADb tracking database and/or the BAMPrimaryImport
database. If multiple MessageBox databases are configured the tracking host instance uses four
threads per MessageBox. When creating a host, you must consider the “enable tracking” check box.
This box should only be checked on hosts that are dedicated to tracking and which will have no other
BizTalk artifacts running in that host. Turning off Global tracking significantly reduces tracking overhead,
but keep in mind that you must still have at least one tracking host instance and it must be started.
Otherwise you can mitigate the need for a tracking host if Global Tracking is turned off and if only the
direct event stream from BAM is used.
For more information about creating scalable host configurations, see Optimizing BizTalk Server
Performance.

Orchestrations
The following performance factors should be considered when implementing orchestrations in a BizTalk
Server solution:
Serializing, deserializing, or loading large messages into memory
Avoid loading entire documents into orchestrations using an XmlDocument object. If you need to read a
message inside an orchestration, avoid loading the entire document into memory using an
XmlDocument object, use XmlReader instead when possible (as described below in the section “Use of
appropriate .NET classes in your orchestrations”

Use of promoted properties to access message tags or attributes

from an orchestration
If you do need to promote properties, promote only those properties that are used for message routing,
filters, and message correlation. The promotion of each property requires the disassembler component
(XML, Flat, custom) to recognize the document type and to retrieve data from the message using the
XPath expression from the relative annotation contained in the XSD which defines the document type.
In addition, each property promotion causes a separate call of the bts_InsertProperty stored procedure
when the Message Agent publishes the message to the MessageBox database. If an orchestration
needs to access a particular element or attribute contained by an XML document, use one of the
following techniques:
1. Use distinguished fields.
2. Use the XPath built-in function provided by the orchestration runtime.
3. if messages are quite small (a few kilobytes) and XML-formatted, you can deserialize the message
into a .NET class instance and work with public fields and properties. If the message needs a
complex elaboration (custom code, Business Rule Engine policies, etc.) accessing data using the
properties exposed by an instance of a .NET class is much faster using XPath expressions. When
the business logic invoked by the orchestration has completed, the entity object can be serialized
back into a BizTalk message. You can create .NET classes from an XML schema using one of the
following tools: XSD tool (.NET Framework 2.0) or SVCUTIL (.NET Framework 3.0).

Performance impact of orchestration persistence points

Persistence of the state of each orchestration and how often this occurs will directly affect the
performance of orchestrations in your solution. At design time, ensure that you completely understand
the concept of orchestration persistence points. For more information about the how orchestration
persistence points work in BizTalk Server, see “Persistence and the Orchestration Engine” in the
BizTalk Server 2006 R2 documentation at http://go.microsoft.com/fwlink/?LinkID=108780.

Effects of orchestration dehydration

When many service instances are running at the same time, memory and performance are potential
issues and dehydration will be an issue. For more information about orchestration dehydration and
rehydration, see “Orchestration Dehydration and Rehydration” in the BizTalk Server 2006 R2
documentation at http://go.microsoft.com/fwlink/?LinkID=106789.
Performance impact of Orchestration complexity
The complexity of orchestrations has a significant impact on performance. As orchestration complexity
increases, overall performance decreases. Orchestrations can be used in an almost infinite variety of
scenarios, and each scenario might involve orchestrations of varying complexity. Avoid complex
orchestrations when possible in favor of a modular approach. In other words, split your business logic
into multiple, reusable orchestrations.
If you do need to implement a complex orchestration, define messages and variables into inner scopes
whenever possible rather than at the root level. This technique maintains a smaller footprint in memory
for each orchestration because variables and messages are disposed of when the flow leaves the
scope where the variables and messages were defined. This approach is particularly beneficial when
orchestrations are saved to the MessageBox at persistence points.

Performance implications of using logical ports bound to physical

ports
You can increase performance by eliminating logical ports bound to physical ports that use the following
adapters:
 SQL Server, Oracle
 SOAP, WSE, HTTP, WCF
 MSMQ, MQ Series
In BizTalk Server 2006, send and receive pipelines can be directly invoked from an orchestration using
the XLANGPipelineManager class contained in the Microsoft.XLANGs.Pipeline.dll. Thus, the
processing of pipelines can be moved from ports to orchestrations, while logical ports in an
orchestration can be substituted with an Expression Shape which invokes an instance of a given .NET
class (for example, a SOAP proxy classes or a Data Access component using ADO.NET). Before
adopting this technique, you should be aware that if you do not use adapters and physical ports, you
lose the ability to leverage their functions, such as batching, retries, declarative configuration and
secondary transports.

Use of appropriate .NET classes in your orchestrations

In general, we can divide the .NET classes used inside an orchestration in two separate categories:
 Helpers and services - These classes provide common services to orchestrastions such as
tracing, error handling, caching, and serialization/deserialization. Most of these classes can be
implemented as static classes with no internal state and multiple public static methods. This
approach avoids creating multiple objects of the same class in different orchestrations running at
the same time, which helps to reduce the working space of host processes and save memory. A
class that is stateless helps to reduce the overall size of the internal state that must be serialized
and persisted to the BizTalk MessageBox when an orchestration is dehydrated.
 Entities and Business Objects - You can use these classes to manage entities, such as orders,
order items, and customers. A single orchestration can internally create and manage multiple
 instances of the same type. These classes are typically stateful and expose public fields and/or
properties along with methods to modify the internal state of the object. Instances of these classes
can be dynamically created by deserializing an XLANGMessage part into a .NET object using the
XmlSerializer or the DataContractSerializer classes or by using the XLANGPart.RetrieveAs method.
You should structure an orchestration using non-transactional scopes in such a way that instances
of stateful classes are created as late as possible and released as soon as they are no longer
needed. This approach reduces the working space of host processes and minimizes the overall
size of the internal state that is serialized and persisted to the MessageBox database when an
orchestration is dehydrated. For more information about using orchestrations in Microsoft BizTalk
Server 2004 and BizTalk Server 2006, see the article “FAQ for BizTalk Server Orchestrations” at
http://go.microsoft.com/fwlink/?LinkID=116886.

Use of the Call Orchestration shape versus the Start Orchestration

shape
Avoid the Start Orchestration shape and use the Call Orchestration shape to execute a nested
orchestration. In fact, The Call Orchestration shape can be used to synchronously call an
orchestration that is referenced in another project. This approach allows for reuse of common
orchestration workflow patterns across BizTalk projects. When you invoke another nested orchestration
synchronously with the Call Orchestration shape, the enclosing orchestration waits for the nested
orchestration to finish before continuing. The nested orchestration is executed on the same thread that
runs the calling orchestration.
The Start Orchestration shape is similar to the Call Orchestration shape, but in this case the nested
orchestration is called in an asynchronous manner: the flow of control in the invoking orchestration
proceeds beyond the invocation, without waiting for the invoked orchestration to finish its work. In order
to implement this decoupling between the caller and the called orchestrations, the Start Orchestration
is implemented via publication of a message to the BizTalk MessageBox. This message is then
consumed by an in-process BizTalk host instance which executes the nested orchestration. When
possible, use Call Orchestration, especially if the calling orchestration needs to wait for a result from
the nested orchestration in order to continue processing.

Using XmlReader with XLANGMessage versus using XmlReader

with XmlDocument
To improve orchestration performance for .NET methods called from an orchestration, use XmlReader
with XLANGMessage, not XmlDocument. The following sample code illustrates this functionality:
// As a general rule, use XmlReader with XLANGMessage, not XmlDocument.

// This is illustrated in the parameter passed into the following code.

// The XLANG/s compiler doesn't allow a return value of XmlReader

// so documents must be initially constructed as XmlDocument()

public static XmlDocument FromMsg(XLANGMessage old)

{

//get at the data

XmlDocument ret = new XmlDocument();

try{

XmlReader reader = (XmlReader)old[0].RetrieveAs(typeof(XmlReader));

//construct new message from old

//read property

object msgid = old.GetPropertyValue(typeof(BTS.MessageID));

finally {

// Call Dispose on the XLANGMessage object

// because the message doesn't belong to the

// .NET runtime - it belongs to the MessageBox database

old.Dispose();

return ret;

Another method would be to create a .NET class based on the schema. This takes less memory than
loading the document into an XmlDocument object, as well as providing easy access to the schema
elements for .NET developers. To generate a class based on a BizTalk schema, you can use the
xsd.exe tool provided with Visual Studio 2005. For example, running xsd.exe <schema.xsd> /classes
against a simple schema containing fields named ItemA, ItemB, ItemC, will produce the following class:
//------------------------------------------------------------------------------

// <auto-generated>

// This code was generated by a tool.

// Runtime Version:2.0.50727.1433

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </auto-generated>

//------------------------------------------------------------------------------

using System.Xml.Serialization;
//

// This source code was auto-generated by xsd, Version=2.0.50727.42.

//

/// <remarks/>

[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]

[System.SerializableAttribute()]

[System.Diagnostics.DebuggerStepThroughAttribute()]

[System.ComponentModel.DesignerCategoryAttribute("code")]

[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true,
Namespace="http://Schemas.MySchema")]

[System.Xml.Serialization.XmlRootAttribute(Namespace="http://Schemas.MySchema",
IsNullable=false)]

public partial class MySchemaRoot {

private string itemAField;

private string itemBField;

private string itemCField;

/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)
]

public string ItemA {

get {

return this.itemAField;

set {

this.itemAField = value;

}
 }

/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)
]

public string ItemB {

get {

return this.itemBField;

set {

this.itemBField = value;

/// <remarks/>

[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)
]

public string ItemC {

get {

return this.itemCField;

set {

this.itemCField = value;

This class can then be referenced in your .NET assembly in order to access the message elements,
and the returned object can be directly assigned to a message. The following is an example use of the
class generated above:
public static Root SetValues(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)

MySchemaRoot rootObj=(MySchemaRoot)msg[0].RetrieveAs(typeof(MySchemaRoot);
 rootObj.ItemA="value a";

rootObj.ItemB="value b";

rootObj.ItemC="value c";

return rootObj;

This technique allows you to use an object-oriented approach when processing messages. This
technique should be used primarily with relatively small messages because even though this technique
uses considerably less memory than when loading the message into an XmlDocument object, the
entire message is still loaded into memory. When processing larger messages, use the XmlReader
class to read messages and the XmlWriter class to write messages. When using XmlReader and
XmlWriter, the message is contained in a VirtualStream object and if the size of the message size
exceeds the value specified for Large message threshold (bytes) exposed on the BizTalk Group
Properties configuration page then the message is written to the file system. This decreases overall
performance, but avoids out of memory exceptions.

Considerations when using maps in orchestrations

The following considerations apply when using maps in orchestrations:
 If you are using a map to extract or set properties used with business logic in an orchestration, use
distinguished fields or promoted properties. When extracting or setting values with a map the
document is loaded into memory. When using distinguished fields or promoted properties, the
orchestration engine accesses the message context and does not load the document into memory.
 If you are using a map to aggregate several fields into one field, use distinguished fields or
promoted properties with an orchestration variable to accumulate the result set.
 Do not configure an orchestration with multiple inputs to transform shapes. An orchestration that
contains multiple inputs to transform shapes will not stream to the file system while mapping. This
behavior will cause the entire document that is being mapped to load into memory if the document
size exceeds the specified TransformThreshold registry value. One possible workaround to this
issue would be to apply transforms at the receive port level so that the orchestration never accepts
more than a single input to transform shapes.

Impact of correlated messages on throttling

Messages that are en-queued into BizTalk Server, for example, through a receive location or by
orchestrations, can be processed in one of the following ways:
 They can activate new instances of subscribers (that is, orchestrations or send ports)
 They can be routed to an existing subscriber instance via correlation. For more information about
correlation, see “Using Correlations in Orchestrations” in the BizTalk Server 2006 R2 help at
http://go.microsoft.com/fwlink/?LinkId=119927.
Many developers tend to use a single receive location to receive both activation and correlated
messages for a solution through the same port. This is natural as it minimizes the number of addresses
that message senders need to keep track of. However, there can be advantages to creating separate
receive locations for activation messages and correlated messages.
When both activation and correlation messages arrive through the same receive location, they are
subject to the same throttling state because throttling is applied at the host level. As a result, all
messages arriving at receive locations in the host will be throttled as a unit. This is not an issue for
many scenarios, but there are cases where throttling correlations with activations can result in a type of
system deadlock.

Example
For example, consider a scenario whereby an orchestration receives an activation message that
initializes a correlation set, which in turn receives a convoy of 10 messages that follow the correlation
set. In addition, assume that the mix of activation and correlation messages cause a backlog of
messages in the spool table which triggers a throttling condition that limits the amount of messages that
can be received. Unfortunately, the correlation messages are throttled along with the activation
messages, which slows down the completion of orchestrations, causing further backlog and additional
throttling. Allowed to continue, this can cause the throttling mechanism to reduce system throughput to
nearly zero.
By splitting the single receive location into two receive locations -- one for activations and one for
correlations -- and configuring the locations in separate hosts, the database size throttling threshold for
the activations can be kept lower than that for correlations, which will result in reduced overall backlog,
and keep messages flowing.
So, you might be asking "Why can’t I just raise the database size threshold for my single receive
location to fix the problem?" The answer is, you can, but it won’t always result in the desired behavior.
Throttling is there primarily to protect the system from becoming overloaded. If you raise the thresholds
high enough, or turn them off altogether, you will eliminate this protection.

Recommendation
The best practice for scenarios such as the one described above that are sensitive to throttling
correlation messages, is to separate the receive locations into separate hosts which can be throttled
independently.
When separate hosts are configured for receive locations, set the database size throttling threshold for
the host used by the receive locations to a lower value than the database size throttling threshold for
hosts used by orchestrations or correlations.
If you know that your load will never be higher than the maximum sustainable throughput (MST) for the
system, or that throughput peaks are recoverable between peak events, then raising the throttling
thresholds will also work, but may not sustain as high a throughput as using separate hosts for
activations and correlations.
Performance implications of delivery notification
Be aware of the performance implications of using delivery notification. Delivery notification incurs
overhead that negatively impacts the overall throughput of a solution so only use it when absolutely
necessary. BizTalk creates an internal subscription for each delivery notification and uses an internal
correlation set to return a message to the corresponding orchestration instance. More subscriptions
entail more work for the master MessageBox, which ultimately reduces the maximum sustainable
throughput of the system.

Flat file processing performance considerations

The two factors that have the highest impact on the performance of flat-file parsing are file size and
schema complexity. An ambiguous schema is a schema that contains many optional fields. When large
file sizes are used, a schema with many optional fields can degrade performance because larger files
may match different branches of the schema. Schema complexity has less impact on smaller files than
on larger files.

Business Rules Engine (BRE) performance factors

The following factors should be considered when implementing BRE in a BizTalk Server solution:

Fact types
The rule engine takes less time to access .NET facts compared to the time it takes to access XML and
database facts. If you have a choice of using either .NET or XML or database facts in a policy, you
should consider using .NET facts for improved performance.

Data table vs. data connection

When the size of the data set is small (< 10 or so), the TypedDataTable binding provides better
performance than the DataConnection binding. However, the DataConnection binding performs better
than the TypedDataTable binding when the data set is large (greater than or equal to 10 rows
approximately). Therefore, you should decide whether to use the DataConnection binding or
TypedDataTable binding based on the estimated size of the data set.

Fact retrievers
A fact retriever implements standard methods which are typically used to supply long-term and slowly
changing facts to the rule engine before a policy is executed. The engine caches these facts and uses
them over multiple execution cycles. Instead of submitting a static or fairly static fact each time that you
invoke the rule engine, you should create a fact retriever that submits the fact for the first time, and then
updates the fact in memory only when necessary.
Rule priority
The priority setting for a rule can range on either side of 0, with larger numbers having higher priority.
Actions are executed in order from the highest priority to lowest priority. When the policy implements
forward-chaining behavior by using Assert/Update calls, the chaining can be optimized by using the
priority setting. For example, assume that Rule2 has a dependency on a value set by Rule1. Giving
Rule1 a higher priority means that Rule2 will only execute after Rule1 fires and updates the value.
Conversely, if Rule2 were given a higher priority, it could fire once, and then fire again after Rule1 fires
and update the fact that Rule2 is using a condition. While this may provide a correct result, giving
Rule1 a higher priority in this scenario will provide better performance.

Update calls
The Update function causes all the rules using the updated facts to be reevaluated. Update function
calls can be expensive especially if a large set of rules is reevaluated when updating facts. There are
situations where this behavior can be avoided. For example, consider the following rules:
Rule1:
IF PurchaseOrder.Amount > 5

THEN StatusObj.Flag = true; Update(StatusObj)

Rule2:
IF PurchaseOrder.Amount <= 5

THEN StatusObj.Flag = false; Update(StatusObj)

All remaining rules of the policy use StatusObj.Flag in their conditions. Therefore, when Update is
called on the StatusObj object, all rules will be reevaluated. Whatever the value of the Amount field is,
all rules except Rule1 or Rule2 are evaluated twice, once before the Update call and once after the
Update call.
To mitigate the associated overhead, you could set the value of the flag field to false prior to invoking
the policy and then use only Rule1 in the policy to set the flag. In this case, Update would be called
only if the value of the Amount field is greater than 5, and the Update function is not called if the value
of Amount is less than or equal to 5. Therefore, all the rules except Rule1 or Rule2 are evaluated twice
only if the value of the Amount field is greater than 5.

Usage of logical OR operators

Using an increasing number of logical OR operators in conditions creates additional permutations that
expand the analysis network of the rule engine. From a performance standpoint, you are better off
splitting the conditions into atomic rules that do not contain logical OR operators.

Caching settings
The Rule Engine uses two caches. The first one is used by the update service and the second one is
used by each BizTalk process. The first time a policy is used, the BizTalk process requests the policy
information from the update service. The update service retrieves the policy information from the rule
engine database, caches it and returns the information to the BizTalk process. The BizTalk process
creates a policy object based on that information and stores the policy object in a cache when the
associated rule engine instance completes execution of the policy. When the same policy is invoked
again, the BizTalk process reuses the policy object from the cache if one is available. Similarly, if
BizTalk process requests for the information about a policy from update service, the update service
looks for the policy information in its cache if it is available. The update service also checks if there
have been any updates to the policy in the database every 60 seconds. If there are any updates, the
update service retrieves the information and caches the updated information.
There are three tuning parameters for the rule engine related to these caches, CacheEntries,
CacheTimeout, and PollingInterval. You can specify the values for these parameters either in the
registry or in a configuration file. The value of the CacheEntries parameter is the maximum number of
entries in the cache and is set to a value of 32 by default. You may want to increase the value of the
CacheEntries parameter to improve performance in certain scenarios. For example, say you are using
40 policies repeatedly; you could to increase the value of the CacheEntries parameter to 40 to improve
performance. This would allow the update service to maintain cache details of up to 40 policies in
memory.
The value of CacheTimeout is the time in seconds that an entry is maintained in the update service
cache. In other words, the CacheTimeout value refers to how long a cache entry for a policy is
maintained in the cache without being referenced. The default value of CacheTimeout parameter is
3600 seconds, or 1 hour. It means that if the cache entry is not referenced within an hour, the entry is
deleted. In some cases, it may be beneficial to increase the value of the CacheTimeout parameter to
improve performance. For example if a policy is invoked every 2 hours performance of the policy
execution would be improved by increasing the CacheTimeout parameter to a value higher than 2
hours.
The PollingInterval parameter of the rule engine defines the time in seconds for the update service to
check the rule engine database for updates. The default value for the PollingInterval parameter is 60
seconds. If you know that the policies do not get updated at all or are updated rarely, you could change
this parameter to a higher value to improve performance.

SideEffects property
The ClassMemberBinding, DatabaseColumnBinding, and XmlDocumentFieldBinding classes
have a property named SideEffects. This property determines whether the value of the bound field,
member, or column is cached. The default value of the SideEffects property in the
DatabaseColumnBinding and XmlDocumentFieldBinding classes is false. The default value of the
SideEffects property in the ClassMemberBinding class is true. Therefore, when a field of an XML
document or a column of a database table is accessed for the second time or later within the policy, its
value is retrieved from the cache. However, when a member of a .NET object is accessed for the
second time or later, the value is retrieved from the .NET object, and not from the cache. Setting the
SideEffects property of a .NET ClassMemberBinding to false will improve performance because the
value of the field is retrieved from the cache from the second time onwards. You can only do this
programmatically. The Business Rule Composer tool does not expose the SideEffects property.

Instances and selectivity

The XmlDocumentBinding, ClassBinding, and DatabaseBinding classes have two properties:
Instances and Selectivity. The value of Instances is the expected number of instances of the class in
working memory. The value of Selectivity is the percentage of the class instances that will successfully
pass the rule conditions. The rule engine uses these values to optimize the condition evaluation so that
the fewest possible instances are used in condition evaluations first and then the remaining instances
are used. If you have prior knowledge of the number of instances of the object, setting the Instances
property to that value would improve performance. Similarly, if you have prior knowledge of the
percentage of these objects passing the conditions, setting the Selectivity property to that value would
improve performance. You can only set values for these parameters programmatically. The Business
Rule Composer tool does not expose them.

Performance metrics
This section describes performance metrics that should be evaluated when measuring the performance
of a BizTalk solution. This section provides pointers to existing documentation as a reference when
more information is needed for a specific performance object or counter that might be mentioned later
in this document.

BizTalk Server performance metrics

For a detailed description of the performance counters available in BizTalk Server and to get
information about counters mentioned in this document, see “Performance Counters” in the BizTalk
Server 2006 R2 help at http://go.microsoft.com/fwlink/?LinkID=104641.

SQL Server performance metrics

Because SQL Server performance is such an integral part of the overall performance of a BizTalk
Server solution it is important to have a thorough understanding of how to evaluate and troubleshoot
SQL Server performance. For more information on evaluating and maximizing the performance of the
SQL Server computers that host the BizTalk Server databases, see the following topics:
 SQL Server 2005 Waits and Queues at http://go.microsoft.com/fwlink/?LinkId=115110.
 Troubleshooting Performance Problems in SQL Server 2005 at http://go.microsoft.com/fwlink/?
LinkId=113794.
 How to troubleshoot SQL Server performance issues at http://support.microsoft.com/kb/298475.
 Tool for Performance Monitoring and Tuning in the SQL Server 2005 Books Online at
http://go.microsoft.com/fwlink/?LinkId=115111.
See Also
Optimizing Performance

Performance Tools
This topic provides information on tools you can use to evaluate the performance of a BizTalk Server
solution. The tools described in this topic have different purposes; some are designed to evaluate end-
to-end performance while others focus on evaluating performance of a particular aspect of a BizTalk
Server solution.

BizUnit 3.0 and BizUnit Designer

BizUnit is a framework designed for automated testing of BizTalk solutions. BizUnit is an excellent tool
for testing end-to-end BizTalk Server scenarios. Performing automated testing of BizTalk solutions with
BizUnit is the primary focus of the Automating Testing section of this guide. For more information about
BizUnit 3.0, see http://go.microsoft.com/fwlink/?LinkID=85168.
BizUnit Designer is a GUI that allows for rapid creation of BizUnit test cases that can be used for unit
testing or system testing distributed applications. The tool is available at http://go.microsoft.com/fwlink/?
LinkID=117917.

Important
As of the writing of this guide, the test cases generated by BizUnit Designer 1.x are only
compatible with BizUnit 2.x.

Note
Use of this tool is not supported by Microsoft, and Microsoft makes no guarantees about the
suitability of this programs. Use of this program is entirely at your own risk.

Performance Analysis of Logs (PAL)

The PAL tool is used to generate an HTML-based report that graphically charts important performance
counters and generates alerts when thresholds for these counters are exceeded. PAL is an excellent
tool for identifying bottlenecks in a BizTalk Server solution to facilitate the appropriate allocation of
resources when optimizing the performance of the solution.
For more information about the Performance Analysis of Logs (PAL) tool, see
http://go.microsoft.com/fwlink/?LinkID=98098.

SQLIO
The SQLIO tool was developed by Microsoft to evaluate the I/O capacity of a given configuration. As
the name of the tool implies, SQLIO is a valuable tool for measuring the impact of file system I/O on
SQL Server performance. SQLIO can be downloaded from http://go.microsoft.com/fwlink/?
LinkId=115176.

Microsoft BizTalk LoadGen 2007

BizTalk LoadGen 2007 is a load generation tool used to run performance and stress tests against
BizTalk Server.
For more information about the Microsoft BizTalk LoadGen 2007 tool, see
http://go.microsoft.com/fwlink/?LinkId=59841.

Visual Studio Team Suite Testing Tools

Available with Visual Studio 2005 as the "Performance Tools" feature in Visual Studio Team Suite. For
more information about the testing tools that are integrated into Visual Studio 2005 Team System, see
"Visual Studio 2005 Team System: Enabling Better Software Through Better Testing" at
http://go.microsoft.com/fwlink/?LinkId=102208.

Windows Server 2003 Performance Advisor

Windows Server 2003 Performance Advisor is a simple but robust tool that can help you diagnose the
root causes of performance problems in a Windows Server 2003 deployment. Server Performance
Advisor collects performance data and generates comprehensive diagnostic reports that give you the
data to help you analyze problems and develop corrective actions. The tool is available at
http://go.microsoft.com/fwlink/?LinkId=117918.

BizTalk Server Orchestration Profiler

The BizTalk Server Orchestration Profiler is used to view orchestration tracking data for a specified
period of time and is useful for determining where performance bottlenecks exist in orchestrations.
For more information about the BizTalk Server 2006 Orchestration Profiler, see
http://go.microsoft.com/fwlink/?LinkId=102209.

Note
Use of this tool is not supported by Microsoft, and Microsoft makes no guarantees about the
suitability of this programs. Use of this program is entirely at your own risk.

Phases of a Performance Assessment

One of the primary goals of BizTalk Server is to provide maximum flexibility for accommodating as
many processing scenarios as possible. Because of this great flexibility, one of the primary challenges
facing developers of a BizTalk solution is to determine how to make best use of the features available in
BizTalk Server to meet their business needs. This flexibility also poses a challenge when optimizing the
performance of a BizTalk Server solution.
This section describes the methodology that should be used to optimize the performance of a BizTalk
Server solution by engaging in a BizTalk Server performance assessment. A BizTalk Server
performance assessment is used to maximize the performance of a particular BizTalk Server solution.
In order to gain the maximum benefit from a BizTalk Server performance assessment, the performance
assessment should be divided into the following 5 distinct steps/phases:
1. Scope
2. Plan
3. Prepare
4. Build lab
5. Execute
This topic describes each of these phases in greater detail.
Phases of a BizTalk Server performance assessment
In This Section
 Phase 1: Scoping the Assessment
 Phase 2: Planning the Assessment
 Phase 3: Preparing for the Assessment
 Phase 4: Building the Assessment Environment
 Phase 5: Executing the Assessment

Phase 1: Scoping the Assessment

A common mistake when engaging in a performance assessment is to underestimate the scope of the
performance assessment. If sufficient resources and time are not allocated beforehand, then the team
responsible for the performance assessment will be unable to complete all of the tasks required to build
out and test a complex production-like environment. The team working on the performance assessment
should choose their battles carefully. Most performance assessments are performed within a very
limited timeframe and so the team should identify and focus on one or two, maybe three at most, key
performance objectives. The application to be tested should be specifically developed to focus on the
identified performance objectives and should factor out all other technology variables as much as
possible. This topic describes the aspects of the scope phase of a BizTalk Server performance
assessment.

Considerations before beginning the performance

assessment
The following factors should be considered before any other work is done for a performance
assessment. These factors will help decide the general direction of the scope phase and are a good
starting point for a performance assessment.

Message load
It’s important to consider right from the outset how you are going to replicate the message load that will
actually be going through the production system. For instance, if in production 20% of the messages
will be <20KB in size, 50% will be <100KB in size and the remaining 30% could be up to 1 MB in size, it
is important this is replicated in the lab.

Develop a brief detail of the scenarios to be tested

After you have identified the test cases that will be tested, it is important to identify the major
components that are involved in them. This includes both BizTalk Server components (messaging,
orchestration, etc) and other components, including third party technologies such as MQSeries or SAP.
It is very important that you are aware of all of these from the outset as it will help you gauge the
complexity of the lab and will enable you to plan for the technical skills required during the engagement.

Identify which adapters will be used

It is of vital importance the performance assessment lab uses the actual adapters that will be used in
the production environment. Failure to use the actual adapters used in production causes problems
because the performance of different adapters varies significantly. For instance, the file adapter is one
of the fastest BizTalk Server adapters but it lacks some of the features required of some systems, in
particular the file adapter does not provide support for transactions. Transaction support provides the
ability to read messages and write them to the MessageBox all within the context of an MSDTC
transaction. Transaction support incurs overhead and so using the File adapter to simulate a production
scenario that requires transaction support would not be an “apples to apples” comparison. In this
scenario the performance results are essentially invalid as they are very unlikely to reflect the actual
performance of the production system.

Estimate time required for the performance assessment

Use the following guidelines to estimate the time required for the performance assessment:
 Allocate two weeks of preparation time for setting up the testing environment. One week will be
used to build out the required infrastructure, software components, and apply software updates.
The second week will be dedicated to setting up the specific environment that duplicates the
BizTalk Server production environment.
 Allocate an additional week for each test case that will be analyzed during the performance
assessment.
 Allocate a week at the end of the actual performance assessment to document the findings of the
performance assessment.
So for a typical performance assessment with 2 test cases, the estimated time to complete the
assessment would be:
(2 weeks of preparation time) + (2 weeks for the actual performance assessment) + (1 week to
document findings) = 5 weeks total.

Documenting the performance assessment

As part of scoping the performance assessment the details of the assessment should be documented in
an engagement summary. This document should clearly define goals and objectives, stakeholders, and
milestones for the performance assessment. This document will serve as a roadmap for the
performance assessment, help ensure all stakeholders agree on the engagement details and serve to
ensure the performance assessment stays on track. This document should be updated throughout the
performance assessment and include a summary of results upon the conclusion of the performance
assessment.
What performance criteria are you trying to maximize? Typically one or more of the following
performance measures are the focus of a BizTalk Server performance assessment:

Goals and objectives

Carefully define throughput and latency goals - What performance criteria are you trying to
maximize? Typically one or more of the following performance measures are the focus of a BizTalk
Server performance assessment:
 Throughput – Typically measured as the number of messages per time unit that can be processed
over a specified time interval. For example, a throughput goal might be defined as the ability to
process 100 messages per second for a period of 3 hours.
 Latency – Usually defined as percentage of all messages that can be processed end-to-end within
a given time interval, for example:
 95% of all messages should be processed end-to-end within 2 seconds.
 100% of all messages should be processed end-to-end within 4 seconds.
 Peak loads
 Time to complete a batch of X
 Floodgate recovery scenarios
 High-level architecture including hardware and software
Performance goals should be measured in terms of “achieve highest possible X given hardware and
software constraints.” Determine how the goal will be measured in advance. For example, “Maximum
Sustainable Throughput of X end-to-end as measured by the counter ’XLang/s\orchestrations
completed / second’”.

Note
In the examples above, X is placeholder for the unit that is the focus of the performance
assessment. X could represent orchestrations, messages, or other performance metrics that
are relevant to the BizTalk solution.

Is the desired performance attainable?

When evaluating performance considerations, you should first determine if the available hardware
resources will be sufficient for meeting your performance goals. In some cases, the desired
performance is simply not possible without additional investment in hardware. There is no magic
formula that can be used to determine what performance is or is not possible given a specific hardware
configuration as many factors influence the performance of the solution, including the complexity of
orchestrations, custom code that is used, number of times that messages are persisted to the
MessageBox database, and limitations of external systems. The table below provides a summary of
hardware used to achieve specific performance goals for certain scenarios.
 Note
The information below is provided for guidance only. The requirements of different BizTalk
Server solution vary greatly so the values in this table should be used as a rough “rule of
thumb” when estimating required hardware resources.

Sample hardware scenarios

Type of Processing BizTalk Server SQL Server Throughput Notes
computers computers attained

Orchestration  6 BizTalk  3 SQL Server 95 orchestrations  Average

exposed as a Web Server 2006 2005 per second latency 1.11s
service, MQSeries computers computers  99%
adapter  Each server  Each server messages
running two running four processed with
3GHZ dual 3GHZ dual <2 seconds
core core latency
processors processors
 Windows  64 bit, 16 GB
Server 2003, memory
32 bit, 4GB  Single
memory Messagebox
database
Messaging 6 BizTalk Server 3 SQL Server Peak throughput Before optimizing
2006 computers 2005 computers attained over a 2 solution, peak
hour period was throughput was
277 messages per 125 messages per
second second
Low-latency One dual One quad 60 orchestrations < 350 millisecond
scenario using processor processor SQL per second latency achieved
orchestrations and BizTalk Server Server 2005
Web services 2006 computer computer
Low-latency 23 Quad  3 SQL Server 1156 As of January
scenario using processor 2005 orchestrations per 2008 was the
orchestrations BizTalk Server computers second highest
2006 computers  One 16-CPU sustainable
master performance of
Messagebox BizTalk Server
database running
orchestrations
 Two 8-CPU
recorded
secondary
Messagebox
database
computers
After the available hardware infrastructure is deemed sufficient to achieve the desired performance,
then consider the following when scoping a BizTalk Server performance assessment:
 Which adapters and/or accelerators are required?
 What are the requirements for implementing orchestrations in the solution?
 Document throughput requirements: What are the maximum sustainable throughput requirements
for the solution?
 Latency requirements: How responsive does the solution need to be for solicit-response and
request-response scenarios?
 How well does the solution recover from periods of peak document load?
 What are the high availability requirements of the solution?
 What are the document tracking requirements of the solution?
 What are the performance characteristics of any dependent applications such as a remote Web
service or other system? If dependent applications do not keep up with the required load, then the
overall system performance will be degraded accordingly.

Hardware information to consider during scope phase

When scoping the solution, create a high-level hardware diagram that includes the following:
 Computer architecture (such as x86, x64, and IA64)
 CPU requirements (such as type, speed, number, cores, and use of hyperthreading)
 RAM requirements for each computer
 Local disk storage (type, size, speed)
 SAN (storage requirements: number of LUNS; SAN card type)
 Network cards (number in each computer, 100 megabits (Mbps) versus 1 Gigabit (1 Gbps).)
 How will firewalls be deployed in the solution?
 Will Network Load Balancing hardware be used?
 Are specific computers to be clustered?

Software information to consider during the scope phase

Equally important as the hardware information is the software stack that will be used during the
performance assessment. You should ensure you document the following information:
 Operating system for each computer ( 32 or 64 bit, clustered or not).
 Server software to be installed on each computer.
 Virtualization software used.
 Specific software features not typically installed such as COM+ rollup fixes or SQL Server host fixes
that are required.
Determine if code changes are within the scope of the performance
assessment
This is one of the most important things to determine during the scoping process. BizTalk Server and
the underlying components it uses (SQL Server, Windows, IIS and many more) can be optimized using
the tuning techniques and configuration changes discussed in this guide. However, if an application has
not been developed for optimal performance, it can hamper these performance gains. Therefore, code
changes should only be removed from the scope if you have confidence a thorough code review has
been completed before the application enters the lab. If necessary, you may agree that only certain
changes be allowed, for example, the removal of persistence points within orchestrations.

Roles and responsibilities

One of the most important areas of running a performance assessment is to ensure the roles and
responsibilities are clearly assigned. The following key roles should be assigned at the onset of the
performance assessment:
Engagement lead - The engagement lead is responsible for owning the overall engagement end-to-
end. This role will typically be performed by a Senior Consultant or Architect. Ideally this person
should have experience in tuning BizTalk Server based systems. Knowledge of SQL Server and
any other technologies including third party ones is desirable. Please note it is not necessary that
the lead is an expert in all areas, but they need to have at least a working knowledge of the
technology in order that they can work with the specialists in those areas and understand the
optimizations that they are applying.
Test designer - It is necessary to have someone who is dedicated to designing and implementing the
tests that will be executed during the lab. This will involve deciding on the test framework that will
be used to create tests, testing each of the tests to ensure that it will fulfill the requirements of the
lab and ensuring that those responsible for running the tests are aware of how to use the client.
Environment owner - Having a representative environment within the lab that accurately reflects the
production BizTalk Server environment is critical. The person performing this role will be
responsible for checking each item of the software and hardware stack used and validating that
there are no significant differences. For example SQL Server 2005 when running on the 32-bit
platform can only address 4GB of physical memory without using either Physical Address
Extensions (PAE) or Address Windowing Extensions (AWE). In SQL Server 2005, 64-bit up to 1
terabyte of memory can be addressed (this is the current maximum physical memory supported by
Windows 2003 SP1). Therefore a significant difference between the customer and the lab
environment would be the architecture of CPU used by BizTalk Server and SQL Server. In addition
to these obvious factors, other less obvious factors, such as service pack levels and hotfixes
installed, can impact performance of the environment.
Build environment lead - After a detailed specification has been drawn up for the performance
assessment, someone should be assigned the responsibility of building the environment. This will
include the hardware and software stack. In many cases one individual will be responsible for this
(this is often the environment owner). However in a large enterprise the environment owner may
 need to be the liaison between different teams, who may each be responsible for various
components of the solution. For example, one team may be responsible for the Windows build,
another for SQL Server, and yet another team for BizTalk Server.
Deployment lead - It is necessary to have someone responsible for ensuring that the application is
deployed correctly to BizTalk Server, that the correct bindings are configured and that any custom
configuration is applied. This role will require a thorough knowledge of the solution and will require
the knowledge to package an application and deploy an application and then validate that it is in a
functioning state within the lab environment.
Product specialists – It is important to identify what product specialists are required for the
performance assessment. The exact skills required depend upon the design and purpose of the
BizTalk Server application.
One of the most common product specialist skills required is extensive knowledge of performance
tuning SQL Server. These skills are required for two purposes: first, it is often necessary to perform
SQL Server optimizations to optimize performance of the BizTalk databases and second, many
BizTalk solutions make use of custom databases. The use of custom databases can become a
bottleneck in the solution if the correct optimizations are not applied to the SQL Server
environment. In order to identify and apply the appropriate database optimizations, the following
SQL Server skills are typically required:
 Thorough understanding of SQL Server stored procedure code, including the ability to optimize
existing stored procedures.
 Ability to identify and build missing database indexes.
 Ability to write scripts to split databases into multiple files.

Note
For more information on applying this optimization, see Optimizing Filegroups for the
Databases.
 Ability to identify performance problems using SQL Server 2005 Performance Dashboard
Reports.

Note
SQL Server 2005 Performance Dashboard Reports is available for download at
http://go.microsoft.com/fwlink/?LinkId=118673.
For each specialist technology involved in the performance assessment, a list of requirements
should be defined as is done above for SQL Server. This ensures the resource obtained has clear
expectations of what will be required of them. Another technology that frequently requires
specialized knowledge during the performance assessment is IBM Websphere MQ. The list below
illustrates the requirements specification for an IBM WebSphere MQ product specialist:
 Experience in the monitoring, maintenance, and customization of MQSeries.
 Experience with installation and migration of new versions of MQSeries.
 Ability to analyze and tune MQSeries performance.
 Perform MQSeries problem analysis.
  Knowledge of the processes and procedures related to MQSeries security, administration,
recovery and automation.
Documentation lead - Continuously updating the lab documentation end-to-end throughout the
performance assessment is vitally important. The overall successfulness of a lab engagement
should not be judged until the optimizations have successfully been applied in the production
environment and the system has obtained the desired level of performance. In order to do this, it is
essential that a detailed record of the following information is kept:
 High-level results summary of the lab
 Unresolved issues
 Resolved issues
 Timeline for the lab
 Lab progress
 Implemented optimizations by category
 Implemented optimizations in chronological order (to ensure that they can be applied in the
same order in the production system)
 High-level architectural diagram
 Detail of the scenarios to be tested
 Third party technologies involved
 Lab hardware diagram
 Contact list
 Detailed hardware inventory
 Appendix with full detailed results
Developer - Whether a developer is required depends very much on the scope of the engagement. If
the code base has been locked down and the lab is there to test infrastructure and platform
optimizations only then the services of a developer should not be required. This type of scenario
can occur when performance testing is performed just before the “go-live” date of the production
server. By this time, the code should have been locked down and full regression testing should be
complete or in progress. Any changes to the code introduced in the lab could introduce a regression
and, therefore, introduce risk to the production system. If code changes are permitted, then typically
a developer will be required. The list below represents the skills typically required by a developer
that is engaged in a BizTalk Server performance assessment:
 Ability to identify and fix performance issues with orchestrations
 Ability to identify and fix performance issues with pipelines
 Familiarity with .NET including:
 Enterprise library
 Visual Studio F1 profiler expertise
 Visual Studio 2005 Team System
Test lead - Ensuring an accurate, complete and thorough set of results is obtained is critical. The test
lead is responsible for ensuring the required information is captured, analyzed appropriately, and
distributed appropriately after every test run. It is important to consider how to capture the data,
typically the test data is suitable for presentation using an Excel spreadsheet. The following list
illustrates the data that should be captured for each test that is run during the lab:
 Test run number
 Date
 Total messages processed
 Messages processed per second
 Time started
 Time stopped
 Test duration in minutes
 Suspended messages / Total messages processed – This can be captured either from the
BizTalk Administration console or by measuring the BizTalk Server performance counters using
Performance Monitor.
 # of messages that have failed processing
 # or message that have been successfully processed
 Test client responses
 Client process duration average, measured in seconds - Typically this value is measured when
implementing a synchronous messaging solution with BizTalk Server, in this case it is important
to know the value for average client duration as this is typically representative of how long an
end user is waiting for a response from the solution.
 Client process duration maximum value, measured in seconds
 Client process duration minimum value, measured in seconds
 BizTalk Server request/response latency, measured in seconds
 Orchestrations completed per second
 % of messages processed on time
 Value of TestResultsLocation variable used by Visual Studio Team System testing tools.
 Value of TestResultsLocation variable used by BizUnit.
 Any comments or recommendations
As well as collecting the results, the test lead should ensure that they monitor each test run to see if
there are any trends. Performance improvements should be communicated to the rest of the team
and should indicate how much performance was improved and which optimization was applied to
achieve the improvement. At the end of day it is important that the test lead provides a summary of
the tests that have been performed in the lab. This allows the stakeholders to be kept informed of
the continued progress of the lab. The table below illustrates how this information might be put
together in a sample update e-mail:
 Test results summary
Status Throughput Averag %< 2 # of # of # of Averag Duratio
e second Tes BizTalk Message e n
Latenc s t Server s Messag
y run Compute e Size
s rs

Scale 140 0.777 99.3% 2 6 270,000 609 30

out messages/seco second bytes minute
nd s s
Best 50 1.12 99.12 17 2 360,000 609 2
messages/seco second % bytes hours
nd s
Baselin 30 1.52 92.9 % 4 2 36,000 609 20
e messages/seco second bytes minute
nd s s
Goals 5 <2 90% - 2 - - -
messages/seco second
nd s

Define all deliverables that are required at the onset

of the performance assessment
It is important to agree upon deliverables that must be in place before embarking on a BizTalk Server
performance assessment. The section below describes the deliverables that should be in place at the
onset of the performance assessment.
Application to be tested – The complete application that will be used during the performance
assessment must be available. It is important that the application is in a fully functioning state
before beginning the performance assessment, otherwise there is risk of losing valuable lab testing
time.
Planning for automated build and deployment - Before engaging in the performance assessment,
an automated build and deployment process should be developed for the BizTalk Server solution to
be tested. Automating the build process for an application enables you to do a continuous daily
build process, which can then be accompanied by a set of build validation tests (BVTs) which test
the functional flows through the system. This enables you to detect compilation and functional
problems quicker and easier throughout the development lifecycle. Within the lab, this means that if
any code changes are required you can quickly verify that the updated solution works without
problems. Manually building, deploying and configuring an application for a performance lab can be
a tedious and error prone task. Therefore it is recommended that an automation technique be used
to accomplish the following build and deployment activities:
 Get latest code from source control.
 Build the complete solution.
  Deploy the solution to the environment.
 Create BizTalk applications.
 Add BizTalk Server resources such as .dll files and bindings to BizTalk applications.
 Import binding file to create ports and bind to orchestrations.
 Export BizTalk applications as a Microsoft® Windows® Installer package so that it can be
deployed in the testing or production environment.

Note
For more information about implementing an automated build process, see Automating the
Build Process.
MSBuild was introduced with the .NET framework 2.0 to enable developers to automate task such
as those described above. Several BizTalk Server specific MSBuild tasks are included with the SDC
Tasks library which is available for download from http://go.microsoft.com/fwlink/?LinkId=119288.
Test data to be used during the performance assessment – The test data that is used has a
considerable influence on the overall effectiveness and success of a performance assessment.
Consider the scenario where a BizTalk Server application utilizes messaging, orchestration and the
Rules Engine. The Rules Engine is called from within a pipeline component on the receive side to
determine which orchestration will be used to process the message; and it is also called from within
the orchestration at various points to determine flow. The Rules Engine implements caching so that
rules policy execution is optimized. Therefore, if a single message is used as test data during the
performance assessment, test results may be skewed (due to caching) and you may obtain results
that can’t be replicated in production.
Ideally the test data used during the performance assessment should be actual production data or a
subset of production data. The test data should also simulate the load and pattern of traffic that will
be flowing through the production system. Consider the following factors when defining
requirements for test data:
 Number of messages that will be flowing through the system in a given period - This is
normally expressed as messages per second or messages per hour.
 Types of messages – Are the messages flat file, XML, or binary?
 Distribution of messages – What percentage will be flat file, what percentage of each XML
message type will be used?
 Peak load processing requirements - In many scenarios a large interchange may be
processed during non-peak hours. For example a large batch of payments may be posted to a
bank’s systems at midnight. If this is the case, ensure you are able to replicate this during
testing.
 Endpoints used to receive/send messages - In many environments separate receive
locations are configured to receive different types of messages. For example flat file messages
may be received using the File adapter or the MQSeries adapter may be used to receive XML
messages. While messages may all be processed by the same orchestration(s) they will have
 different entry points into the system. Each of these different receive locations can be hosted in
a separate host; in fact doing this will often improve the overall performance of the system.
The table below provides an example of the information that should be captured when determining
test data specifications:

Sample test data specification

Messages per second  Maximum throughput is key in this
scenario
 Goal of 50 messages per second
 Low-latency is not a goal
Type of messages  Small XML messages, approximately 25
KB that conform to XML schema X
 Medium XML messages, approximately
512 KB that conform to XML schema Y
Distribution of messages  58% 25 KB (small XML messages)
 25% 512 KB (medium XML messages)
 11% 3 MB (medium binary data – PDF) –
non compressible
 4% 7.5 MB (large binary data – PDF) –
non compressible)
 2% 20 MB (large binary data – PDF) –
non compressible
Peak load processing requirements Large binary data (20MB) will represent
approximately 2% of data (as specified above)
the time at which this is processed is non-
predictable. The system must be able to
accommodate these large messages at any
given time.
Endpoints used to receive/send messages Small XML messages (25 KB)
 Receive location: PaymentXMLDocIn
 Host: ReceiveHost
 Pipeline used: XMLReceive
Medium XML messages (512 KB)
 Receive location: PaymentXMLDocIn
 Host: ReceiveHost
 Pipeline used: XMLReceive
Medium binary data (3 MB) – PDF – non
compressible
 Receive location: BinaryDataIn
 Host: ReceiveHost
 Pipeline used: PassThruReceive
 Large binary data (7.5 MB – 20 MB) – PDF –
non compressible
 Receive location: BinaryDataIn
 Host: ReceiveHost
 Pipeline used: PassThruReceive
Location of test data Locally accessible test data file share, for
example: \\PerformanceLabs\July\Test Data\

Putting the information into a table accomplishes several things. First off, it makes it easier for
stakeholders to agree on assumptions made about the test data. Second, it provides you with
information that can be used to decide on potential optimizations for the performance assessment.
For example in the table above you can see that all the receive locations used to process all
different data types are hosted within the ReceiveHost BizTalk host. This means that each instance
of this host will be responsible for processing different types and sizes of data (e.g. XML and binary
non-compressible PDF data). Given that each host instance is a single instance of the BizTalk
Server process (BTSNTSVC.EXE), this could become a processing bottleneck. Therefore in this
scenario one immediately obvious optimization for the environment would be to test the
performance improvement of separating each receive location into its own individual host. Having
access to the test data information in a summary tabular format makes it easier to gauge simple
optimizations such as this.
Planning for automated load tests and load generation - After the test data profile for the
performance assessment is established, it is important to consider how to perform load testing
within the environment. The BizTalk Server product group has developed the BizTalk LoadGen
2007 tool (LoadGen) to quickly, easily and reliably define load tests that simulate production level
message volumes. LoadGen is multi-threaded, configuration driven and supports multiple
transports. Because LoadGen was designed by and is used by the BizTalk Server product group it
should be the tool of choice for simulating load during the performance assessment. For more
information about automating load testing using LoadGen, see Automating Performance and
Stability Testing.

Phase 2: Planning the Assessment

The Plan phase of a performance assessment is largely comprised of setting up specific milestones for
the completion of the deliverables identified during the Scope phase. The Plan phase is the “when” to
the Scope phase’s “what.” Third-party software and physical logistics are “how” and “where” aspects
that should also be considered during the planning phase as these aspects may require additional lead
time to implement.
This topic describes the various aspects of the Plan phase of a performance assessment.
Solution milestones timeline
It is important to have a clear and concise record of the milestones for the performance assessment.
Setting specific milestones will increase the likelihood that the solution will be completed in a timely
manner. Consider creating a Visio timeline to visually represent dates, milestones, and tasks associated
with the performance assessment. Keep the timeline simple enough to be easily understood yet
detailed enough to communicate milestones effectively. The actual milestones should be agreed upon
by all stakeholders and reviewed regularly. A sample Visio timeline is displayed below:

Sample performance assessment Visio timeline

Note
For more information about how to create a timeline using Visio 2007, see the article “Create
project timelines in Visio 2007” at http://go.microsoft.com/fwlink/?LinkId=119395.
The table below summarizes the deliverables and other details associated with the milestones in the
figure above.

Milestone Deliverables Other Details

Lab planning call Begin documentation Confirm objectives defined during

scoping, assign dates to
deliverables to create task and
milestones.
Lab request Hardware/software diagram and The hardware/software diagram
specification and specification is required by
the lab team to procure and build
the hardware to the designated
software specification.
 Lab hardware available Lab hardware should now be For illustration purposes, it has
accessible to all stakeholders. been assumed that a system
build team is available to build
out the lab. In reality this may not
be the case and responsibility for
building out the lab hardware
may rest upon one or more of the
members of the team
participating in the performance
assessment.
BizTalk Server environment  BizTalk Server should be fully
ready deployed and configured.
 The BizTalk Server
application to be tested
should be fully deployed.
Functional validation of All functional flows through the Ideally this will be done using
solution completed system should be tested at this automated functional testing so
point. that this process can be easily
repeated as required.
Lab scheduled to conclude  Performance goals should be
met at this point
 Documentation should be up
to date with all optimization
and configuration settings
that have been applied so far.
Performance assessment Final lab report is delivered
document summary completed

Non-Microsoft software considerations

It’s a good practice to be very clear from the beginning about what stakeholders will provide the needed
expertise for any third-party software that will be used during the performance assessment. Consider
the following when non-Microsoft software will be used with the solution:
 Determine how the software or hardware required be obtained.
 Plan for capacity and sizing to ensure that non-Microsoft software does not become a bottleneck in
your solution.
 Determine a plan of action for installing required non-Microsoft software.
 Create a plan of action for configuring and optimizing required non-Microsoft software.
Physical space and other logistics
Physical space is an important detail to consider during the planning phase. In order to conduct a lab,
computers need to exist where they can be accessed and the participants will need space to work and
hold discussions. The participants will also benefit from additional space where phone conferences may
be held in a less public forum.
One of the most important aspects of the physical environment for the lab is to create an environment
where all participants can comfortably see the same set of screens. This can be accomplished by using
overhead projectors through which the team can view remote desktop sessions used during the lab or
by shadowing sessions using the “shadow” feature of remote desktop.
Performance assessment engagements may yield unexpected problems, which will only be
compounded by the fact that the engagement is typically on a tight schedule. Because of the
sometimes lengthy working days that are required to meet milestones, physical space logistics will
become important to the success of the engagement.
In summary, the following factors should be considered when planning the physical space required for
the performance assessment:
 Lab computers must be accessible to team members.
 Team members will need space to hold discussions during the lab.
 Team members should have access to visual media that allows all members to see the same set of
screens, typically either an overhead projector tied to a remote desktop screen or by using the
“shadow” feature of remote desktop.
 Team members should have access to a “whiteboard area” which will be used to facilitate
discussions during the lab.
 Team members should have access to space where phone conferences can be held in a less public
forum.
 If possible, the lab area should be climate controlled during extended hours, this will accommodate
off hours access if required.
 Everyone will likely still need to communicate with their day jobs, so allow enough table space for
both client computers and personal laptops, 2 for each participant.
 Ensure that enough power strips and network connections are available in the lab. If wireless is
used, arrange guest access for participants.
 Ensure that the lab environment will be secure during off hours.

Phase 3: Preparing for the Assessment

The Prepare phase of a performance assessment can be thought of as the “how” to the Scope phase’s
“what” and the Plan phase’s “when.” At this point in the performance assessment, all stakeholders
should have agreed upon the scope of the engagement and the plans for conducting the lab. It is in the
Prepare phase of the performance assessment where the plans are executed and steps are taken to
get ready for execution of the performance lab.
This topic describes the various aspects of the Prepare phase of a BizTalk Server performance
assessment.

Detailed design of the solution platform

A detailed solution design facilitates communications and avoids assumptions, which will improve the
agility and effectiveness of all activities. You should fully document the following elements:
 BizTalk Server databases and how they will be distributed across computers - SQL Server
performance is one of the key factors in overall BizTalk Server performance. If SQL Server is
experiencing resource constraints, this will impact the ability of BizTalk Server to process
messages. The main factor that influences BizTalk database performance is the speed of disks that
they are hosted on. Separating the transaction log and database files for each BizTalk database
onto separate drives or SAN LUN’s has been shown to remarkably improve the overall performance
of BizTalk Server. Therefore, it is important that this information is recorded in an easily accessible
manner. The values that will be used in the production environment should be documented in the
detailed solution design. The table below provides an example of how this can be done.
 BizTalk Database Volume Name Files LUN# or Physical LUN
ML_# Size (GB)

MessageBox Data_TempDb_1 TEMPDB, MASTER, 1 134

and MSDB data files
Logs_TempDb_1 TEMPDB, MASTER, 2 134
and MSDB transaction
log files
Data_BtsMsgBox BizTalkMsgBoxDb data 3 134
file
Logs_BtsMsgBox BizTalkMsgBoxDb 4 134
transaction log file
BAM Data_TempDb_2 TEMPDB, MASTER, and 5 67
MSDB data files
Logs_TempDb_2 TEMPDB, MASTER, and 6 67
MSDB transaction log
files
Data_BAM BAMPrimaryImport data 7 134
file
Logs_BAM BAMPrimaryImport 8 134
transaction log file
BizTalk Tracking, Data_TempDb_3 TEMPDB, MASTER, 9 67
Management, MSDB, BizTalkDTADb,
Single Sign-On, BizTalkMgmtDb,
and Rule Engine ENTSSO, and
databases BizTalkRuleEngineDb
data files
Logs_TempDb_3 TEMPDB, MASTER, 10 67
MSDB, BizTalkDTADb,
BizTalkMgmtDb,
ENTSSO, and
BizTalkRuleEngineDb
transaction log files

 BizTalk Host design and descriptions of each host and their instances.
 Description of each orchestration.
 Description of each pipeline.
 Description of custom components such as .NET assemblies and COM+ components.
Detailed architecture diagram
The diagram below illustrates an architecture diagram that could be used for a performance
assessment.

BizTalk Architecture Diagram

Message flow diagrams

Create detailed message flow diagrams to help avoid any confusion or false assumptions regarding
what is supposed to be happening to messages during processing.
When thinking about a BizTalk solution holistically, we tend to think of the message flow through the
system. This Message Flow perspective is especially important when doing performance testing
because all parts of the flow must be considered as potential bottlenecks. Having a message flow
diagram avoids any confusion or false assumptions regarding what is supposed to be happening to
messages during each test run.
In the example below, created using simple Visio shapes, everyone on the project regardless of
background can quickly understand how a message gets into the system, what parts of the solutions
interact with the message, and finally where the message lands after processing.
Message Flow Diagram

The following details should be considered when creating the message flow diagram(s):
 Describe the lifecycle of each type of message from the time it arrives at a receive location until all
resulting messages are sent and all related processing is completed.
 Describe how processing changes for error conditions.
 Include details about correlation, delivery notifications, and acknowledgements.
 Include details about dependence on external systems.
 Include performance requirement information regarding latency and throughput.

Third-party software details

All non-Microsoft software that is used should be fully documented as part of the detailed solution
design.

Detailed lab hardware stack

Building on the previously created high-level hardware diagram, the following hardware information
should be fully documented:
 Processors
 Type
 Speed
 Number of cores
 Hyperthreading
 Memory
 Amount
 Speed
 Parity
 Network
 Number of network interface cards (NICs)
  Speed of network
 SAN
 Number of SAN cards in each computer
 Number of logical unit numbers (LUNs) for each computer and purpose for each LUN
 Speed of storage area network (SAN) Cards
 SAN card configuration details
 SAN disk allocation, formatting, and partitioning
 Disk
 Local disk details for each computer
 Formatting used for local disks
 Partitioning details for local disks
 Cache
 L2 Cache amount
 L3 Cache amount

Detailed lab software stack

The following software information should be documented:
 Specific operating system versions, editions, and architecture
 Specific operating system features
 Specific software installed on each computer
 Specific drivers
 Service Packs and other updates
 Configuration values for all software and operating system features used if they vary from default
values

Phase 4: Building the Assessment

Environment
The Build lab phase of a performance assessment is used to install the hardware and software for the
environment in conformance to the design decisions made in previous phases. Because the Build lab
phase can be time consuming, it is not unusual for this phase to overlap earlier phases. In many
scenarios, the hardware and operating system may be installed before a final decision has been made
as to the application architecture. The Build lab phase of a performance assessment typically includes
the following aspects:
Obtain all build-lab infrastructure at least a week in
advance of the lab start date
Plan to have available all of the required hardware and software at least a week before the lab start
date. This will ensure that valuable lab time is not wasted for want of the required infrastructure.

Configure third-party software systems

There may be third-party systems that need to be built out and configured before the lab can begin. If
subject matter experts (SMEs) are required for these systems, be sure they are scheduled during the
build-out and lab execution stages. Ensure that they thoroughly document their build-out procedures.

Install and configure the BizTalk Server environment

Detailed instructions for installing BizTalk Server and the required dependency software can be found in
the BizTalk Server 2006 R2 installation guides available at http://go.microsoft.com/fwlink/?
LinkID=81041. After successfully installing and configuring the BizTalk Server environment, complete
the following tasks:
 Follow the recommendations listed in the Operational Readiness Checklists at
http://go.microsoft.com/fwlink/?LinkId=120082.
 Follow the recommendations in Optimizing Performance.
 Ensure all computer times are properly synchronized.
 Verify MSDTC functionality between all computers in the environment.
 Ensure any custom tracing/logging is disabled unless absolutely needed.
 Install the BizTalk LoadGen 2007 tool (LoadGen) on all BizTalk Server computers. For more
information about the Microsoft BizTalk LoadGen 2007 tool, see http://go.microsoft.com/fwlink/?
LinkId=59841.
 Setup Performance Monitor counters and logs, as needed.
 Setup a debugging computer to debug the solution if code changes are within the scope of the
performance assessment.
 Defragment all hard drives.
 Disable antivirus real time scanning.
 Back up the Enterprise Single Sign-On Master Secret.

Install the BizTalk Server application to be tested

Installation of the application to be tested will typically include the following steps:
1. Use the BizTalk Server Administration console to do the following:
 Create Hosts
  Create Send/Receive Handlers.
 Create Host instances.
 Create BizTalk Server Applications.
2. Application installation:
a. Deploy BizTalk Server binaries to the BizTalk Server group.
b. Import bindings to the BizTalk Server group.
c. GAC BizTalk Server and non-BizTalk Server binaries on all boxes.
d. Ensure dependency components exist on all boxes.
3. Install dependency applications.
4. Configure transports and physical endpoints in the BizTalk Server Administration console.
5. Start services.
6. Perform basic smoke tests – Smoke tests are end-to-end functional tests that test the basic
functionality of your solution.

Implement automated build and load testing

Implementation of an automated build and load testing process is arguably the cornerstone of a BizTalk
Server performance assessment. An automated build process should be implemented if code changes
are within the scope of the performance assessment. Automated load testing should be implemented
for all load testing scenarios. The initial time investment required to implement automated build and
load testing is quickly recouped, automation accommodates rapid and precise repetition of mundane
build/testing tasks that are subject to human error. For more information about implementing an
automated build and testing process, see the Automating Testing in this guide.

Configure performance monitoring

Accurate performance monitoring is critical to the success of the performance assessment. Determine
which performance metrics should be evaluated based on the throughput and latency goals that were
defined in the Scope phase. Performance monitoring should be performed on each computer in the
BizTalk Server environment. For more information about the performance counters available for BizTalk
Server 2006, see “Performance Counters” in the BizTalk Server 2006 R2 Help at
http://go.microsoft.com/fwlink/?LinkId=120120. Use the Performance Analysis of Logs tool (PAL) to
generate HTML reports that graphically chart important performance counters and generate alerts when
thresholds for these counters are exceeded. For more information about the Performance Analysis of
Logs (PAL) tool, see http://go.microsoft.com/fwlink/?LinkID=98098.
Establish and document the solution’s baseline
performance
Baseline performance should be calculated so that the effect of performance optimizations applied
during the performance assessment can be measured.

Phase 5: Executing the Assessment

The Execute phase is where the performance data is generated through automated load testing and
where performance bottlenecks are discovered and addressed. This phase has an iterative process
whereby performance bottlenecks are reduced or eliminated by testing, evaluating performance,
optimizing, and testing again.
This topic describes the steps that are typically followed during the Execute phase of a BizTalk Server
performance assessment:

Step 1: Run automated tests

Begin the Execute phase by running automated tests. A BizTalk Server performance assessment
typically focuses on throughput and/or latency testing but may include build verification and functional
tests. For comprehensive information about running automated testing, see Automating Testing.

Step 2: Document and evaluate test results

At the conclusion of each test, thoroughly document the test results and evaluate whether the stated
performance goals have been met.

Step 3: Modify the configuration of BizTalk Server,

third-party systems, or solution artifacts to tune for
performance based on the test results
Use the test results to make decisions about how to optimize the environment to reach stated
throughput or latency goals.

Step 4: Record all changes made to the environment

Ensure that any changes made to the environment are thoroughly documented. A record of the
changes will allow you to easily apply the changes in the production environment and will accommodate
the undoing of changes if need be.
Step 5: Repeat this cycle until goals are achieved
Continue the cycle of testing, evaluating and documenting results, optimizing the environment, and
documenting changes to the environment until the desired performance goals are reached.

Step 6: Summarize test results at the end of each day

Complete an “executive summary” of the test results and progress made at the end of each day.
Compile an e-mail that contains the summary and send to all stakeholders in the performance
assessment to keep everyone informed of progress that is being made.

Step 7: Update the project plan as timeline goals are

met
The timeline developed in the Plan phase is a good reference for the overall progress of the
performance assessment. Update this timeline as necessary to communicate the progress to all
stakeholders.

Finding and Eliminating Bottlenecks

A successful BizTalk Server performance assessment is largely a matter of discovering the existence of
and then resolving bottlenecks to accommodate either more throughput or reduced latency. This section
describes various types of performance bottlenecks as they relate to BizTalk Server solutions and
information about how to resolve the bottlenecks.

In This Section
 Best Practices for Avoiding Bottlenecks
 Investigating Bottlenecks
 System Level Bottlenecks
 Bottlenecks in the BizTalk Server Tier
 Bottlenecks in the Database Tier

Best Practices for Avoiding Bottlenecks

While the default settings in BizTalk Server 2006 provide optimal performance for many hardware and
software configurations, in some scenarios it may be beneficial to modify the settings or deployment
configuration. When configuring BizTalk Server 2006, consider the following performance guidelines:
 To prevent resource contention, isolate receiving, orchestration, and sending on separate hosts. To
further minimize contention, isolate the tracking service from other hosts.
 If CPU processing on the BizTalk Server is the bottleneck, scale up the BizTalk Server by including
additional CPUs or upgrading to faster CPUs.

SQL Server Guidelines

Consider the following performance guidelines when configuring Microsoft SQL Server™ with BizTalk
Server 2006:
 Whenever possible, use a fast disk subsystem with SQL Server. Use a redundant array of
independent disks type 10 (RAID10/0+1) or a storage area network (SAN) with backup power
supply.
 Isolate each MessageBox database on a separate server from the BizTalk Tracking database
(BizTalkDTADb). For smaller deployments if CPU resources are available, it might be sufficient to
isolate the MessageBox database on a separate physical disk from the BizTalk Tracking database.
 The primary MessageBox database could be the bottleneck due to CPU processor saturation or
latency from disk operations (average disk queue length). If CPU processing is the bottleneck, add
CPU processors to the primary MessageBbox. If not, try to disable publishing on the master
MessageBox database. This way the master MessageBox database can more efficiently handle
routing of messages to the other MessageBox databases
 If disk operations are the bottleneck, move the BizTalk Tracking database to a dedicated SQL
Server computer and/or dedicated disk. If CPU processing and disk operations on the primary
MessageBox database are not the bottleneck, you can create new MessageBox databases on the
same SQL Server computer to leverage your existing hardware.
 Follow SQL Server best practices to isolate the transaction and data log files for the MessageBox
and BizTalk Tracking databases onto separate physical disks.
 Allocate sufficient storage space for the data and log files. Otherwise SQL Server will automatically
consume all of the available space on the disks where the log files are kept. The initial size of the
log files depends on the specific requirements in your scenario. Estimate the average file size in
your deployment based on testing results, and expand the storage space before implementing your
solution.
 Allocate sufficient storage space for high-disk-use databases, such as the MessageBox, Health and
Activity Tracking (HAT), and Business Activity Monitoring (BAM). If your solution uses the BizTalk
Framework messaging protocol, allocate sufficient storage space for the BizTalk Configuration
database (BizTalkMgmtDb).
 Depending on business needs, such as data retention periods, and the volume of data processed in
your scenario, configure the Archive/Purge jobs on the HAT-Tracking database such that the
BizTalk Tracking database does not grow too large. The growth of this database can degrade
performance because reaching the full capacity of the database imposes a limit on the rate of data
insertion. This is especially true when especially when one BizTalk Tracking database supports
multiple MessageBox databases.
 Scale up the servers hosting the MessageBox and BizTalk Tracking databases if they are the
bottleneck. You can scale up the hardware by adding CPUs, adding memory, upgrading to faster
CPUs, and using high-speed dedicated disks.
 Splitting the TempDB files across multiple files may resolve performance issues related to I/O
operations. As a general guideline, create one file data file per processor and use the same size for
all files created.
 Change the database auto-grow settings to a fixed value such as 100-150MB. By default the
database growth is configured to 10%, which can lead to delays when growing larger databases.
 SQL Server memory should be set to a fixed value by setting both Min Server Memory and Max
Server Memory to the same value. In general, allocate 75% of physical memory to SQL Server and
leave 25% for the rest of the operating system and any applications. If this is a dedicated SQL
Server, you can decrease the amount reserved for the operating system to a minimum of 1GB.

See Also
Finding and Eliminating Bottlenecks

Investigating Bottlenecks
This topic describes a recommended process for investigating bottlenecks.

What is the source of the problem?

The source of the bottleneck could be hardware or software related. When resources are underused, it
is usually an indication of a bottleneck. Bottlenecks can be caused by hardware limitations, by
inefficient software configurations, or by both.
Identifying bottlenecks is an incremental process whereby alleviating one bottleneck can lead to the
discovery of the next one. The science of identifying and alleviating these bottlenecks is the objective of
this topic. It is possible for a system to perform at peaks for short periods of time. However, for
sustainable throughput a system can only process as fast as its slowest performing component.

Using an iterative approach to testing

Bottlenecks can occur at the endpoints (entry/exit) of the system or in the middle
(orchestration/database). After the bottleneck has been isolated, use a structured approach to identify
the source. After the bottleneck is eased, it is important to measure performance again to ensure that a
new bottleneck has not been introduced elsewhere in the system.
The process of identifying and fixing bottlenecks should be done in an iterative manner. Vary only one
parameter at a time, repeat exactly the same steps during each test run, and then measure
performance to verify the impact of the single modification. Varying more than one parameter at a time
could conceal the effect of the change.
For example, changing parameter 1 could improve performance. However, changing parameter 2 in
conjunction with changing parameter 1 could have a detrimental effect and negate the benefits of
changing parameter 1. This leads to a net zero effect and results in a false negative on the effect of
varying parameter 1 and a false positive on the effect of varying parameter 2.

Testing consistency
Measuring performance characteristics after changing settings should be done to validate the effect of
the change.
 Hardware - Use consistent hardware because varying the hardware can cause inconsistent
behavior and produce misleading results. For example, you would not use a laptop to test
performance of a BizTalk solution.
 Test Run Duration - Measure performance for a fixed minimum period to ensure that the results
are sustainable. Running tests for longer periods also ensures the system has gone through the
initial warm/ramp up period where all caches are populated, database tables have reached
expected counts, and throttling is given sufficient time to regulate throughput once predefined
thresholds are hit. This approach will help discover optimal sustainable throughput.
 Test Parameters – Do not vary test parameters from test run to test run. For example, varying map
complexity and/or document sizes can produce different throughput and latency results.
 Clean State - After a test is complete, cleanup all state before running the next test. For example,
historical data can buildup in the database impacting runtime throughput. Recycling the service
instances helps to release cached resources like memory, database connections, and threads. In
your test environment, you may want to run the script BizTalk Message Box Clean as described in
the article “BizTalk Server 2006: Managing a Successful Performance Lab” (available at
http://go.microsoft.com/fwlink/?LinkID=118365). This script is intended to return your BizTalk Server
test environment to a fresh state with regards to the Message Box between runs. The script deletes
all running instances and all information about those instances including state, messages, and
subscriptions, but leaves all activation subscriptions so you do not have to re-enlist your
orchestrations or send ports. Note that this tool is not supported on production systems.
 Performance Testing and Tuning - The goal of this test category is to maximize performance and
throughput of your application and find the Maximum Sustainable Throughput (MST) of your system
(see “Planning for Sustained Performance” at http://go.microsoft.com/fwlink/?LinkID=104146) and
“What Is Sustainable Performance?” at http://go.microsoft.com/fwlink/?LinkID=106928).
The MST is the highest load of message traffic that a system can handle indefinitely in a production
environment. All BizTalk applications should be tested for performance and throughput before going
into production. At a minimum, you should run a representative set of test cases that represent the
most common usage scenarios. We recommend that you test against expected loads and peak
loads in a separate environment that matches characteristics of the production environment. This
 environment should have all of the corporate standard services installed and running, such as
monitoring agents, and antivirus software.
 We also recommend that you test new BizTalk applications on the same hardware in production
alongside the other BizTalk applications that are running. These other BizTalk applications put
additional load on the BizTalk Server, SQL Server, network I/O, and disk I/O. In addition, one
BizTalk application could cause another to throttle (when the spool depth gets too large, for
example). All BizTalk applications should be performance / stress tested before going into
production. In addition, you should determine how long it takes the system to recover from peak
loads. If the system does not fully recover from a peak load before the next peak load occurs, then
you've got a problem. The system will get progressively further and further behind and will never be
able to fully recover.

Expectations: throughput vs. latency

You can expect a certain amount of throughput and/or latency from the deployed system. Attempting to
achieve high throughput and low latency simultaneously places opposing demands on the system. You
can expect optimal throughput with reasonable latency. As throughput improves, stress (such as, higher
CPU consumption, higher disk-I/O contention, memory pressure, and greater lock contention) on the
system increases. This situation can have a negative impact on latency. To discover optimal capacity of
a system, we recommend that you identify and minimize any bottlenecks.
Completed instances residing in the database can cause bottlenecks. When bottlenecks occur,
performance can degrade. Giving the system sufficient time to drain can help fix the problem.
Discovering the cause of the backlog buildup and helping fix the issue is important.
To discover the cause of the backlog, you can analyze historical data and monitor performance
counters (to discover usage patterns, and diagnose the source of the backlog). Commonly, backlogs
can occur when large volumes of data are processed in a batched manner on a nightly basis. You may
find it useful to discover the capacity of the system and its ability to recover from a backlog. This
information can help you to estimate hardware requirements for handling overdrive scenarios and the
amount of buffer room to accommodate within a system to handle unforeseen spikes in throughput.
Tuning the system for optimal sustainable throughput requires an in depth understanding of the
deployed application, the strengths and weaknesses of the system, and usage patterns of the specific
scenario. The only way to discover bottlenecks and predict optimal sustainable throughput with
certainty is through thorough testing on a topology that closely matches what will be used in production.
When running load and stress tests against a certain use case, isolating single artifacts (receive
locations, send ports, orchestrations) into separate host instances and setting the right counters inside
the performance monitor tool is crucial to narrow down the cause of a bottleneck.
Other topics in this section guide you through the process of defining that topology, and provide
guidance on how to lessen and avoid bottlenecks.
Scaling
Bottlenecks can occur at various stages of a deployed topology. Some bottlenecks can be addressed
by either scaling up or scaling out the environment Scaling up is the process of upgrading the existing
computer. For example, you can upgrade a BizTalk Server computer from a four-processor computer to
an eight-processor computer, as well as substituting the existing CPUs and adding more RAM. In this
way, you can accelerate resource-intensive tasks such as document parsing and mapping. Scaling out
is the process of adding servers to your deployment. The decision to scale up or out depends on the
type of bottleneck and the application being configured. An application needs to be built from the
ground up to be capable of taking advantage of scaling up or out. The following guidance explains how
to change hardware deployment topologies based on bottlenecks encountered.
Scaling up means running a BizTalk solution on upgraded hardware (for example, adding CPU’s and
memory). You should look at scaling up when 1) scaling out is too expensive or 2) scaling out will not
help solve a bottleneck. For example, you can significantly reduce the time spent transforming and
processing a large message if you run the task on a faster machine.
Scaling out the application platform consists of adding BizTalk nodes to the BizTalk Server Group and
using them to run one or more parts of the solution. You should look at scaling out when 1) you need to
isolate send, receive, processing, tracking hosts or 2) when memory, I/O or Network I/O resources are
maxed out for a single server. The load can be spread across multiple servers; however, adding new
nodes to the BizTalk Server Group can increase the lock contention on the MessageBox database.
So should you scale up or scale out? Scaling up your platform can reduce the latency of a BizTalk
solution because it makes single tasks (for example, message mapping) run faster. Scaling out can
improve the Maximum Sustainable Throughtput and the scalability of your BizTalk solution because it
allows you to spread the workload across multiple machines.

System Level Bottlenecks

This topic describes how to address common system-level bottlenecks that can impact the performance
of a BizTalk Server solution.

Creating a snapshot of the baseline configuration

Gathering the following information can provide you with a snapshot of the baseline configuration that
you can use to assist in correcting system-level bottlenecks.
Gather documentation - Review the documentation of the architecture and infrastructure of your
scenario.
Run the Baseline Security Analyzer - Follow these steps to run the Baseline Security Analyzer:
1. Download the Baseline Security Analyzer from http://go.microsoft.com/fwlink/?LinkID=117287.
2. Using a domain administrator account, log on to a computer on the same network that is hosting
the BizTalk Server and SQL Server computers.
3. Install the Microsoft Baseline Security Analyzer on the current computer (for example, one of the
BizTalk Server computers or a separate computer).
4. Execute a separate scan (Start Scan), specifying as a parameter the name or the IP address of
each BizTalk Server and SQL Server computer.
5. Copy each security report (.mbsa files) from the %userprofile%\SecurityScans directory.
Run the BizTalk Server 2006 Best Practices Analyzer - Follow these steps to run the BizTalk Server
2006 Best Practices Analyzer:
1. Download the BizTalk Server 2006 Best Practices Analyzer from http://go.microsoft.com/fwlink/?
LinkID=86622.
2. Using a user account that is part of the BizTalk Server Administrator security group, log on to a
BizTalk Server node.
3. Install the BizTalk Server 2006 Best Practices Analyzer on the current computer.
4. Run the tool and save the report.
Run MSInfo32 and save the results - Follow these steps to run MSInfo32:
1. Using a domain or a local administrator account, log on to each BizTalk Server and SQL Server
computer.
2. Launch a command prompt and change directories to the %windir%\system32 directory of the
computer.
3. Run MSinfo32.exe from the command prompt.
4. Click the File menu and select the Export menu item to export to save the computer configuration.
Export the BizTalk Server and SQL Server computer TCP/IP registry settings - Follow these steps
to save the BizTalk Server and SQL Server TCP/IP registry settings:
1. Launch a command prompt and change directories to the %windir%\system32 directory of the
computer.
2. Run Regedit.exe from the command prompt.
3. Navigate to the following key in the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] (network
settings)

4. Right-click this key and select Export to export the registry key to a file.
Collect the BizTalk configuration files - On each BizTalk Server node, collect the
BTSNTSVC.exe.config file located in the BizTalk Server installation folder (e.g. C:\Program
Files\Microsoft BizTalk Server 2006).
Collect the .NET configuration files - On each BizTalk Server node, collect the machine.config and
web.config .NET Framework 2.0 configuration files. You can find the configuration files in the %windir
%\Microsoft.NET\Framework\v2.0.50727\CONFIG folder.
Use the MsgBoxViewer tool to collect information about the Messagebox database - Follow these
steps to collect information about the MessageBox database using the MsgBoxViewer tool:
1. Download the MsgBoxViewer tool from http://go.microsoft.com/fwlink/?LinkID=117289.
2. Log on to the BizTalk Server computer with a user account that is part of the BizTalk Server
Administrator security group.
3. Copy the MsgBoxViewer.exe to the BizTalk Server computer.
4. Launch the tool.
5. Click the Optional Info to Collect tab, and then click Select All Info.
6. Click Start to Collect.
7. When the Status label shows the End Collection message, switch to the folder containing the
MsgBoxViewer.exe executable and copy the resulting report (.htm) and log files.
Use the BizTalk Server 2006 Documenter tool to save BizTalk configuration information – Follow
these steps to use the BizTalk Server 2006 Documenter tool to save BizTalk Server configuration
information:
1. Download the BizTalk Server 2006 Documenter tool from http://go.microsoft.com/fwlink/?
LinkID=117291.
2. Using a user account that is part of the BizTalk Server Administrator security group, log on to a
BizTalk node.
3. Install the tool.
4. Launch the BizTalk Server 2006 Documenter tool.
5. Choose the Document All Configuration option.
6. Start collecting data.
7. Save the documents produced by the tool.
Run the Windows Server 2003 Performance Advisor tool - Follow these steps to run the Windows
Server 2003 Performance Advisor tool:
1. Download the Windows Server 2003 Performance Advisor tool from http://go.microsoft.com/fwlink/?
LinkID=117292.
2. Using a domain or local administrator account, log on to each BizTalk Server and SQL Server
computer.
3. Install the Windows Server 2003 Performance Advisor tool.
4. Run the Windows Server 2003 Performance Advisor tool.
5. Press the green button under the File menu to start the system overview.
6. When the tool finishes collecting data, switch to the folder C:\PerfLogs\Report\System
Overview\Current and save the data. Note that .blg files can be quite large.
7. You can further analyze performance data collected by the Performance Advisor tool using the
Performance Analysis of Logs (PAL) tool available at http://go.microsoft.com/fwlink/?LinkID=98098.
Collect and store the source code for all components used in the solution - Store the source code
for all components (for example Orchestration, Custom Pipeline Component, and Helper components
code) on a separate file share.
Initial troubleshooting
There are certain components of a BizTalk Server solution which, if not enabled, will cause performance
problems regardless of the overall size or design of the BizTalk solution. The following preliminary
troubleshooting tasks should be completed to rule out some of the “usual suspects” before engaging in
an exhaustive bottleneck analysis of a BizTalk solution.
 Verify the Tracking host instance is running - The Tracking host instance is responsible for
moving both BAM and HAT data from the TrackingData table of the MessageBox database to the
BizTalkDTADb and/or BAMPrimaryImport database tables. If the tracking host instance is not
running, then tracking data will accumulate in the MessageBox database and negatively impact
performance of the BizTalk Server solution.
 Verify the Enterprise Single Sign-On (ENTSSO) service is running on all BizTalk Server
computers - BizTalk host instances maintain a dependency on a locally running instance of the
ENTSSO service. If the ENTSSO service is not running on the BizTalk Server, then host instances
on the server will not be able to run either.
 Verify the SQL Server Agent service is running on all SQL Server computers - The SQL
Server Agent service must be running in order for the BizTalk SQL Server Agent jobs to execute.
These jobs perform important functions to keep your servers operational and healthy.
 Verify the BizTalk SQL Server Agent jobs are enabled and running without exceptions - Even
if the SQL Server Agent service is running, it is imperative that all of the default BizTalk SQL Server
Agent jobs are enabled and running successfully.
 Check the BizTalk Server and SQL Server event logs - A cursory examination of the BizTalk
Server or SQL Server event logs may reveal a problem that could otherwise take a significant
amount of time to diagnose and resolve.
 Run the BizTalk Server 2006 Best Practices Analyzer - The BizTalk Server 2006 Best Practices
Analyzer examines a BizTalk Server 2006 deployment and generates a list of issues pertaining to
best practices standards. The tool performs configuration-level verification by gathering data from
different information sources, such as Windows Management Instrumentation (WMI) classes, SQL
Server databases, and registry entries. The data is then used to evaluate the deployment
configuration. The tool reads and reports only and does not modify any system settings, and is not
a self-tuning tool. You can download the BizTalk Server 2006 Best Practices Analyzer at
http://go.microsoft.com/fwlink/?LinkID=86622.

High-level system bottlenecks

This section describes system-level bottlenecks that may be present in a BizTalk Server solution and
possible mitigation strategies.

Disk I/O bottlenecks

Disk I/O refers to the number of read and write operations performed by your application on a physical
disk or multiple disks installed in your server. Common activities that can cause disk I/O and related
bottlenecks include long-running file I/O operations, data encryption and decryption, reading
unnecessary data from database tables, and an insufficient physical memory, which can lead to
excessive paging activity. Disk speed is another factor to consider when evaluating disk I/O bottlenecks;
faster disks provide increased performance and help reduce disk I/O bottlenecks.
The table below provides factors that should be considered when planning the disk subsystem for a
BizTalk Server solution.

Disk subsystem factor Details

Disk memory cache and available physical Because memory is cached to disk as physical
memory memory becomes limited, make sure that you
have a sufficient amount of memory available.
When memory is scarce, more pages are
written to disk, resulting in increased disk
activity. Also, make sure to set the paging file to
an appropriate size. Additional disk memory
cache will help offset peaks in disk I/O
requests. However, it should be noted that a
large disk memory cache seldom solves the
problem of not having enough spindles, and
having enough spindles can negate the need
for a large disk memory cache. For information
on configuring the Windows paging file for
optimal performance, see the section
“Configure the Windows PAGEFILE for optimal
performance” in the topic Optimizing Operating
System Performance.
Storage controller type If you have battery-backed cache, enable write
caching to improve disk write performance on
the transaction log file volumes and on the
database volumes. Write caching provides a
response time of 2 ms for a write I/O request,
as opposed to a response time of 10 to 20 ms
without write caching enabled. Enabling write
caching greatly improves the responsiveness
for client write requests. Read caching does not
improve performance in a BizTalk Server
scenario because it is only useful for sequential
disk reads, which occur only in transaction log
files.
Transaction log files are read from only when
they are being played back, such as after a
database restore or when a server is not
properly shutdown. Larger caches allow for
more data to be buffered, meaning that longer
periods of saturation can be accommodated. If
your controller allows you to configure the
cache page size, you should set it to 4 KB. A
 larger size, such as 8 KB, results in wasted
cache because a 4 KB I/O request takes up the
entire cache page of 8 KB, thereby cutting your
usable cache in half.
Spindles Spindles are more important than capacity, and
BizTalk Server performance is improved if the
spindles support a high number of random I/O
requests. Plan for no more than 80 percent
total utilization to ensure sufficient I/O is
available, even in cases of a spindle failure.
Raid The RAID solution you use should be based on
the cost and performance trade-offs that are
appropriate for your environment. Therefore,
more than one type of RAID solution may be
recommended for a particular data storage
requirement. General recommendations are as
follows:
 Use Raid-1+0 (striped sets in a mirrored
set) for the BizTalk Server databases.
 Use Raid-1 (mirrored set without parity) for
the transaction log file volumes.
 In general, Raid 5 (striped set with
distributed parity) is not recommended as
Raid 5 does not provide optimal reliability,
availability and performance as compared
to other Raid configurations.
 Due to the possibility of permanent data
loss, a Raid-0 (striped set without parity)
configuration should never be used in a
BizTalk Server production environment.
Bus type Higher throughput provides better performance.
In general, SCSI buses provide better
throughput and scalability than IDE or ATA
buses. You can use the following equation to
determine the theoretical throughput limit for
your bus type:
(Bus speed (in bits) / 8 bits per byte) X Operating speed (in
MHz) = Throughput (in MB/s)
You can also improve disk I/O performance by
placing multiple drives on separate I/O buses.
Performance counters for measuring disk I/O bottlenecks
Note
When attempting to analyze disk performance bottlenecks, you should always use physical disk
counters. However, if you use software RAID, you should use logical disk counters. As for
Logical Disk and Physical Disk Counters, the same counters are available in each of these
counter objects. Logical disk data is tracked by the volume manager (or managers), and
physical disk data is tracked by the partition manager.
The following performance counters should be used to determine if your system is experiencing a disk
I/O related bottleneck:
 PhysicalDisk\Avg. Disk Queue Length
 Threshold: Should not be higher than the number of spindles plus two.
 Significance: This counter indicates the average number of both read and writes requests that
were queued for the selected disk during the sample interval. This counter is useful for
gathering concurrency data, including data bursts and peak loads. These values represent the
number of requests in flight below the driver taking the statistics. This means the requests are
not necessarily queued but could actually be in service or completed and on the way back up
the path. Possible in-flight locations include the following:
 SCSIport or Storport queue
 OEM driver queue
 Disk controller queue
 Hard disk queue
 Actively receiving from a hard disk
 PhysicalDisk\Avg. Disk Read Queue Length
Threshold: Should be less than two.
Significance: This counter indicates the average number of read requests that were queued for the
selected disk during the sample interval.
 PhysicalDisk\Avg. Disk Write Queue Length
 Threshold: Should be less than two.
 Significance: This counter indicates the average number of write requests that were queued for
the selected disk during the sample interval.
 PhysicalDisk\Avg. Disk sec/Read
 Threshold: No specific value.
 Significance: This counter indicates the average time, in seconds, of a data read operation from
the disk.
 PhysicalDisk\Avg. Disk sec/Transfer
 Threshold: Should not be more than 18 milliseconds.
 Significance: This counter indicates the time, in seconds, of the average disk transfer. This may
indicate a large amount of disk fragmentation, slow disks, or disk failures. Multiply the values of
 the Physical Disk\Avg. Disk sec/Transfer and Memory\Pages/sec counters. If the product of
these counters exceeds 0.1, paging is taking more than 10 percent of disk access time, so you
need more physical memory available.
 PhysicalDisk\Disk Writes/sec
 Threshold: Depends on manufacturer’s specifications.
 Significance: This counter indicates the rate of write operations on the disk.
 Processor\% DPC Time, % Interrupt Time and % Privileged Time - If Interrupt Time and
Deferred Procedure Call (DPC) time are a large portion of Privileged Time, the kernel is spending a
significant amount of time processing I/O requests. In some cases performance can be improved by
configuring interrupts and DPC affinity to a small number of CPUs on a multiprocessor system,
which improves cache locality. In other cases, it works best to distribute the interrupts and DPCs
among many CPUs, so as to keep the interrupt and DPC activity from becoming a bottleneck. For
information on using the Interrupt Filter Configuration tool to bind network adapter interrupts to
specific processors on multiprocessor computers, see the section “Use the Interrupt Filter
Configuration tool to bind network adapter interrupts to specific processors on multiprocessor
computers” in Optimizing Operating System Performance.
 Processor\DPCs Queued / sec - Measures how DPCs are consuming CPU time and kernel
resources.
 Processor\Interrupts / sec - Another measurement of how interrupts are consuming CPU time and
kernel resources. Modern disk controllers often combine or coalesce interrupts so that a single
interrupt results in the processing of multiple I/O completions. Of course, there is a trade-off
between delaying interrupts (and thus completions) and economizing CPU processing time.

Disk I/O tuning options

If you determine that disk I/O is a bottleneck in your environment, the following techniques may be used
to alleviate the bottleneck:
 Defragment your disks - Use the PageDefrag utility available at http://go.microsoft.com/fwlink/?
LinkId=108976 to defragment the Windows paging file and pre-allocate the Master File Tables.
 Use stripe sets to process I/O requests concurrently over multiple disks - Use mirrored
volumes to provide fault tolerance and increase I/O performance. If you do not require fault
tolerance, implement stripe sets for fast reading and writing and improved storage capacity. When
stripe sets are used, per disk utilization is reduced because work is distributed across the volumes,
and overall throughput increases. If you adding additional disks in a stripe set does not increase
throughput, then your system might be experiencing a bottleneck due to contention between disks
by the disk controller. In this case, adding an additional disk controller will help distribute load and
increase performance.
 Distribute workload among multiple drives - Windows Clustering and Distributed File System
provide solutions for load balancing on multiple disk drives.
 Limit the use of file compression or encryption - File compression and encryption are I/O-
intensive operations. You should only use them where absolutely necessary.
 Disable creation of short names - If you are not supporting MS-DOS for Windows 3.x clients,
disable short names to improve performance. For more information about disabling the creation of
short names, see the section “Disable short-file-name (8.3) generation” in Optimizing Operating
System Performance.
 Disable last access update - By default, NTFS updates the date and time stamp of the last access
on directories whenever it traverses the directory. For a large NTFS volume, this update process
may hinder performance. For more information about disabling last access updates, see the section
“Disable NTFS last access updates” in Optimizing Operating System Performance.

Caution
Some applications, such as incremental backup utilities, rely on the NTFS update
information and will not function correctly without it.
 Reserve appropriate space for the master file table - Add the NtfsMftZoneReservation entry to
the registry depending on the number of files that are typically stored on your NTFS volumes. When
you add this entry to the registry, the system reserves space on the volume for the master file table.
Reserving space in this manner allows the master file table to grow optimally. If your NTFS volumes
generally store relatively few files, set the value of this registry entry to the default value of 1.
Typically you can use a value of 2 or 3 if your NTFS volumes store a moderate numbers of files,
and use a value of 4 (the maximum) if your NTFS volumes tend to contain a relatively large number
of files. However, make sure to test any settings greater than 2, because these greater values
cause the system to reserve a much larger portion of the disk for the master file table. For more
information about adding the NtfsMftZoneReservation to the registry, see the section “Increase
space available for the master file table” in Optimizing Operating System Performance.
 Use the most efficient disk systems available - In addition to the physical disk that is used,
consider the type of disk controller and cabling that will be used. An efficient disk subsystem should
also provide drivers that support interrupt moderation or interrupt avoidance to mitigate processor
interrupt activity caused by disk I/O.
 Ensure that you are using the appropriate RAID configuration - Use RAID 10 (striping and
mirroring) for optimal performance and fault tolerance. The tradeoff is that using RAID 10 is
expensive. Avoid using RAID 5 when you have extensive write operations. For more information
about implementing RAID in a BizTalk Server environment, see the section “Disk Infrastructure” in
the BizTalk Server Database Optimization" white paper at http://go.microsoft.com/fwlink/?
LinkID=101578.
 Consider using database partitions - If you have a database bottleneck, consider using database
partitions and mapping disks to specific tables and transaction logs. The primary purpose of
partitions is to overcome disk bottlenecks for large tables. If you have a table with large number of
rows and you determine that it is the source of a bottleneck, consider using partitions. For SQL
Server, you can use file groups to improve I/O performance. You can associate tables with file
groups, and then associate the file groups with a specific hard disk. For more information about
using optimizing filegroups for the BizTalk Server databases, see Optimizing Filegroups for the
Databases.
 Consider adding physical memory, if you have excessive page faults - A high value for the
Memory: Pages/sec performance counter could indicate excessive paging which will increase disk
I/0. If this occurs, consider adding physical memory to reduce disk I/O and increase performance.
 Consider using a disk with a higher RPM rating or using a Storage Area Network (SAN)
device - Disks with higher RPM ratings offer improved performance compared to disks with lower
RPM ratings. SAN devices typically offer top tier performance but at a price premium.
 Follow the recommendations in Optimizing Database Performance. This topic provides several
recommendations for optimizing database performance both before and after configuring BizTalk
Server.

CPU bottlenecks
Each application that runs on a server gets a time slice of the CPU. The CPU might be able to efficiently
handle all of the processes running on the computer, or it might be overloaded. By examining processor
activity and the activity of individual processes including thread creation, thread switching and context
switching, you can gain insight into processor workload and performance.

You may have a CPU bottleneck if…

 The value of the Processor\% Processor Time performance counter often exceeds 75%.
 The value of the System\ Processor Queue Length performance counter is 2 or more for a
sustained period of time.
 The value of the Processor\% Privileged Time or System\Context Switches/sec performance
counters are unusually high.
If the value of Processor\ % Processor Time performance counter is high, then queuing occurs,
and in most scenarios the value of System\ Processor Queue Length will also be high.

Performance counters for measuring CPU bottlenecks

The following performance counters should be used to determine if your system is experiencing a CPU
related bottleneck:
 Processor\% Processor Time
Threshold: Should be less than 85%.
Significance: This counter is the primary indicator of processor activity. High values many not
necessarily be bad. However, if the other processor-related counters are increasing linearly
such as Processor\% Privileged Time or System\Processor Queue Length, high CPU
utilization may be worth investigating.
 Processor\% Privileged Time
Threshold: A figure that is consistently over 75 percent indicates a bottleneck.
Significance: This counter indicates the percentage of time a thread runs in privileged mode. When
your application calls operating system functions (for example to perform file or network I/O or
to allocate memory), these operating system functions are executed in privileged mode.
 Processor\% Interrupt Time
Threshold: Depends on the processor.
Significance: This counter indicates the percentage of time the processor spends receiving and
servicing hardware interrupts. This value is an indirect indicator of the activity of devices that
generate interrupts, such as network adapters. A dramatic increase in this counter indicates
potential hardware problems.
 System\Processor Queue Length
Threshold: An average value consistently higher than 2 indicates a bottleneck.
Significance: If there are more tasks ready to run than there are processors, threads queue up. The
processor queue is the collection of threads that are ready but not able to be executed by the
processor because another thread is currently executing. A sustained or recurring queue of
more than two threads is a clear indication of a processor bottleneck. You may get more
throughput by reducing parallelism in those cases.
You can use this counter in conjunction with the Processor\% Processor Time counter to
determine if your application can benefit from more CPUs. There is a single queue for
processor time, even on multiprocessor computers. Therefore, in a multiprocessor computer,
divide the Processor Queue Length (PQL) value by the number of processors servicing the
workload.
If the CPU is very busy (90 percent or higher utilization) and the PQL average is consistently
higher than 2 per processor, you may have a processor bottleneck that could benefit from
adding CPUs. Or, you could reduce the number of threads and queue more at the application
level. This will cause less context switching, and less context switching is good for reducing
CPU load. A common reason for a PQL value of 2 or higher with low CPU utilization is that
requests for processor time arrive randomly and threads demand irregular amounts of time
from the processor. This means that the processor is not a bottleneck but that the application
threading logic should be improved.
 System\Context Switches/sec
Threshold: As a general rule, a context switching rate less than 5,000 per second per processor is
not worth worrying about. If context switching rates exceed 15,000 per second per processor,
then context switching can become a bottleneck.
Significance: Context switching occurs when a higher priority thread preempts a lower priority
thread that is currently running or when a high priority thread blocks other threads. High levels
of context switching can occur when many threads share the same priority level. This often
indicates that there are too many threads competing for the processors on the system. If both
processor utilization and context switching levels are low, this is often an indication that threads
are blocked.

Resolving CPU bottlenecks

The first step is to identify which process is consuming excessive processor time. Use Windows Task
Manager to identify which process is consuming high levels of CPU by looking at the CPU column on
the Processes page. You can also determine this by monitoring Process\%Processor Time in
Performance Monitor and selecting the processes you want to monitor.
Another powerful tool for determining which processes are consuming excessive CPU time is the Visual
Studio Team System Profiler that is available with the Visual Studio Team System (VSTS) suite. For
more information about using the Visual Studio Team System Profiler, see the Visual Studio Team
System documentation.
After you determine that your CPU is a bottleneck you have several options, including the following:
 Add multiple processors if you have multi-threaded applications. Consider upgrading to a more
powerful processor if your application is single-threaded.
 If you observe a high rate of context switching, consider reducing the thread count for your process
before increasing the number of processors.
 Analyze and tune the application that is causing high CPU utilization. You can dump the running
process by using the ADPLUS utility and analyze the cause by using Windbg. These utilities are
part of the Windows debugging toolkit. You can download these tools from
http://go.microsoft.com/fwlink/?LinkID=106624.
 Analyze the instrumentation log generated by your application to isolate the subsystem that is
taking the maximum amount of time for execution. Determine whether a code review would be
more beneficial than just tuning the BizTalk Server environment.

Note
Although you can change the process priority level of an application by using Task Manager or
from a command prompt, you should generally avoid doing so.

Memory bottlenecks
When evaluating memory-related bottlenecks, consider unnecessary allocations, inefficient clean up,
and inappropriate caching and state management mechanisms. To resolve memory-related
bottlenecks, optimize your code to eliminate these issues and then tune the amount of memory
allocated to your application(s). If you determine during tuning that memory contention and excessive
paging are occurring, you may need to add additional physical memory to the server. Low memory
leads to increased paging of an application's virtual address space to and from disk. If paging becomes
excessive, disk I/O will increase and negatively impact overall system performance.

You might have a memory bottleneck if…

 The value of the Memory\Available MBytes performance counter is low, either due to system
memory limitations or an application that is not releasing memory. Monitor the value of the
Process\Working Set performance counter for each process that is running. If value of the
Process\Working Set remains high even when the process is not active, this may be an indication
that the process is not releasing memory as it should.
 The value of the Memory\Pages/sec performance counter is high. The average of Memory\Pages
Input/sec divided by average of Memory\Page Reads/sec gives the number of pages per disk
 read. This value should not generally exceed five pages per second. A value greater than five
pages per second indicates that the system is spending too much time paging and requires more
memory (assuming that the application has been optimized).

Performance counters for measuring memory bottlenecks

The following performance counters should be used to determine if your system is experiencing a
memory related bottleneck:
 Memory\Available Mbytes
Threshold: A consistent value of less than 20 to 25 percent of installed RAM is an indication of
insufficient memory.
Significance: This indicates the amount of physical memory available to processes running on the
computer. Note that this counter displays the last observed value only. It is not an average.
 Memory\Page Reads/sec
Threshold: Sustained values of more than five indicate a large number of page faults for read
requests.
Significance: This counter indicates that the working set of a process is too large for the available
physical memory which is causing memory to page to disk. It shows the number of read
operations, without regard to the number of pages retrieved in each operation. Higher values
indicate a memory bottleneck.
If a low rate of page-read operations coincides with high values for Physical Disk\% Disk Time
and Physical Disk\Avg. Disk Queue Length, a disk I/O bottleneck condition may exist. If an
increase in queue length is not accompanied by a decrease in the pages-read rate, a memory
bottleneck exists due to insufficient physical memory.
 Memory\Pages/sec
Threshold: A sustained value of more than five indicates a bottleneck.
Significance: This counter indicates the rate at which pages are read from or written to disk to
resolve hard page faults. Multiply the values of the Physical Disk\Avg. Disk sec/Transfer and
Memory\Pages/sec performance counters. If the product of these values exceeds 0.1, paging
is utilizing more than 10 percent of disk access time, which indicates that insufficient physical
memory is available.
 Memory\Pool Nonpaged Bytes
Threshold: Watch the value of Memory\Pool Nonpaged Bytes for an increase of 10 percent or
more from its value at system startup.
Significance: An increase of 10 percent or more from the value at startup may be an indication of a
memory leak.
 Server\Pool Nonpaged Failures
Threshold: Regular nonzero values indicate a bottleneck.
Significance: This counter indicates the number of times allocations from the non-paged pool have
failed. The non-paged pool contains pages from a process's virtual address space that are not
 to be swapped out to the page file on disk, such as a process kernel object table. The
availability of the non-paged pool determines how many processes, threads, and other such
objects can be created. When allocations from the non-paged pool fail, this can be due to a
memory leak in a process, particularly if processor usage has not increased accordingly.
 Server\Pool Paged Failures
Threshold: No specific value.
Significance: This counter indicates the number of times allocations from the paged pool have
failed. A positive value for this counter is an indication that the computer has insufficient
physical memory or that the Windows paging file is too small.
 Server\Pool Nonpaged Peak
Threshold: No specific value.
Significance: This is the maximum number of bytes in the non-paged pool that the server has
reserved for use at any one point. It indicates how much physical memory the computer should
have. Because the non-paged pool must be resident in physical memory and because there
has to be some memory left over for other operations, as a rule of thumb the computer should
have installed physical memory that is 4 times the value indicated for this counter.
 Memory\Cache Bytes
Threshold: No specific value.
Significance: Monitors the size of cache under different load conditions. This value of this
performance counter indicates the size of the static files cache. By default, this counter uses
approximately 50 percent of available memory, but decreases if available memory shrinks,
which affects system performance.
 Memory\Cache Faults/sec
Threshold: No specific value.
Significance: This counter indicates how often the operating system looks for data in the file system
cache but fails to find it. This value should be as low as possible.
 Cache\MDL Read Hits %
Threshold: The higher this value, the better the performance of the file system cache. Values
should be as close to 100 percent as possible.
Significance: This counter provides the percentage of Memory Descriptor List (MDL) Read requests
to the file system cache, where the cache returns the object directly rather than requiring a read
from the hard disk.
 Process\Working Set
Threshold: No specific value.
Significance: The working set is the set of memory pages currently loaded in memory (physical +
virtual). If the system has sufficient memory, it can maintain enough space in the working set so
that it does not need to perform disk operations to page memory to disk. However, if there is
insufficient memory, the system tries to reduce the working set by taking away the memory from
the processes which results in an increase in page faults. When the rate of page faults rises,
 the system tries to increase the working set of the process. If you observe wide fluctuations in
the working set, it might indicate a memory shortage. Higher values in the working set may also
be due to multiple assemblies in an application. You can improve the working set by using
assemblies shared in the global assembly cache.

Resolving memory bottlenecks

If you determine that memory is a bottleneck in your BizTalk Server environment, use one or more of
the following methods to resolve the bottleneck:
 Tune the amount of memory allocated if you can control the allocation. For example, you can tune
this for BizTalk Server, ASP.NET and SQL Server.
 Increase the size of the Windows paging file and follow the steps in the “Configure the Windows
PAGEFILE for optimal performance” section of Optimizing Operating System Performance.
 Turn off services that are not used. Stopping services that you do not use regularly saves memory
and improves system performance. For more information, see the “Disable non-essential services”
section of Optimizing Operating System Performance.
 Remove unnecessary protocols and drivers. Even idle protocols use space in the paged and non-
paged memory pools. Drivers also consume memory, so you should remove unnecessary ones.
For more information, see the “Remove unnecessary network protocols” section of Optimizing
Operating System Performance.
 Install additional physical memory on the computers in the BizTalk Server environment.

Note
On a 32-bit system, BizTalk can use a maximum of 2GB of memory, the limit increases to 3GB
with BizTalk 2006 if the /3GB switch is used. For more information on memory usage, see
“Memory Limits for Windows Releases” at http://go.microsoft.com/fwlink/?LinkId=118349.

Network I/O bottlenecks

You might have a network I/O bottleneck if…

 The value of the Network Interface\Bytes Total/sec performance counter exceeds 80% of
available network bandwidth.
 The value of the Server\Bytes Total/sec performance counter is greater than 50% of available
network bandwidth.

Performance counters for measuring network I/O bottlenecks

The following performance counters should be used to measure network I/O and determine if your
system is experiencing a network I/O related bottleneck:
 Network Interface\Bytes Total/sec
 Threshold: Sustained value of more than 80 percent of network capacity.
Significance: This counter indicates the rate at which bytes are sent and received over each
network adapter. This counter helps determine if a network adapter is saturated and whether
you should add one or more network adapters to increase available network bandwidth.
 Network Interface\Bytes Received/sec
Threshold: No specific value.
Significance: This counter indicates the rate at which bytes are received over each network adapter.
Use the value of this counter to calculate the rate of incoming data as a percentage of total
available bandwidth. This will help determine if network bandwidth should be increased on the
client sending data to BizTalk Server or if network bandwidth should be increased on the
BizTalk Server computer itself.
 Network Interface\Bytes Sent/sec
Threshold: No specific value.
Significance: This counter indicates the rate at which bytes are sent over each network adapter.
Use the value of this counter to calculate the rate of outgoing data as a percentage of total
available bandwidth. This will help determine if network bandwidth should be increased on the
BizTalk Server sending data to a client or if network bandwidth should be increased on the
client computer receiving data from BizTalk Server.
 Server\Bytes Total/sec
Threshold: Sustained value of more than 50 percent of network capacity.
Significance: This counter indicates the number of bytes sent and received over the network.
Higher values indicate a network I/O bottleneck. If the sum of Bytes Total/sec for all servers is
roughly equal to the maximum transfer rate of your network, consider subnetting the network to
improve performance. For more information about subnetting a network to improve
performance, see the Subnets section of the “BizTalk Server Database Optimization”
whitepaper at http://go.microsoft.com/fwlink/?LinkID=101578.

Resolving network I/O bottlenecks

If you determine that network I/O is a bottleneck in your environment, use one or more of the following
methods to resolve the bottleneck:
 Follow the recommendations in the “General guidelines for improving network performance” section
of Optimizing Network Performance.
 Run the Windows Powershell network optimization script described in the topic Optimizing Network
Performance on each computer in the BizTalk Server environment.

Bottlenecks in the BizTalk Server Tier

The BizTalk tier can be divided into the following functional areas:
 Receiving
 Processing
 Transmitting
 Tracking
 Other
For these areas, if the system resources (CPU, memory, and disk) appear to be saturated, upgrade the
server by scaling the platform up or out based on the characteristics of your application. If the system
resources are not saturated, perform the steps described in this section.

Bottlenecks in the receive location

If messages build up at the receive location (for example, file receive folder grows large), this indicates
that the system is unable to absorb data fast enough to keep up with the incoming load. This is due to
internal throttling. That is, BizTalk Server reduces the receiving rate if the subscribers are unable to
process data fast enough causing backlog buildup in the database tables. If the bottleneck is caused by
hardware limitations, try scaling up. For more information about scaling up, see the following topics in
the BizTalk Server 2006 R2 documentation:
 “Scaling Up the BizTalk Server Tier” at http://go.microsoft.com/fwlink/?LinkId=115393.
 ”Scaling Up the SQL Server Tier” at http://go.microsoft.com/fwlink/?LinkId=115401.
It is also possible to scale out by adding a host instance (server) to the host mapped to the receive
handler. For more information about scaling out, see the following topics in the BizTalk Server 2006 R2
documentation:
 ”Scaling Out the BizTalk Server Tier” at http://go.microsoft.com/fwlink/?LinkId=115405.
 “Scaling Out the SQL Server Tier” at http://go.microsoft.com/fwlink/?LinkID=102619.
Use Perfmon to monitor the resource use on the system. It is important to confirm that the external
receive location is not the cause of the bottleneck. For example, confirm whether the remote file share
is saturated due to high disk I/O, the server hosting the remote outgoing queue is not saturated, or the
client used to generate HTTP/SOAP load is not starved on threads.

Processing bottlenecks
If the Host Queue – Length performance counter is climbing, it indicates that the orchestrations are not
completing fast enough. For more information, see the Perfmon counter table in this topic. This could
be due to memory contention or CPU saturation.
If the orchestration servers are the bottleneck, use Perfmon to identify the source.
If the server is CPU bound, consider the following:
 If the workflow is complex consider splitting the orchestration into multiple smaller orchestrations
 Note
Splitting an orchestration into multiple workflows can cause additional latency and add
complexity. Multiple workflows can also cause an increase in the number of messages
published to and consumed from the BizTalkMsgBoxDb, putting additional pressure on the
database.
 If you use complex maps, consider whether they can be moved to the Receive/Send ports. Be sure
to verify which ports have additional bandwidth.
 Consider scaling up the hardware or scaling out by configuring an additional processing server.

Transmitting bottlenecks
If the server hosting the send adapters is saturated on resources (for example, disk, memory, or CPU),
consider scaling-up the server or scaling-out to additional send host servers. The sending tier could
become the bottleneck if the destination (external to BizTalk) is unable to receive data fast enough. This
will cause messages to buildup in the MessageBox database (Application SendHostQ).
If all the endpoints are within the scope of the topology, isolate the cause at the destination. For
example, determine if the HTTP/SOAP location is optimally configured to receive load. If not, consider
scaling out. Also determine if the destination is growing due to excessive output messages delivered by
BizTalk. If yes, you might need a maintenance plan to archive and purge the destination messages.
Large numbers of files in a destination folder can severely impact the ability of the BizTalk service to
commit data to the disk drive.

Tracking bottlenecks
The Tracking host instance is responsible for moving the Business Activity Monitoring (BAM) and Health
and Activity Tracking (HAT) data from the MessageBox database (TrackingData table) to the BizTalk
Tracking and/or BAM Primary Import database tables. If multiple MessageBox databases are
configured, the tracking host instance uses four threads per MessageBox database.
It is possible that the Tracking host instance is CPU bound. If it is, consider scaling-up the server or
scale-out by configuring an additional server with Host Tracking enabled. The multiple host instances
will automatically balance load for the multiple MessageBox databases configured. For more
information about scaling, see the topic “Scaling Your Solutions” in the BizTalk Server 2006 R2
documentation at http://go.microsoft.com/fwlink/?LinkID=107575.
If the TrackingData table in the MessageBox database grows large, it is usually because the data
maintenance jobs on the BizTalk Tracking and/or BAM Primary Import database are not running as
configured, causing growth of the BizTalk Tracking and/or BAM Primary Import databases. After these
databases grow too large it can have a negative impact on the ability of the Tracking host to insert data
into the TrackingData table. This causes tracked data to back up in the MessageBox database tables.
The growth of the TrackingData table cause throttling to start.
You should only enable the minimum tracking required for your application, as this will reduce the
amount of data logged and lower the risk of tracking bottlenecks. For information on disabling tracking
settings for individual items such as orchestrations and send/receive ports, see
http://go.microsoft.com/fwlink/?LinkId=118343.

Other
Configure the deployment topology such that different functionality runs in dedicated isolated host
instances. This way each host instance gets its own set of resources (for example, on a 32-bit system,
2GB virtual memory address space, handles, threads). If the server is has sufficient CPU headroom
and memory to host multiple host instances, they can be configured to run on the same physical
computer. If not, consider scaling out by moving the functionality to dedicated servers. Running the
same functionality on multiple servers also serves to provide a highly available configuration.

BizTalk system performance counters

Object Instance Counter Monitoring Purpose

Processor _Total % Processor Time Resource Contention

Process BTSNTSvc Virtual Bytes Memory Leak/Bloat
Process BTSNTSvc Private Bytes Memory Leak/Bloat
Process BTSNTSvc Handle Count Resource Contention
Process BTSNTSvc Thread Count Resource Contention
Physical Disk _Instance % Idle Time Resource Contention
Physical Disk _Instance Average Disk Queue Resource Contention
Length

CPU contention
If the processor is saturated, you can fragment the application by separating the receiving from the
sending and orchestration. To do this, create separate hosts, map the hosts to specific functionality
(receive/send/orchestrations/tracking) and add dedicated servers to these separate hosts.
Orchestration functionality is often CPU-intensive. If you configure the system so the orchestrations
execute on a separate dedicated server, this can help improve overall system throughput.
If multiple orchestrations are deployed, you can enlist them to different dedicated orchestration hosts.
Mapping different physical servers to the dedicated orchestration hosts ensures that the different
orchestrations are isolated and do not contend for shared resources either in the same physical
address space or on the same server.
Stop unused host instances. Unused host instances can compete for CPU and memory resources by
regularly checking the MessageBox for messages to process. Additionally, stop unused receive
locations, send ports, and orchestrations.
Spool table growth
Downstream bottlenecks and/or resource contention can cause the spool to start growing excessively
and reduce overall performance. For more information, see Spool Table Growth in How to Identify
Bottlenecks in the MessageBox Database.

Memory starvation
High throughput scenarios can have increased demand on system memory. Since a 32-bit process is
limited by the amount of memory it can consume, it is recommended to separate the
receive/process/send functionality into separate host instances such that each host receives its own
2GB address space. In addition, if multiple host instances are running on the same physical server, you
can upgrade to 4/8GB memory to avoid swapping data to disk from real memory. Long running
orchestrations can hold onto allocated memory longer. This can cause memory bloat and throttling to
start. Large messages can also cause high memory consumption.
You can ease the memory bloat problem that occurs when large messages are processed by lowering
the Internal Message Queue Size and In-process Messages per CPU values for the specific host.

Note
If latency is a concern, changes to Internal Message Queue Size and In-process Messages
per CPU should be made with caution as this may increase end-to-end latency of the system.

Disk contention
If the disks are saturated (for example, with a large number of FILE/MSMQ transports), consider
upgrading to multiple spindles and striping the disks with RAID 10. In addition, whenever using the FILE
transport, it is important to ensure that the receive and send folders do not grow larger than 50,000
files.
The receive folder can grow large if BizTalk Server throttles incoming data into the system. It is
important to move data from the send folder so that growth in this folder does not impact the ability of
BizTalk Server to write additional data. For non-transactional MSMQ queues, it is recommended to
remotely create the receive queues so that disk contention is reduced on the BizTalk Server.
The remote non-transactional queue configuration also provides high availability as the remote server
hosting the queue can be clustered.

Other system resource contention

Depending on the type of transport, it may be necessary to configure system resources like IIS for
HTTP/SOAP (for example, MaxIOThreads, MaxWorkerThreads).
With ASP.NET 2.0, the <processModel autoConfig="true"/> setting in the machine.config file will
automatically configure the following settings for optimal performance:
 maxWorkerThreads
 maxIoThreads
 minFreeThreads attribute of the httpRuntime element
 minLocalRequestFreeThreads attribute of the httpRuntime element
 maxConnection attribute of the <connectionManagement> Element (Network Settings) element
For more information about configuring parameters that affect adapter performance, see ASP.NET
Configuration Settings for the processModel Element at http://go.microsoft.com/fwlink/?LinkId=117336.
For more information about configuration settings that can affect BizTalk Server adapters, see
Configuration Parameters that Affect Adapter Performance at http://go.microsoft.com/fwlink/?
LinkId=117337.
In addition to optimizing your BizTalk Server applications, other ASP.NET applications running on the
same server can have an affect on overall performance. It is important to optimize all of your ASP.NET
applications to reduce demand on system resources. For more information, see ASP.NET Performance
at http://go.microsoft.com/fwlink/?LinkId=117344.
When configuring for maximum performance, consider optimizing other external systems such as
messaging engines (Message Queuing, MQSeries), applications, databases, Active Directory, etc. that
are part of your overall BizTalk solution. Performance bottlenecks in any of these other external
systems can have a negative effect on your BizTalk solution.

Downstream bottlenecks
If the downstream system is unable to receive data fast enough from BizTalk, this output data will back
up in the BizTalk databases. This results in bloat, causes throttling to start, shrinks the receive pipe, and
impacts the overall throughput of the BizTalk system. A direct indication of this is Spool table growth.
For more information about bottlenecks and the Spool table, see How to Identify Bottlenecks in the
MessageBox Database.

Throttling impact
Throttling will eventually start to protect the system from reaching an unrecoverable state. Thus, you
can use throttling to verify whether the system is functioning normally and discover the source of the
problem. After you identify the cause of the bottleneck from the throttling state, analyze the other
performance counters to determine the source of the problem. For example, high contention on the
MessageBox database could be due to high CPU use, caused by excessively paging to disk that is
caused by low memory conditions. High contention on the MessageBox database could also be caused
by high lock contention due to saturated disk drives. While occasional throttling is not a significant
threat to performance, persistent throttling can indicate a more significant underlying problem. For more
information about those conditions where BizTalk Server will use throttling, see BizTalk Engine
Throttling Conditions at http://go.microsoft.com/fwlink/?LinkId=117360.
For more information about how BizTalk Server throttling can help manage the use of available
resources and minimize resource contention, see Optimizing Resource Usage Through Host Throttling
at http://go.microsoft.com/fwlink/?LinkId=117358.
BizTalk application counters
Object Instance Counter Description

BizTalk Messaging RxHost Documents Incoming Rate

Received/Sec
BizTalk Messaging TxHost Documents Outgoing Rate
Processed/Sec
XLANG/s Orchestrations PxHost Orchestrations Processing Rate
Completed/Sec.
BizTalk : MessageBox: MsgBoxName Spool Size Cumulative size of
General Counters all Host Queues
BizTalk : MessageBox: MsgBoxName Tracking Data Size Size of
General Counters TrackingData table
on the
MessageBox
BizTalk:MessageBox:Host PxHost:MsgBoxName Host Queue - Length Number of
Counters messages in the
specific Host
Queue
BizTalk:MessageBox:Host TxHost:MsgBoxName Host Queue - Length Number of
Counters messages in the
specific Host
Queue
BizTalk:Message Agent RxHost Database Size Size of publishing
(PxHost) Queue
BizTalk:Message Agent PxHost Database Size Size of publishing
(TxHost) Queue
BizTalk:Message Agent HostName Message Delivery Affects XLANG
Throttling State and Outbound
transports
BizTalk:Message Agent HostName Message Publishing Affects XLANG
Throttling State and Inbound
transports

Where do I start?
Monitoring the Message Delivery Throttling State and the Message Publishing Throttling State for
each host instance is a good place to start. If the value of these counters is not zero, this indicates
throttling in the BizTalk system and you can further analyze the cause of the bottleneck. For
descriptions on the other performance counters, see Bottlenecks in the Database Tier.
Backlog buildup
For a 1-1 deployment scenario where 1 message received results in 1 message processed and
transmitted, if the outgoing rate does not equal the incoming rate, there is a backlog in the system. In
this situation, you can monitor the Spool Size. When determining the cause of bottlenecks in outgoing
rate, run a single use-case scenario at a time. Isolate orchestrations, receive locations, and send
locations to separate hosts.
Add the BizTalk:Message Box:Host Counters to your Performance Monitor log to monitor a host. The
Host Queue - Length: counter tracks the total number of messages in a particular host queue. If one or
more of these counters continues grow over time, give particular attention to the artifacts executed by
those hosts.
If the Spool is growing linearly, determine which Application Queue is responsible for the Spool growth.
If none of the Application Queues are growing and the Spool continues to grow, it could mean that the
purge jobs are unable to keep up. This occurs if the agent is not running or there is other system
resource contention on the SQL Server.
If one of the Application Queues is growing, diagnose the cause of this growth. Monitor the system
resources on the system that is unable to drain the specific Application Queue (for example,
Orchestration Host-Q is growing due to CPU starvation on the server). In addition, verify the values of
the throttling counter for the specific host instance.
If the BizTalk:Messsage Agent Message Delivery Throttling State and Message Publishing Throttling
State performance counters are not zero, check the value to confirm the reason for throttling (for
example, memory threshold exceeded, in-flight message count too high, and so on).

F1 profiler
You can use performance counters to detect the location of the bottleneck at a high level. However,
once narrowed down, you might need to examine the code more closely to help ease the problem. The
F1 Profiler that ships with Visual Studio can be a very helpful tool to help diagnose where the code is
spending most of its cycles.
Symbols can help to create a more meaningful stack (especially for unmanaged code). For example,
the F1-Profiler can help pinpoint the number of invocations and the amount of time an API call takes to
return. Drilling further down the stack, it may be possible to detect the underlying cause of the high
latency. It could be a blocking call to a database query or a call to wait on an event.

L2/L3 cache
From a hardware perspective, you can gain the biggest benefits by using the onboard CPU cache.
Higher CPU cache helps increase cache hit rate reducing the need for the system to page data in and
out of memory to disk.
64-Bit performance bottlenecks
Performance on 64-bit systems may appear lower than what can be achieved on 32-bit systems. This is
possible for a few reasons, the most important one being memory.
Measuring performance on a 32-bit system with 2 GB of memory and comparing the results to a similar
64-bit system with 2 GB of memory is not comparing the same thing. The 64-bit system will appear to
be disk-I/O bound (low % Disk Idle time & high Disk Queue Length) and CPU bound (max CPU and
high context switching). However, this is not because performing file I/O on a 64-bit system is more
expensive.
The 64-bit system is more memory intensive (64-bit addressing) which results in the operating system
consuming most of the 2 GB available memory. When this happens, most other operations cause
paging to disk which stresses the file subsystem. Therefore, the system spends CPU cycles paging
in/out of memory both data and code and is impacted by the high disk latency cost. This manifests itself
as both higher disk contention and higher CPU consumption.
The way to alleviate this problem is to scale-up the server by upgrading the memory. Scaling-up to 8
GB is idea, however, adding more memory will not help improve throughput unless the source of the
problem is CPU starvation due to low memory conditions.

Using BAM to identify bottlenecks and high-latency

issues
When low-latency is important, you can use BAM to measure the time the system takes to complete
each stage within the BizTalk Server system. Although you can use HAT to debug the state of
messages and diagnose the source of problems in routing messages, you can use BAM to track
various points through the message flow. By creating a BAM tracking profile that defines an activity with
continuations, you can measure latency between different parts of the system to help track the most
expensive stages within the workflow process.
You can use Orchestration Debugger in HAT to query a suspended instance, resume the instance in
debug mode, and add appropriate breakpoints using the Technical Details View. This will enable you to
trace the activities and debug messages step by step.
You can set breakpoints to track the following events:
 The start and finish of an orchestration
 The start and finish of a shape
 The sending or receipt of a message
 Exceptions
At each breakpoint, you can examine information about local variables, messages and their properties,
ports, and role links.
Bottlenecks in the Database Tier
This section explains how to identify bottlenecks in the MessageBox database, BizTalk Tracking
database, and BAM Primary Import database. It also explains how to avoid disk contention, and use the
SQL-Profiler to diagnose performance bottlenecks.

In This Section
 How to Identify Bottlenecks in the MessageBox Database
 How to Identify Bottlenecks in the Tracking Database
 How to Identify Bottlenecks in the BAM Database
 How to Avoid Disk Contention

How to Identify Bottlenecks in the MessageBox

Database
To identify bottlenecks in the MessageBox database, first ensure that the SQL-Server-Agent Service is
started. Change the Service startup state from Manual to Auto so that if the server is restarted, the
service will automatically restart.
By default, the BizTalk service will throttle if the Spool, TrackingData, or ApplicationQ tables grow.
These tables are pruned by SQL-Agent jobs, which, if not running will cause the Spool to grow causing
throttling to start and protect the database from additional pressure. Check the status of the following
performance counters:
 BizTalk:Message Agent (Host Name) Message Delivery Throttling State
 BizTalk:Message Agent (Host Name) Message Publishing Throttling State
A value of “0” indicates no throttling is occurring. A value of “6” indicates the system is throttling due to
database growth. For information about how to interpret the values of these counters, see “What is
Host Throttling” and “Host Throttling Performance Counters” in the BizTalk Server 2006 R2
documentation at http://go.microsoft.com/fwlink/?LinkID=106791 and http://go.microsoft.com/fwlink/?
LinkID=106791.

Spool table growth

The Spool can start growing for multiple reasons. One reason for Spool growth is if the Application
Queues are growing. They could grow due to reasons such as downstream bottlenecks and/or resource
contention.
If the Application Queues are small and the Spool is still large, verify that the purge jobs are keeping up.
Ensure that the SQL-Agent Service is running and then verify that the following jobs are successfully
completing:
 MessageBox_Message_Cleanup_BizTalkMessageBoxDb
 MessageBox_Parts_Cleanup_BizTalkMessageBoxDb
If the MessageZeroSum table is large, it indicates that the messages have been processed. This
means that DeQueue has successfully completed and deleted data from the Application Queue tables
and the rows have been flagged for deletion. However, the purge jobs are unable to keep up with
deleting the data. This can happen if the computer running SQL Server is experiencing severe CPU
contention, impacting the ability of the purge jobs to keep up due to CPU starvation.

Application queue table growth

Application Queues host in-flight transition data that, once processed, are cleaned up by DeQueue.
After these messages are processed, the Spool table (holding references to these rows) can be
cleaned.
For example, the RxHostQ publishes data to the orchestration PxHostQ. This queue publishes data to
the sending TxHostQ each referencing a row in the Spool table. After the messages for a particular
HostQ have successfully processed through the system, these rows are deleted by DeQueue. After
these rows are deleted, the Spool (which is no longer referenced by these rows) can then be cleaned
by the purge jobs.
Application Queue growth indicates that the host instances responsible for draining the Application
Queue are unable to keep up with the incoming rate.
For example, the orchestration application queue (PxHostQ) may grow because the server responsible
for processing orchestrations is CPU bound and unable to process any faster. However, if the receiving
server is fast it may publish faster than what the orchestration server can process leading to the
Application Queue growth.
Another reason for orchestration queue growth could be due to memory contention. When many long
running orchestration instances are concurrently instantiated in memory, memory bloat indirectly
causes throttling to shrink the thread pool until memory pressure is relieved.
A reason why the send application queue may grow is if the downstream system is unable to receive
messages (outgoing from BizTalk Server) fast enough. Thus the messages will continue to reside within
the BizTalk system causing Application Queue growth. This can cause throttling to start and reduce the
receiving rate impacting the overall throughput of the system.

TrackingData table growth

The TrackingData table in the MessageBox database is a transition table into which interceptors write
tracking data for both Health and Activity (HAT) and Business Activity Monitoring (BAM) tracking. If
tracking is disabled, this table should be empty. By default, HAT-tracking is enabled for the pipelines
and orchestrations In/Out events.
If Message Body Tracking is enabled, ensure that the MessageBox database server (that is, the host
with "allow host tracking") is running. It will reduce a bottleneck as it moves data from TrackingData
table in the MessageBox database to the BizTalk Tracking database tables.
It is possible to track custom events by enabling custom HAT-tracking, for example, on promoted
properties and message body tracking. In addition to HAT-tracking data, BAM data is also written to the
TrackingData table. The Tracking Data Decode Service (TDDS, which runs on the host instance on
which tracking is enabled,) is responsible for moving this data from the MessageBox database to the
BizTalk Tracking and BAM Primary Import databases. Then after the data is successfully moved, TDDS
deletes this data. Message body tracking data is moved separately by a SQL-Agent job
TrackedMessages_Copy_BizTalkMsgBoxDb.
If TDDS is unable to keep up with the rate at which the interceptors are writing data to the TrackingData
table, this table will grow, causing throttling to start. This impacts sustainable throughput. To lessen this
problem, ensure at least one host is running with tracking enabled.
If the data still builds up, ensure the BizTalk Tracking database is not growing out of control. Also,
ensure the archiving and purging job is running and is able to keep up with the rate at which data is
arriving.

Note
By default, the purge job is unable to delete data from the BizTalk Tracking database tables
until this data has been archived. If you do not need to archive the tracking data, you can
modify the job to purge the BizTalk Tracking database without archiving by following the steps
at http://go.microsoft.com/fwlink/?LinkId=118004.

See Also
Bottlenecks in the Database Tier

How to Identify Bottlenecks in the Tracking

Database
To identify bottlenecks in the BizTalk Tracking (BizTalkDTADb) database, perform the following steps:
1. Ensure that the SQL-Agent Service is running.
2. Ensure that the Archive/Purge Job is running and completing successfully.
3. Ensure that the TrackedMessages_Copy_BizTalkMsgBoxDB Job is running and completing
successfully.
4. Verify that sufficient free disk space is available for the DTADb archives and database growth.
5. Use a dedicated host for tracking and measure the Host Queue Length performance counter when
under load.
6. Check the Spool Table size performance counter for an increasing trend over time.
7. Check the Archive/Purge job execution duration for long execution times.
8. Check disk responsiveness (Disk Seconds per Read/Write performance counter) on the disk
hosting the BizTalk Tracking database.

See Also
Bottlenecks in the Database Tier

How to Identify Bottlenecks in the BAM

Database
To identify bottlenecks in the Business Activity Monitoring (BAM) databases, perform the following
steps:
1. Ensure that the Active Instances count is not climbing.
2. Ensure that the SQL-Agent Service is running.
3. If OLAP Analysis is configured ensure that the BAM_AN_<activityname> job is running at periodic
intervals.
4. Ensure that BAM_DM_<activityname> (Data Maintenance) job is scheduled to run at periodic
intervals.
5. Use an dedicated host for tracking and measure the Host Queue Length performance counter when
under load.
6. Check the Spool Table size performance counter for an increasing trend over time.
7. Check the Archive/Purge job execution duration for long execution times.
8. Check disk responsiveness (Disk Seconds per Read/Write performance counter) on the disk
hosting the BizTalk Tracking database.

See Also
Bottlenecks in the Database Tier

How to Avoid Disk Contention

BizTalk Server is designed as a persistent system. For high throughput scenarios, the MessageBox and
BizTalk Tracking databases can experience severe contention. This contention can be aggravated by
slow disks. If the disks are slow (greater than 15ms on average for Avg. Disk sec/Read or Avg. Disk
sec/Write), it may cause SQL Server to hold onto locks longer (high Lock Wait Time and high Lock
Timeouts). This, in turn, can cause the MessageBox tables (Spool and Application Queues) to grow,
causing database bloat and throttling. This situation ultimately results in lower overall sustainable
throughput.

Note
For information about identifying if a server has a disk bottleneck, and using the Microsoft
Server Performance Advisor (SPA) tool to determine if disk bottleneck exists, see "How To:
Identify a Disk Performance Bottleneck Using the Microsoft Server Performance Advisor (SPA)
Tool" at http://go.microsoft.com/fwlink/?LinkId=115283.
To avoid disk contention, do the following:

Steps Reference

Use Raid10/0+1 disk configurations. Best Practices for Avoiding Bottlenecks

If possible, deploy the databases on a high- Optimizing Filegroups for the Databases
speed SAN. If multiple databases are sharing
the same disks it is recommended to configure
them on separate dedicated disks. In addition,
it is recommended to separate the MDF and
LDF files for the MessageBox database onto
separate disks.
Consider allocating multiple files for the Pre-Configuration Database Optimization
TEMPDB database, as this will significantly
reduce disk contention and spread the load
across multiple data files.
Consider separating the MessageBox Post-Configuration Database Optimization
database onto a dedicated server that is
separate from the BizTalk Tracking databases.
Assign the MSDTC log file directory to a Optimizing Operating System Performance
separate dedicated drive.
If there is contention on the local drive due to Best Practices for Avoiding Bottlenecks
the PageFile or MSDTC log, try moving the
PageFile and/or the MSDTC log to a separate
drive.
Optimize the Tracking database for write How to Identify Bottlenecks in the Tracking
operations. Database
Optimize the MessageBox database for read How to Identify Bottlenecks in the MessageBox
and write operations. Database
If a BizTalk host instance is saturating the CPU, Optimizing BizTalk Server Performance
consider separating sending, receiving,
processing, and tracking functionality into
multiple hosts. This configures the system so
that the orchestration functionality runs on a
separate dedicated server to improve overall
system throughput.
 If multiple orchestrations are deployed, Optimizing BizTalk Server Performance
consider enlisting them in different dedicated
orchestration hosts. This isolates the different
orchestrations and prevents contention for
shared resources either in the same physical
address space or on the same server.
Consider using the Microsoft Server http://go.microsoft.com/fwlink/?LinkId=115283
Performance Advisor (SPA) to diagnose disk
contention issues. Use the SPA tool to identify
files and processes that cause disk contention.
Note
Use of this tool is not supported by
Microsoft, and Microsoft makes no
guarantees about the suitability of this
programs. Use of this program is
entirely at your own risk.

See Also
Bottlenecks in the Database Tier

Automating Testing
BizTalk Server solutions are often deployed in “mission critical” scenarios, whereby the BizTalk solution
is a core component of the business. In these scenarios, the continual performance and stability of the
BizTalk solution is key business requirement because if the BizTalk solution fails then the associated
downtime costs are significant. In such scenarios, it is of paramount importance that the BizTalk
solution is thoroughly tested before the solution is placed into production. The costs associated with
properly testing the solution are small compared to the downtime costs resulting from not testing or
insufficiently testing the solution. Therefore, the testing of a BizTalk Server solution is arguably the most
important phase of any BizTalk Server solution deployment.
This section describes the proper methodology for testing a BizTalk solution before running the solution
in a production environment.

In This Section
 Why Is It Important to Test?
 Automating the Build Process
 Using BizUnit for Automated Testing
Why Is It Important to Test?
This topic provides an overview of the mindset that leads to insufficient testing, describes the risks
associated with failing to test BizTalk solutions, and contrasts the pitfalls of manual testing with the
benefits of automated testing.

Testing as “overhead”
Unfortunately, with ever increasing demands for return on investment (ROI), the testing phase of a
project is often seen as one of the first aspects of a project plan that can be scaled back.
One argument against testing BizTalk solutions is that “We don’t need to test our solution because
Microsoft already thoroughly tests BizTalk Server.” While it is true that Microsoft does thoroughly test
BizTalk Server, different usage scenarios require one of an almost countless number of permutations of
business requirements for throughput, high availability, adapter usage, latency, tracking requirements,
orchestration usage, and custom code. Because BizTalk Server is extremely flexible and can
accommodate so many different usage scenarios, it is simply not possible to anticipate and test all of
them. Furthermore, the default settings that are applied in a BizTalk Server environment should be
optimized to accommodate each usage scenario. The only way to determine the optimal settings for a
particular usage scenario is to test the solution, measure various parameters, tune the environment,
and retest. Consider the following diagram, which depicts a sample physical architecture for a BizTalk
Server solution:

Sample Physical BizTalk Architecture

You can see in the diagram above that the BizTalk Server solution contains many moving parts,
including multiple BizTalk Servers, SQL Servers, server cluster nodes and Active Directory domains.
After the system is up and running, there will be many configuration tweaks applied to optimize the
application per the business requirements so as to maximize the overall ROI of the solution. When
viewing this single scenario, it is apparent that there are many variables in play. In addition to the
physical architecture of the environment, consider the following diagram, which depicts the flow of a
message through BizTalk Server:

Sample Logical BizTalk Message Flow

When we look at the logical diagram of a message flowing through BizTalk Server, we see other
variables that necessitate per-project testing, including custom send and receive pipeline components
and custom classes that can be called from BizTalk orchestrations. Given that the type complexity and
use of custom components and BizTalk components varies from project to project, it becomes more
evident why it is important to perform testing for each specific usage scenario.
Testing methodology and timelines
To ensure testing is performed effectively and efficiently, the test harness should be fully automated so
it is easily reproducible and minimizes the chance for human error. Additionally, adequate time should
be allotted for testing when planning the project. A minimalist approach to testing would comprise
manual steps similar to the following:
1. Manually load one or more messages into a receive end point, such as a file drop or by using a
SOAP client to call a Web service.
2. Manually validate the correct content and structure of a message. Because multiple schemas are
often present in a project, the messages may be a mixture of flat file and XML and may also contain
cross field dependencies.

Note
An example of this would be any project involving SWIFT messages, these are flat file
messages which have cross field dependencies (i.e. one field’s value depends on another
– simple XSD validation will not do here, hence the SWIFT Accelerator makes use of the
BizTalk Rules Engine for validation of the messages). For more information on the SWIFT
Accelerator, see http://go.microsoft.com/fwlink/?LinkID=79657.
3. Manually check the event logs on the BizTalk Server computers for errors.
4. Manually check the BAM databases (if used) to validate that activity information is recorded
correctly.
Using a manual process as described above for testing is subjective and error prone. Consider having
to examine a hundred line SWIFT message with cross field dependencies for 10 different test cases.
Most project developers would not be able to or even if they were able, would not be inclined to engage
in such a task reliably and accurately. Implementation of a subjective, manual, error prone testing
process adds risk to a project and increases the chance of failure.
The risk of failure is often amplified by project planning timelines that do not incorporate sufficient time
for testing. All too often, a project testing strategy hinges on a single manual test pass which is
scheduled a week or so before the go-live date. Such limited testing places the project at risk. Given
such a limited timeline for testing, if any problems are detected, then the project may be delayed
because no time has been allotted to fix problems. Furthermore, if a problem is discovered and fixed,
there may be insufficient time left to perform subsequent test passes before the system goes live.
The reality of “single final build, single test pass, take the project live” testing is that it often results in the
project being delayed, the project going over budget or even worse, the project failing completely! For
mission critical systems, this sort of testing methodology is a disaster waiting to happen.

Testing effectively and efficiently

Because appropriate testing is often viewed as an expensive luxury rather than a integral requirement,
it is all too often tacked on at the tail end of a project. Given the complexity of the software and
hardware stack used within heterogeneous enterprise environments, this approach is unrealistic.
Implementation of an automated test approach that can be re-run on demand is the best way to test
effectively and efficiently and is an integral component of successful projects that ultimately deliver an
excellent ROI to the business. By investing at the beginning of the project in full end-to-end functional
tests for each code path through the system you are generating test assets. These assets require
investment (i.e. development time) in order to reap the benefits of increased testing effectiveness and
efficiency later. To minimize the investment that is needed from the project to derive such a framework
we recommend that you utilize the BizUnit test framework. BizUnit includes the majority of the common
testing steps required for successful testing and is the framework used in the test scenarios presented
later in this guide.

Automating the Build Process

An automated build process compiles, deploys and then runs build verification tests (BVTs) against the
latest source code for a project at regular, predetermined intervals. Then a “build report,” which details
the success or failure of the build process, is disseminated to the project stakeholders. The build report
is analyzed to determine what areas of the project need attention and/or if the project should be rolled
back to an earlier version/build.
The power of an automated build process is it can be scheduled to be run during “off hours” so it can
help ensure the stability of the project without taking cycles directly away from the development time.
This topic provides an overview of the build process, describes how build verification testing fits into the
build process, describes aspects of functional testing used during build verification testing and provides
information about the importance of automating the build process.

Overview of the build process

Before looking into the specifics of testing, it’s important to consider the context of how testing fits into
the overall build process. All of Microsoft’s product groups operate from the philosophy that the build
process is the heartbeat of any software project. This approach is also used by many of the world’s top
consulting firms that build mission critical solutions on top of the Microsoft software stack. Without a
steady heartbeat and a regular check of it, it is impossible to know the health of the project. To ensure
the product groups have a continuous insight into the overall health of the project the build process is
run daily, typically at midnight. The steps below summarize a typical automated build process:
1. Obtain latest build of source code from source code repository.
2. Compile the source code.
3. Pack up binaries for deployment – typically using scripts or Microsoft® Windows® Installer files.
4. Deploy project to a test server.
5. Automatically run a full set of build verification tests (BVTs).
6. Publish a detailed build report to members of the project team.
 Note
BVTs are functional tests that exercise the main features of the solution to test its quality. You
need to ensure your BVTs are comprehensive enough to gauge the build quality, yet small
enough to execute within the allocated daily build time!

Note
You should also treat any deployment, un-deployment, configuration and installation scripts or
processes as part of the software project for testing purposes. Both the operations of the
project, as well as the deployment and configuration of it, should be tested.
This process is typically completed by early morning around 6 A.M., which enables the first members of
the team to start work on the new day’s build. If one or more of the BVTs from the previous night failed,
then it is the team’s responsibility to fix it as soon as possible.
Following a daily build process has many advantages for the project. First, it provides a regular
heartbeat (made up of the daily build plus the automated BVTs). Second, using BVTs forces integration
with systems, this is a tricky task and doing this early in and of itself reduces project risks. Due to the
time required to complete them, stress and performance testing are typically performed outside of the
daily build process. Stress and performance tests are typically scheduled to be performed on milestone
build in the project.
The daily build process can be and has been used very effectively on BizTalk solutions. However, you
need to ensure tasks that are typically left to the end in projects are done iteratively from the start. For
example, deployment in BizTalk Server is certainly non-trivial. It is important automated deployment
scripts be developed up front. If you do not do this, you’ll end up manually deploying and un-deploying
the solution many times throughout the project, which will cost you more time in the end. There are
tools available to drive the daily build process; Visual Studio Team System and Team Foundation
Server are the primary choice for many people. MSBuild script(s) may be used to drive the steps in the
build process. Another alternative is the open source CruiseControl.NET tool, which is available at
http://go.microsoft.com/fwlink/?LinkId=116093.

Note
Use of this tool is not supported by Microsoft, and Microsoft makes no guarantees about the
suitability of this programs. Use of this program is entirely at your own risk.
For more information about automating testing using Visual Studio Team System, see the topic "Testing
Tools Tasks" in the Visual Studio Team System online documentation at http://go.microsoft.com/fwlink/?
LinkId=120226. For more information about automating the build process using Visual Studio Team
System, see "Managing Builds with Team Foundation Build" in the Visual Studio Team System
documentation at http://go.microsoft.com/fwlink/?LinkId=116130.

Build verification testing

Build verification testing usually comprises the following elements:
 Unit Tests - As unit tests are typically the first tests to be developed, ideally they should be created
before the code has actually been written if you are truly using a test-driven development approach.
 By adding them into BVTs during the early stages of a project, you provide at least some code
coverage immediately. As the number of functional tests and hence test coverage grows, you may
opt to remove unit tests from the BVTs.
 Smoke Tests - End-to-end functional tests that test the basic functionality of your solution. If these
fail, something is seriously wrong. These can usually be run relatively quickly.
 Functional Tests - These also target end-to-end scenarios, but in this case they test all the
scenarios in the project. For large projects it may make sense to categorize your functional tests
further (e.g. to enable a particular component to be tested quickly, reliably and in isolation). These
functional tests should be locked down after you have signed off on your solution as being
functionally correct.
 Regression Verification Tests - Every time a solution bug is found and fixed, regression
verification test cases should be added to verify the bug is fixed and it is not reintroduced later in
the project lifecycle. These tests will typically be edge cases that were not covered in the functional
test cases. You should expect your regression verification tests will increase in number even after
the solution has gone live, if new bugs are discovered and fixed.
On very large projects, you may need to make your BVTs a subset of the full functional test suite (due
to length of time they take to execute). For smaller projects, BVTs will constitute the entire set.
Obviously, if you are going to integrate the BVTs as part of your daily build, then the whole process
needs to be automated. In the rest of this section, we will focus on how you can use BizUnit and other
tools to accomplish this.

Functional testing
In the context of BizTalk applications functional tests, test a specific end-to-end scenario. When
performing this type of testing, it is useful to imagine BizTalk Server as a black box you test functionally
from an external perspective. For example, a test may involve feeding an input message (with known
values) to a receive location end point (e.g. URL, FTP location, whatever your choice of transport is).
The test would then monitor the correct number of messages with the correct output that are produced
on the send side. This may sound relatively straightforward, but when you consider some scenarios
require inputs to come in a certain order and at a certain time and you compound this with other
solution requirements, such as, when recording tracking data in BAM, it becomes clear this is a classic
case where a tool and framework can be used to orchestrate this.
It is critical functional testing is designed to cover all the possible paths through your solution. This
should include not only those scenarios you expect in production, but also the failure paths and
exception handling paths you have implemented but hope never to use – one phrase commonly used to
describe this is testing for the “bad day scenario.” You should ensure all orchestrations, all permissible
message types, and all code branches are exercised by your functional test suite. The following
sections describe developing positive and negative functional test cases to cover all code paths.
For more information about functional testing and the other testing categories should be implemented
before placing a BizTalk Server solution into production, see the topic “Checklist: Testing Operational
Readiness” in the BizTalk Server Operations Guide at http://go.microsoft.com/fwlink/?LinkId=116064.
Positive tests
 It is important when performing positive tests to ensure all combinations of messages, pipelines,
orchestrations and endpoints are passed through the solution to make sure all the message flows
are exercised. To ensure you test all code paths will likely require you process different messages
with different content.
 When testing, use the transport type will be used in production. Unfortunately all too often functional
testing is performed only using the file adapter when some other transport will be used in
production. Adopting this approach is setting you and the overall project up for failure later on.
 Validate the payload of all messages that are sent out from the system. If the messages are XML,
you should validate their schema and key fields in the message using XPath expressions.
 Validate any tracking data stored in BAM (if used) or any other data should be left in external data
repositories is accounted for.
 Test the execution of all Business Rule Engine (BRE) policies and rules if your solution uses BRE.

Negative tests
 Ensure you test the handling of invalid messages through your system. You should verify your
chosen strategy (to reject them before they come into BizTalk Server or to suspend them) has
worked correctly.
 When testing the handling of invalid messages, ensure you test any receive-side error handling
orchestrations have been implemented to handle suspended messages.
 Ensure your failure scenarios cover all exception blocks in your orchestrations. Failing to test this
adequately is a common problem.
 If you are using long-running transactions with compensation behavior, test these scenarios very
carefully. This is another area where inadequate testing will incur serious consequences in a
production environment.
 Ensure failures are logged correctly in the appropriate error logs.

Automation is key
In order to do all of this efficiently and effectively, invest the time upfront to automate testing. Manual
testing is time consuming, error prone, and expensive (in terms of time and cost). Every time you
perform a manual test pass, you add another batch of tasks that have to be handled by project
resources (i.e. people in the team). By automating this up front, you are able to get a return on the
upfront investment that is required to develop the tests every time they are run. Good functional tests
should execute quickly and efficiently and be repeatable; each test should also be autonomous (i.e.
independent of any other, adopting this approach enables you to run multiple tests sequentially as a
test suite). The functional tests should always produce the same result, as poorly written functional
tests or poorly written code will result in different tests results between test runs, leading to confusion
and wasted time investigating the root cause of the failure.
It is important to minimize the development effort required to write each functional test. Usually the
more expensive it is to produce something (in terms of development time), the fewer test cases you are
likely to end up with. This means you will have a lower level of test coverage over your code. By
utilizing a test framework, you can develop test cases quicker and easier and, hence, make it easier to
get full code coverage. Most good test frameworks use a declarative approach to defining tests (i.e. the
configuration for a test is stored in a configuration file which is typically an XML file). Utilizing a good
test framework enables you to develop a full functional test suite in an agile and reliable manner and
avoids having to “reinvent the wheel” over and over, so to speak.

Using BizUnit for Automated Testing

BizUnit is a declarative test framework that is designed to enable you to rapidly build test cases for your
project. Declarative in this context means that the user authors the BizUnit test case in XML, by doing
this they are configuring how the test framework will execute for that particular test case. The XML test
case is executed by BizUnit every time the test is executed; this means that the test can be changed by
modifying the XML there is no need to recompile the test. BizUnit requires a driver to host and execute
the framework; this driver is responsible for telling it which test cases need to be run. This can be done
in a number of ways: you could write.NET code to drive BizUnit, or simply use Visual Studio 2005 Unit
Testing, which is included with the Visual Studio Team System (VSTS) release of the product. BizUnit
does not depend on VSTS unit testing, but it does make a great BizUnit host.
This section describes BizUnit in greater detail, provides a walkthrough of using BizUnit to test one of
the BizTalk Server Business Process Management (BPM) scenarios, and provides information on using
the BizTalk Server LoadGen 2007 Tool in conjunction with BizUnit for performance and stability testing.

In This Section
 Stages of a BizUnit Test Case
 Defining Tests Using an XML Configuration File
 Automating Performance and Stability Testing
 Using BizUnit with the Business Process Management Scenario

Stages of a BizUnit Test Case

Each BizUnit test case consists of three stages, which are TestSetup, TestExecution and
TestCleanup. Each stage contains one or more test steps that are responsible for performing a single
discrete unit of work; for example, the FileCreateStep is responsible for creating a file in a location you
specify with a given filename. BizUnit includes over 70 test steps and also provides extension
capabilities which allow new test steps to be easily added to the framework. The ability to add new
steps to the framework allows BizUnit to be used across a broad range of scenarios. This topic
describes the BizUnit test stages in further detail.

Setup Stage
This setup stage prepares the platform for the testing. For example, before a particular test can be run,
a file may need to be copied to a file drop in preparation for the actual execution of the test. You could
also use this stage to cleanup any file locations or database tables that will be used in the test. As with
every stage in BizUnit, there is no limit to the number of test steps that can be added, which provides
the flexibility required to handle complex scenarios.

Execution Stage
The execution stage is where the test is actually run. This is where the function of the system you are
validating is actually tested.

Cleanup Stage
The cleanup stage is the container for test steps that returns the platform to the consistent state that it
was in before you ran the test. This stage is always executed, even if an error occurs in the execution
stage. The reason the platform should be returned to its starting point is to prevent one test case from
interfering with another so that each test case is run autonomously as part of the test suite. Ensuring a
complete cleanup of the system at this stage is one of the guiding principles for effective testing with
BizUnit.
The diagram below illustrates the format of a sample test case, which contains test steps in the three
stages: setup, execution, and cleanup. It is important to always follow this structure when defining test
cases with BizUnit.
Stages of a BizUnit test

Defining Tests Using an XML Configuration File

BizUnit offers two ways to define tests: via an XML configuration file and via an Excel Spreadsheet.
This topic focuses on using an XML configuration file to define tests, however, we also encourage you
to look at the BizUnit SDK as it provides an interesting example of how to define BizUnit test cases
using Excel. You may also wish to investigate the BizUnit Designer tool, which provides a GUI that
allows for rapid creation of BizUnit test cases. This topic provides an overview of how to define test
cases using XML configuration using a very simplified scenario. If you are already familiar with BizUnit,
you may want to skip this topic and proceed to the detailed end-to-end scenario described in Using
BizUnit with the Business Process Management Scenario.

Overview of defining a BizUnit test case using XML

configuration
As stated above, this scenario is simplified for purposes of illustration. Consider a sample messaging
application such as the one illustrated below. Let’s assume that normal functional behavior for this
application is that BizTalk receives an XML file via a file receive location, it then sends it to an
appropriate subscriber based on a subscription. To validate this scenario effectively it is important that
we perform the following steps in the test:
1. Setup the environment to ensure that it is in a consistent state and ready for the test to be run:
  This is done by deleting any files that are present in the two file locations used.
2. Execute the test to verify functionality:
 Create a valid XML message in the folder that the file receive location polls.
 Validate that the correct XML message is placed in the outbound folder location.
 The validation should cover both the schema and the payload information for the message
(typically a couple of the key fields should be examined).
3. Cleanup the environment to ensure that the environment is in the same state as before the test
executed:
 Delete any files that are present in the two file locations used.

Sample BizTalk Messaging application

Each test case begins and ends with the TestCase XML tag, the testName parameter is passed into this
as indicated below:
<TestCase testName="Test_01_FILECopyWithXmlValidation">

Then we enter the TestSetup phase, in which we ensure that the environment is in a consistent state to
run the test. In this example, we delete any XML messages that are contained in our TestData directory.
This is done using the FileDeleteMultipleStep:
<TestSetup>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileDeleteMultipleStep">

<Directory>..\..\..\TestData\</Directory>

<SearchPattern>*.xml</SearchPattern>

</TestStep>

</TestSetup>

We then enter what is the most critical section of the test, the test execution stage. This stage can
contain multiple test steps. In this example we use the FileCreateStep to cope a document (InDoc1.xml
which can be seen in the <SourcePath> tag) to a file drop which is used by out receive location. It’s
important to note that BizUnit supports using unique identifiers for filenames in this step, this can be
seen with the %Guid% reference in the CreationPath tag.
After this has been completed, we need to use the FileValidateStep to validate the outbound message
has been created. You will notice this step allows you to specify a timeout value (this is in milliseconds),
the directory and the search pattern. In addition to this, the DeleteFile tag enables you to specify
whether you want the file to be removed after it has been validated. Finally, you should also note the
validation includes an XPath query, which validates the PONumber node within the XML message (it
checks that the value is PONumber_0.) Examination and validation of the payload of any outbound
messages is another example of a guiding principle that you should follow when using BizUnit.
<TestExecution>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileCreateStep">

<SourcePath>..\..\..\TestData\InDoc1.xml</SourcePath>

<CreationPath>..\..\..\Rec_03\TransactionId_%Guid%.xml</CreationPath>

</TestStep>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileValidateStep">

<Timeout>3000</Timeout>

<Directory>..\..\..\Rec_03\</Directory>

<SearchPattern>TransactionId_*.xml</SearchPattern>

<DeleteFile>true</DeleteFile>

<ValidationStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.XmlValidationStep">

<XmlSchemaPath>..\..\..\TestData\PurchaseOrder.xsd</XmlSchemaPath>

<XmlSchemaNameSpace>http://SendMail.PurchaseOrder</XmlSchemaNameSpace>

<XPathList>

<XPathValidation query="/*[local-name()='PurchaseOrder' and namespace-

uri()='http://SendMail.PurchaseOrder']/*[local-name()='PONumber' and namespace-
uri()='']">PONumber_0</XPathValidation>

</XPathList>

</ValidationStep>

</TestStep>

</TestExecution>

The final stage of the test case is the cleanup. As can be seen below, the FileDelete test step is used to
clean up the directories used by the test.
<TestCleanup>
 <TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileDeleteMultipleStep">

<Directory>..\..\..\TestData\</Directory>

<SearchPattern>*.xml</SearchPattern>

</TestStep>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileDeleteMultipleStep">

<Directory>..\..\..\Rec_03\</Directory>

<SearchPattern>*.xml</SearchPattern>

</TestStep>

</TestCleanup>

Hopefully this example illustrates that defining tests in BizUnit is relatively straightforward and that by
using this test framework, you will be able to rapidly develop test cases to provide functional testing of
your application.

Full test case example

The full test case configuration file contents are included below for your reference:
<TestCase testName="Test_01_FILECopyWithXmlValidation">

<TestSetup>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileDeleteMultipleStep">

<Directory>..\..\..\TestData\</Directory>

<SearchPattern>*.xml</SearchPattern>

</TestStep>

</TestSetup>

<TestExecution>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileCreateStep">

<SourcePath>..\..\..\TestData\InDoc1.xml</SourcePath>

<CreationPath>..\..\..\Rec_03\TransactionId_%Guid%.xml</CreationPath>

</TestStep>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileValidateStep">

<Timeout>3000</Timeout>

<Directory>..\..\..\Rec_03\</Directory>
 <SearchPattern>TransactionId_*.xml</SearchPattern>

<DeleteFile>true</DeleteFile>

<ValidationStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.XmlValidationStep">

<XmlSchemaPath>..\..\..\TestData\PurchaseOrder.xsd</XmlSchemaPath>

<XmlSchemaNameSpace>http://SendMail.PurchaseOrder</XmlSchemaNameSpace>

<XPathList>

<XPathValidation query="/*[local-name()='PurchaseOrder' and namespace-

uri()='http://SendMail.PurchaseOrder']/*[local-name()='PONumber' and namespace-
uri()='']">PONumber_0</XPathValidation>

</XPathList>

</ValidationStep>

</TestStep>

</TestExecution>

<!-- Test cleanup: test cases should always leave the system in the state they found it -->

<TestCleanup>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileDeleteMultipleStep">

<Directory>..\..\..\TestData\</Directory>

<SearchPattern>*.xml</SearchPattern>

</TestStep>

<TestStep assemblyPath=""
typeName="Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileDeleteMultipleStep">

<Directory>..\..\..\Rec_03\</Directory>

<SearchPattern>*.xml</SearchPattern>

</TestStep>

</TestCleanup>

</TestCase>

Automating Performance and Stability Testing

This topic provides information on how to use the Microsoft BizTalk LoadGen 2007 tool with BizUnit to
automate performance and stability testing of a BizTalk Server solution.
BizTalk Server performance testing, step-by-step
Before investigating how to automate BizTalk Server performance testing it is useful to know what steps
that are typically performed in a performance test. The following steps are representative of a “typical”
BizTalk Server performance testing process:
1. Create a test results directory to store results and data collected, for example event logs, trace logs,
Performance Monitor data.
2. Clear the event logs on all servers within the test environment.
3. Stop all BizTalk host instances.
4. Stop any IIS instances that are running isolated BizTalk hosts such as the SOAP and HTTP receive
adapter handlers.
5. Restart all instances of SQL Server used by the BizTalk Servers.
6. Clean up the Message Box database to ensure that there is no left over data from previous tests
runs. This is important as any leftover data could skew test results.
7. Start the BizTalk host instances.
8. Start the relevant Performance Monitor counters on all servers in the test environment.
9. Send “priming” messages through the system to initialize the system caches.
10. After the priming messages have been processed, track the test start time in a SQL test results
database.
11. Start the performance test by starting all of the LoadGen test agents.
12. Wait for the test to complete – often this can be done systematically by measuring the value of a
Performance Monitor counter such as host queue length.
13. Track test end time in a SQL test results database.
14. Stop the relevant Performance Monitor counters on all servers in the test environment.
15. Save the test data to the test results directory that was created earlier.
16. Perform any necessary cleanup for the next test run.
Each and every one of the steps listed above can be automated using BizUnit. By utilizing the existing
test step assets that BizUnit provides you can quickly and easily generate an automated performance
test for a BizTalk Server solution. One of the primary benefits of automating performance testing using
BizUnit is the flexibility to run tests overnight – meaning that the results are ready for analysis in the
morning. This greatly reduces the burden of performance testing on a project team.

The Microsoft BizTalk LoadGen 2007 tool

Overview of LoadGen
The BizTalk LoadGen 2007 tool (LoadGen) is a load testing tool that was developed by the Stress and
Performance Testing team in the BizTalk Server 2006 product group. LoadGen was designed to quickly,
easily and reliably define load tests that simulate production level message volumes. LoadGen is multi-
threaded, configuration driven and supports multiple transports. LoadGen is used by BizTalk product
group on a daily basis; therefore you can have a high degree of confidence that the tool is durable, fit
for the purpose and able to simulate a wide variety of BizTalk scenarios.
LoadGen employs a modular design that consists of three layers, presentation, framework and
component. The presentation layer consists of a command line driver, which is responsible for driving
the framework. The framework layer reads a configuration file and then executes the components
specified therein. The component layer consists of three types of components; load generators,
message creators and throttle controllers. Each of these components is extensible, so you can
create your own and plug them into LoadGen to address the needs of your scenario. Because LoadGen
was developed by the BizTalk Server product group, you should find that the out of the box components
will fulfill most of your load testing requirements. Each of thes components is described in greater detail
below:
 Load generators are responsible for transmitting messages via a particular transport. Load
generators are provided for the following transports:
 File
 HTTP
 MQSeries
 MSMQLarge
 MSMQ
 SOAP
 Web Services Enhancements (WSE)
 Windows SharePoint Services (WSS)
 Windows Communication Foundation (WCF)
 Message creators are an optional component that can be used when you need to generate
messages that contain unique data. Message creators use one of two modes of creation;
synchronous and asynchronous. If the synchronous message creation mode is specified, then
LoadGen uses only a single thread to create messages to ensure that each message contains a
unique payload. While the synchronous mode guarantees unique data within each message, this
mode also limits scalability. LoadGen also provides asynchronous message creators that use
multiple execution threads; this enables LoadGen to meet the target message rate (because it can
simply create more threads). In asynchronous mode the message creator may be configured to
randomly modify data for each individual message, but because it uses multiple threads it does not
guarantee that all message generated during the test will contain a unique payload.
 Throttle controllers ensure that messages are transmitted at a steady rate by governing the load
generators while the test is running. LoadGen also exposes custom throttling, which enables you to
control the flow of messages based on criteria including:
 Number of files in a folder
 Number of rows in a database table
  Depth of an MSMQ or MQSeries message queue
The Microsoft BizTalk LoadGen 2007 tool is available for download at http://go.microsoft.com/fwlink/?
LinkId=59841.

Sample LoadGen configuration file

All LoadGen configuration information is stored in an xml file. The LoadGen configuration file contains a
<CommonSection> element that configures the default settings for all LoadGen tasks in the LoadGen
scenario. The LoadGen configuration file can also contain one or more <Section> elements that provide
configuration settings for a specific LoadGen task. Entries in a <Section> element supersede any
default values specified in the <CommonSection> element.
The sample LoadGen configuration file below is slightly modified version of the FileToFileLG.xml
sample configuration file that is included in the \ConfigFiles\ConsoleConfigFiles subdirectory of the
LoadGen installation directory. This test sends 25 messages <LotSizePerInterval> every 200
milliseconds <SleepInterval>, 5 threads per load generator <NumThreadsperSection>and will stop the
load test after 5000 messages <NumFiles> have been sent.
The file throttle controller is specified in the <ThrottleController> section. The value for
<ThresholdRange> is set to 1000-2000, which means that if the file location
C:\Scenarios\FileToFile\Receive (Parameters) has less than 1000 or more than 2000 files, the throttle
controller will throttle the file generator and increase/decrease load as appropriate. The number of files
in the file location will be checked every 1000 milliseconds <SleepInterval>. The <FileSection> element
defines the properties for the messages to be sent by the load generators. The FileToFileLG.xml file
<SrcFilePath> will be copied by LoadGen to the filedrop C:\Scenarios\FileToFile\Receive
<DstFilePath>. The file transport is used here as this is the default transport specified in the <Transport
Name> element within the <CommonSection> element.
<LoadGenFramework>

<CommonSection>

<LoadGenVersion>2</LoadGenVersion>

<OptimizeLimitFileSize>204800</OptimizeLimitFileSize>

<NumThreadsPerSection>5</NumThreadsPerSection>

<SleepInterval>200</SleepInterval>

<LotSizePerInterval>25</LotSizePerInterval>

<RetryInterval>10000</RetryInterval>

<StopMode Mode="Files">

<NumFiles>5000</NumFiles>

</StopMode>

<Transport Name="FILE">

<Assembly>FileTransport.dll/FileTransport.FileTransport</Assembly>
 </Transport>

<ThrottleController Mode="Custom">

<Monitor Name="File">

<Assembly>FileMonitor.dll/DropLocationFileMonitor.DropLocationFileMonitor</Assembly>

<ThresholdRange>1000-2000</ThresholdRange>

<SleepInterval>1000</SleepInterval>

<Parameters>C:\Scenarios\FileToFile\Receive</Parameters>

</Monitor>

<ThrottleCondition>File</ThrottleCondition>

</ThrottleController>

</CommonSection>

<Section Name="FileSection">

<SrcFilePath>C:\LoadGen\ConfigFiles\ConsoleConfigFiles\FileToFileLG.xml</SrcFilePath>

<DstLocation>

<Parameters>

<DstFilePath>C:\Scenarios\FileToFile\Receive</DstFilePath>

</Parameters>

</DstLocation>

</Section>

</LoadGenFramework>

Using BizUnit to drive LoadGen

BizUnit provides the LoadGenExecuteStep to facilitate automated performance and stability testing.
The TestExecution stage of a sample BizUnit configuration file that uses LoadGenExecuteStep is
shown below. Note that this step accepts a single configuration parameter which is the location of the
LoadGen configuration file:
<TestCase testName="Test_LoadGen">

<TestSetup>

</TestSetup>

<TestExecution>

<TestStep assemblyPath="" typeName="BizUnit.LoadGenExecuteStep, BizUnit.LoadGenSteps">

<LoadGenTestConfig>..\..\..\PerfGuideFiletoFile.xml</LoadGenTestConfig>

</TestStep>
 </TestExecution>

<!-- Test cleanup: test cases should always leave the system in the state they found it -->

<TestCleanup>

</TestCleanup>

</TestCase>

The remainder of this topic describes the configuration file for a BizUnit test case that automates
performance testing with Loadgen.

Note
This configuration file can be used as a template to quickly integrate BizUnit and Loadgen as
part of your performance testing. Before running this test case you will need to customize the
configuration file for your environment. Sections of the configuration file that must be
customized are indicated accordingly.
To begin with, specify a value for the testName parameter that is appropriate for the BizTalk solution:
<TestCase testName="Performance-Guide-Sample-Loadgen-Test">

Then add context variables to the TestSetup stage. These context variables will be referenced
throughout the duration of the test case. To use this configuration file, modify the values specified for
TestCaseResultsDir (C:\Dev Work\Perf Guide Demos\PerfResults\) and Machine (BIZTALKADMIN01)
to match your environment.
<TestSetup>

<!-- Context property: name of test run -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="TestRunName">

<ItemTest takeFromCtx="BizUnitTestCaseName"></ItemTest>

<ItemTest>_%DateTime%</ItemTest>

</ContextItem>

</TestStep>

<!-- Context property: name of test directory to store results -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="TestCaseResultsDir">

<ItemTest>C:\Dev Work\Perf Guide Demos\PerfResults\</ItemTest>

<ItemTest takeFromCtx="TestRunName"></ItemTest>

</ContextItem>

</TestStep>

<!-- Context property: perfmon log file -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

 <ContextItem contextKey="PerfMonFilePath">

<ItemTest takeFromCtx="TestCaseResultsDir"></ItemTest>

<ItemTest>\PerfCounters.blg</ItemTest>

</ContextItem>

</TestStep>

<!-- Context property: destintation for app event log on test computer -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="DestPath- BIZTALKADMIN01-AppEventLog">

<ItemTest takeFromCtx="TestCaseResultsDir"></ItemTest>

<ItemTest> BIZTALKADMIN01_ApplicationLog.evt</ItemTest>

</ContextItem>

</TestStep>

<!-- Clear the application event log on test computer -->

<TestStep assemblyPath="" typeName="BizUnit.EventLogClearStep">

<Machine>BIZTALKADMIN01</Machine>

<EventLog>Application</EventLog>

</TestStep>

<!-- Create the directory to save all the test results -->

<TestStep assemblyPath="" typeName="BizUnit.CreateDirectory">

<DirectoryName takeFromCtx="TestCaseResultsDir" ></DirectoryName>

</TestStep>

</TestSetup>

After completing the TestSetup stage, we enter the TestExecution stage. The first thing we do in this
stage is stop the BizTalk host instances. A separate BizUnit.HostConductorStep section must be
added for each distinct host instance. If you are using this configuration file in your environment, you
will also need to enter the appropriate values for HostInstanceName, Server, Logon, and Password:
<TestExecution>

<!-- Step 1: Stop BizTalk Hosts -->

<TestStep assemblyPath="" typeName="BizUnit.HostConductorStep, BizUnit.BizTalkSteps">

<Action>stop</Action>

<HostInstanceName>BizTalkServerApplication</HostInstanceName>

<Server>BizTalkAdmin01</Server>

<Logon>ServerName\Administrator</Logon>

<PassWord>Pass@word1</PassWord>
 <GrantLogOnAsService>true</GrantLogOnAsService>

</TestStep>

After stopping all of the host instances, we clean up the BizTalk MessageBox database using the
bts_CleanupMsgBox stored procedure. In order to use this step you must modify the value for
ConnectionString to match your environment:
<!-- Step 2: Clean Up MessageBox -->

<TestStep assemblyPath="" typeName="BizUnit.DBExecuteNonQueryStep">

<DelayBeforeExecution>1</DelayBeforeExecution>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=BizTalkMsgBoxDb;server=BIZTALKADMIN01;Connect
Timeout=30</ConnectionString>

<SQLQuery>

<RawSQLQuery>[dbo].[bts_CleanupMsgbox]</RawSQLQuery>

</SQLQuery>

</TestStep>

Step 3 of the TestExecution stage starts Performance Monitor counters that are specified in a
template file. A sample template file is listed underneath the sample BizUnit.PerfmonCountersStep
below. To use the template file you must modify the value specified for CountersListFilePath to match
your environment. Modify the sample performance monitor counter template file to include any perfmon
counters that you would like to monitor or remove any that are not relevant to your scenario:
<!-- Step 3: Start Perfmon counters -->

<TestStep assemblyPath="" typeName="BizUnit.PerfmonCountersStep">

<PerfmonAction>Start</PerfmonAction>

<CounterSetName>PerfGuidePerfmonCounters</CounterSetName>

<CountersListFilePath>C:\Dev Work\Perf Guide

Demos\Test_06_PerfCounters.txt</CountersListFilePath>

<SampleInterval>5</SampleInterval>

<PerfmonLogFilePath takeFromCtx="PerfMonFilePath"></PerfmonLogFilePath>

</TestStep>

Sample Performance Monitor counter template file (Test_06_PerfCounters.txt referenced by the

BizUnit.PerfmonCountersStep):
\Processor(*)\*

\Process(*)\*

\Memory\*

\PhysicalDisk(*)\*
\System\Context Switches/sec

\System\Processor Queue Length

\BizTalk:FILE Receive Adapter(*)\*

\BizTalk:File Send Adapter(*)\*

\BizTalk:FTP Receive Adapter(*)\*

\BizTalk:FTP Send Adapter(*)\*

\BizTalk:HTTP Receive Adapter(*)\*

\BizTalk:HTTP Send Adapter(*)\*

\BizTalk:Message Agent(*)\*

\BizTalk:Messaging(*)\*

\BizTalk:Message Box:General Counters(*)\*

\BizTalk:Message Box:Host Counters(*)\*

\BizTalk:Messaging Latency(*)\*

\BizTalk:SOAP Receive Adapter(*)\*

\BizTalk:SOAP Send Adapter(*)\*

\BizTalk:TDDS(*)\*

\XLANG/s Orchestrations(*)\*

Now we start the BizTalk Server host instances. A separate BizUnit.HostConductorStep section must
be added for each distinct host instance (distinct includes multiple instances of a host across servers). If
you are using this configuration file in your environment, you will also need to enter the appropriate
values for HostInstanceName, Server, Logon, and Password:
<!-- Step 4: Start BizTalk Hosts -->

<TestStep assemblyPath="" typeName="BizUnit.BizTalkSteps.HostConductorStep,

BizUnit.BizTalkSteps, Version=3.0.0.0, Culture=neutral, PublicKeyToken=7eb7d82981ae5162">

<Action>start</Action>

<HostInstanceName>BizTalkServerApplication</HostInstanceName>

<Server>BizTalkAdmin01</Server>

<Logon>ServerName\Administrator</Logon>

<PassWord>Pass@word1</PassWord>

<GrantLogOnAsService>true</GrantLogOnAsService>

</TestStep>

Step 5 “primes” the system by sending a couple of messages to BizTalk Server using
BizUnit.LoadGenExecuteStep, change the value of the LoadGenTestConfig parameter to match
your environment. Step 6 writes the LoadGen configuration file to memory so that it can written to the
test results database when the test is complete:
<!-- Step 5: Send Priming messages -->

<TestStep assemblyPath="" typeName="BizUnit.LoadGenExecuteStep, BizUnit.LoadGenSteps">

<LoadGenTestConfig>C:\Program
Files\LoadGen\ConfigFiles\ConsoleConfigFiles\PerfGuideFiletoFile.xml</LoadGenTestConfig>

</TestStep>

<!-- Step 6: Read loadgen file into context variable -->

<TestStep assemblyPath="" typeName="BizUnit.FileReadAndLoadToContext">

<FilePath>C:\Program
Files\LoadGen\ConfigFiles\ConsoleConfigFiles\PerfGuideFiletoFile.xml</FilePath>

<ContextPropertyName>LoadGenFileContent</ContextPropertyName>

</TestStep>

Now we write the test start time to a test results database. Modify the ConnectionString and
RawSQLQuery parameters to match your environment:
<!-- Step 7: Update test results DB with test start time -->

<TestStep assemblyPath="" typeName="BizUnit.DBExecuteNonQueryStep">

<DelayBeforeExecution>1</DelayBeforeExecution>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=TestResults;server=BizTalkAdmin01;Connect Timeout=30</ConnectionString>

<SQLQuery>

<RawSQLQuery>INSERT INTO tblPerformanceResults (Test_ID, StartTime,LoadGenFile) VALUES

('{0}',GetDate(),'{1}' )</RawSQLQuery>

<SQLQueryParams>

<SQLQueryParam takeFromCtx="TestRunName"></SQLQueryParam>

<SQLQueryParam takeFromCtx="LoadGenFileContent"></SQLQueryParam>

</SQLQueryParams>

</SQLQuery>

</TestStep>

Step 8 is where the actual performance test is initiated using BizUnit.LoadGenExecuteStep. This step
specifies the same LoadGen configuration file that was used in step 5 but you can specify any valid
LoadGen configuration file here. BizUnit.DelayStep is used in step 9 to impose a 5 second delay to
allow time for messages to start flowing through the system. Host queue length is calculated using
BizUnit.PerMonCounterMonitorStep. When this parameter reaches a value of 1 as specified in step
10, the test is concluded. Change the values for the InstanceName and Server parameters to match
the name of the host instance and server that you would like to monitor in your environment.
<!-- Step 8: LoadGen: Load actual perf test -->
<TestStep assemblyPath="" typeName="BizUnit.LoadGenSteps.LoadGenExecuteStep,
BizUnit.LoadGenSteps , Version=3.0.0.0, Culture=neutral, PublicKeyToken=7eb7d82981ae5162">

<LoadGenTestConfig>C:\Program
Files\LoadGen\ConfigFiles\ConsoleConfigFiles\PerfGuideFiletoFile.xml</LoadGenTestConfig>

</TestStep>

<!-- Step 9: Delay for 5 secs to allow msgs to start flowing -->

<TestStep assemblyPath="" typeName="BizUnit.DelayStep">

<Delay>5000</Delay>

</TestStep>

<!-- Step 10: Wait for Orch Host Queue depth to reach one -->

<TestStep assemblyPath="" typeName="BizUnit.PerfMonCounterMonitorStep">

<CategoryName>BizTalk:Message Box:Host Counters</CategoryName>

<CounterName>Host Queue - Length</CounterName>

<InstanceName>BizTalkServerApplication:biztalkmsgboxdb:BizTalkAdmin01</InstanceName>

<Server>BizTalkAdmin01</Server>

<CounterTargetValue>1</CounterTargetValue>

</TestStep>

At the conclusion of the test we use BizUnit.DBExecuteNonQueryStep to update the test results
database. Completion of this step signifies the end of the test execution stage, as indicated by the
closing </TestExecution> tag. Again, you must modify the ConnectionString and RawSQLQuery
parameters to match your environment.
<!-- Step 11: Update test results DB with test stop time -->

<TestStep assemblyPath="" typeName="BizUnit.DBExecuteNonQueryStep">

<DelayBeforeExecution>1</DelayBeforeExecution>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=TestResults;server=BIZTALKADMIN01;Connect Timeout=30</ConnectionString>

<SQLQuery>

<RawSQLQuery>UPDATE tblPerformanceResults SET EndTime = GetDate() WHERE Test_ID =

'{0}'</RawSQLQuery>

<SQLQueryParams>

<SQLQueryParam takeFromCtx="TestRunName"></SQLQueryParam>

</SQLQueryParams>

</SQLQuery>

</TestStep>

</TestExecution>
Upon concluding the execution stage we enter the test cleanup stage. This stage uses
BizUnit.PerfmonCountersStep to stop the Performance counters that were started earlier (in Step 3).
<TestCleanup>

<!-- Return system to state prior to test -->

<!-- Stop perfmon counters -->

<TestStep assemblyPath="" typeName="BizUnit.PerfmonCountersStep" failOnError="false">

<PerfmonAction>Stop</PerfmonAction>

<CounterSetName>PerfGuidePerfmonCounters</CounterSetName>

</TestStep>

</TestCleanup>

</TestCase>

This example illustrated how BizUnit can be combined with LoadGen to automate performance testing.
The load test described by the BizUnit configuration file above can be executed from Visual Studio’s
testing tools in the same manner as the functional testing examples described in Walkthrough: Using
BizUnit to Test the BPM Scenario. Adopting this approach enables you to centrally manage, administer
and collect data for your performance testing.
By using BizUnit and LoadGen in an automated approach, it is very easy to schedule multiple test runs
to occur during off hours, which will provide ample test results for analysis during normal working hours.
When automating performance testing, consider using LoadGen scripts that model different loads
through the system, for example you may wish to simulate varying degrees (75%, 100% and 125%) of
the expected production message volume. When performing load testing, it is especially important to
test the overload or “bad day” scenario. Before placing the system into production, you should know
what the maximum sustainable throughput (MST) is for each test case in the BizTalk Server
environment. For more information about maximum sustainable performance, see “What is Sustainable
Performance” in the BizTalk Server 2006 documentation at http://go.microsoft.com/fwlink/?
LinkId=116896.

The complete BizUnit LoadGen sample configuration file

The following list contains the entire contents of the BizUnit configuration file referenced above:
<TestCase testName="Performance-Guide-Sample-Loadgen-Test">

<TestSetup>

<!-- Context property: name of test run -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="TestRunName">

<ItemTest takeFromCtx="BizUnitTestCaseName"></ItemTest>

<ItemTest>_%DateTime%</ItemTest>

</ContextItem>
 </TestStep>

<!-- Context property: name of test directory to store results -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="TestCaseResultsDir">

<ItemTest>C:\Dev Work\Perf Guide Demos\PerfResults\</ItemTest>

<ItemTest takeFromCtx="TestRunName"></ItemTest>

</ContextItem>

</TestStep>

<!-- Context property: perfmon log file -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="PerfMonFilePath">

<ItemTest takeFromCtx="TestCaseResultsDir"></ItemTest>

<ItemTest>\PerfCounters.blg</ItemTest>

</ContextItem>

</TestStep>

<!-- Context property: destintation for app event log on BTSSVR-001 -->

<TestStep assemblyPath="" typeName="BizUnit.ContextManipulatorStep">

<ContextItem contextKey="DestPath-BTSSVR-001-AppEventLog">

<ItemTest takeFromCtx="TestCaseResultsDir"></ItemTest>

<ItemTest>BTSSVR-001_ApplicationLog.evt</ItemTest>

</ContextItem>

</TestStep>

<!-- Clear the application event log on BTSSVR-001 -->

<TestStep assemblyPath="" typeName="BizUnit.EventLogClearStep">

<Machine>BIZTALKADMIN01</Machine>

<EventLog>Application</EventLog>

</TestStep>

<!-- Create the directory to save all the test results -->

<TestStep assemblyPath="" typeName="BizUnit.CreateDirectory">

<DirectoryName takeFromCtx="TestCaseResultsDir" ></DirectoryName>

</TestStep>

</TestSetup>
 <TestExecution>

<!-- Step 1: Stop BizTalk Hosts -->

<TestStep assemblyPath="" typeName="BizUnit.HostConductorStep, BizUnit.BizTalkSteps">

<Action>stop</Action>

<HostInstanceName>BizTalkServerApplication</HostInstanceName>

<Server>BizTalkAdmin01</Server>

<Logon>ServerName\Administrator</Logon>

<PassWord>Pass@word1</PassWord>

<GrantLogOnAsService>true</GrantLogOnAsService>

</TestStep>

<!-- Step 2: Clean Up MessageBox -->

<TestStep assemblyPath="" typeName="BizUnit.DBExecuteNonQueryStep">

<DelayBeforeExecution>1</DelayBeforeExecution>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=BizTalkMsgBoxDb;server=BIZTALKADMIN01;Connect
Timeout=30</ConnectionString>

<SQLQuery>

<RawSQLQuery>[dbo].[bts_CleanupMsgbox]</RawSQLQuery>

</SQLQuery>

</TestStep>

<!-- Step 3: Start Perfmon counters -->

<TestStep assemblyPath="" typeName="BizUnit.PerfmonCountersStep">

<PerfmonAction>Start</PerfmonAction>

<CounterSetName>PerfGuidePerfmonCounters</CounterSetName>

<CountersListFilePath>C:\Dev Work\Perf Guide

Demos\Test_06_PerfCounters.txt</CountersListFilePath>

<SampleInterval>5</SampleInterval>

<PerfmonLogFilePath takeFromCtx="PerfMonFilePath"></PerfmonLogFilePath>

</TestStep>

<!-- Step 4: Start BizTalk Hosts -->

<TestStep assemblyPath="" typeName="BizUnit.BizTalkSteps.HostConductorStep,

BizUnit.BizTalkSteps, Version=3.0.0.0, Culture=neutral, PublicKeyToken=7eb7d82981ae5162">

<Action>start</Action>

<HostInstanceName>BizTalkServerApplication</HostInstanceName>
 <Server>BizTalkAdmin01</Server>

<Logon>ServerName\Administrator</Logon>

<PassWord>Pass@word1</PassWord>

<GrantLogOnAsService>true</GrantLogOnAsService>

</TestStep>

<!-- Step 5: Send Priming messages -->

<TestStep assemblyPath="" typeName="BizUnit.LoadGenExecuteStep, BizUnit.LoadGenSteps">

<LoadGenTestConfig>C:\Program
Files\LoadGen\ConfigFiles\ConsoleConfigFiles\PerfGuideFiletoFile.xml</LoadGenTestConfig>

</TestStep>

<!-- Step 6: Read loadgen file into context variable -->

<TestStep assemblyPath="" typeName="BizUnit.FileReadAndLoadToContext">

<FilePath>C:\Program
Files\LoadGen\ConfigFiles\ConsoleConfigFiles\PerfGuideFiletoFile.xml</FilePath>

<ContextPropertyName>LoadGenFileContent</ContextPropertyName>

</TestStep>

<!-- Step 7: Update test results DB with test start time -->

<TestStep assemblyPath="" typeName="BizUnit.DBExecuteNonQueryStep">

<DelayBeforeExecution>1</DelayBeforeExecution>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=TestResults;server=BizTalkAdmin01;Connect Timeout=30</ConnectionString>

<SQLQuery>

<RawSQLQuery>INSERT INTO tblPerformanceResults (Test_ID, StartTime,LoadGenFile)

VALUES ('{0}',GetDate(),'{1}' )</RawSQLQuery>

<SQLQueryParams>

<SQLQueryParam takeFromCtx="TestRunName"></SQLQueryParam>

<SQLQueryParam takeFromCtx="LoadGenFileContent"></SQLQueryParam>

</SQLQueryParams>

</SQLQuery>

</TestStep>

<!-- Step 8: LoadGen: Load actual perf test -->

<TestStep assemblyPath="" typeName="BizUnit.LoadGenSteps.LoadGenExecuteStep,

BizUnit.LoadGenSteps , Version=3.0.0.0, Culture=neutral, PublicKeyToken=7eb7d82981ae5162">
 <LoadGenTestConfig>C:\Program
Files\LoadGen\ConfigFiles\ConsoleConfigFiles\PerfGuideFiletoFile.xml</LoadGenTestConfig>

</TestStep>

<!-- Step 9: Delay for 5 secs to allow msgs to start flowing -->

<TestStep assemblyPath="" typeName="BizUnit.DelayStep">

<Delay>5000</Delay>

</TestStep>

<!-- Step 10: Wait for Orch Host Queue depth to reach one -->

<TestStep assemblyPath="" typeName="BizUnit.PerfMonCounterMonitorStep">

<CategoryName>BizTalk:Message Box:Host Counters</CategoryName>

<CounterName>Host Queue - Length</CounterName>

<InstanceName>BizTalkServerApplication:biztalkmsgboxdb:BizTalkAdmin01</InstanceName>

<Server>BizTalkAdmin01</Server>

<CounterTargetValue>1</CounterTargetValue>

</TestStep>

<!-- Step 11: Update test results DB with test stop time -->

<TestStep assemblyPath="" typeName="BizUnit.DBExecuteNonQueryStep">

<DelayBeforeExecution>1</DelayBeforeExecution>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=TestResults;server=BIZTALKADMIN01;Connect Timeout=30</ConnectionString>

<SQLQuery>

<RawSQLQuery>UPDATE tblPerformanceResults SET EndTime = GetDate() WHERE Test_ID =

'{0}'</RawSQLQuery>

<SQLQueryParams>

<SQLQueryParam takeFromCtx="TestRunName"></SQLQueryParam>

</SQLQueryParams>

</SQLQuery>

</TestStep>

</TestExecution>

<TestCleanup>

<!-- Return system to state prior to test -->

<!-- Stop perfmon counters -->

<TestStep assemblyPath="" typeName="BizUnit.PerfmonCountersStep" failOnError="false">

 <PerfmonAction>Stop</PerfmonAction>

<CounterSetName>PerfGuidePerfmonCounters</CounterSetName>

</TestStep>

</TestCleanup>

</TestCase>

Using BizUnit with the Business Process

Management Scenario
This topic will utilize one of the end-to-end scenarios provided with BizTalk Server 2006 and show how
you can use the techniques described so far to perform automated functional and performance testing
of the solution. This provides a realistic scenario to help determine how the tools and techniques
presented in this guide can be used to incorporate testing into BizTalk Server solutions.

In This Section
 Overview of the BPM Scenario
 BPM Scenario Architecture
 BPM Message Flow and Entry Points
 Walkthrough: Using BizUnit to Test the BPM Scenario

Overview of the BPM Scenario

The Business Process Management (BPM) scenario is one of three end-to-end (E2E) scenarios
included on the CD with BizTalk Server 2006. The E2E scenarios were developed with a focus on “real
world” scenarios and were vetted by a consortium of BizTalk customers and developers. In fact, the
E2E scenarios underwent a formal “sign off” procedure that required the solutions to be formally
acknowledged as valid for “real-world” solutions before BizTalk Server 2006 was released to
manufacture. Since the E2E scenarios promote best practices for use in live solutions, it is
recommended that each of these solutions is reviewed and that relevant functionality is re-used as
appropriate for any given BizTalk Server solution. For more detailed information about the E2E
scenarios, see “Scenarios for Business Solutions” in the BizTalk Server 2006 documentation at
http://go.microsoft.com/fwlink/?LinkId=116296.

The BPM scenario

The Business Process Management (BPM) scenario covers a fictitious cable TV ordering system for a
company called Southridge Video. The solution enables a user to order a standard or deluxe cable
package. They can also modify or cancel a subscription to either of these. The solution supports long
running business processes (as some subscriptions may take a long time to be approved), routes
requests to multiple backend systems (an example of legacy system integration), and makes use of
complex design patterns which will be discussed in more depth later and are covered completely in the
BPM documentation (see link below). The BPM scenario has been chosen as the walkthrough example
to demonstrate effective and efficient testing because it represents many of the challenges seen in real
world projects it and will provide you realistic guidance and advice.

Note
As well as reading through this overview of the BPM scenario, you should also read the
documentation referenced by the link below. This provides detailed information about the
solution including the design patterns used. It also provides full and complete instructions on
how to set up the solution on your machine. You will need to follow these instructions carefully if
you then want to utilize BizUnit and the other tools we use here to test your solution. For more
information about the BPM solution, see “Business Process Management Solution” at
http://go.microsoft.com/fwlink/?LinkId=116293.

Overview of the BPM scenario

Because the BPM scenario is based on real-world situations, many of the business requirements
imposed by Southridge Video are similar to those experienced by customers using BizTalk Server 2006.
At a high-level the business requirements demand the solution be able to provide the following
functionality:
 Support business process versioning - Individual parts of the business process should be able
to change without affecting the overall solution (i.e. no need for a complete redeployment). This is a
common requirement for customers as most business processes evolve over time, in this situation
it is important to minimize changes to the overall solution and ensure there is little or no impact on
any actively running processes.
 Support long running orders – Individual service requests have no finite time span, therefore, the
solution needs to be able to support long running transactions and also handle circumstances
where the business process must be changed during the lifetime of a long running order.
 Modify in-flight orders - One of the requirements of Southridge is that any specific order can be
modified or cancelled as required while it is being processed. Because each order is represented
by an orchestration instance, this functionality requires the use of a pattern that allows the
orchestration to be interrupted.
 Provide end-to-end tracking –The management of the store also require a full end-to-end
contiguous view of the business process, this is provided through Business Activity Monitoring
(BAM)
 Handle suspended messages – To avoid the operational overhead of having to deal with
suspended messages in BizTalk one of the requirements of the solution is that suspended
messages should be passed directly to the Operations team to enable them to manually repair
them.
 Support batch processing – The system requires multiple entry points so that multiple orders can
be added (this is implemented through an FTP entry point into the system). In addition to this if one
of the interchanges within the batch is faulty it should only affect the processing of that interchange,
the whole batch should not be prevented from processing due to one faulty message in the batch.
 Communicate via remoting with an application server – One of the back-end systems within the
Southridge scenario is an application server with an exposed .NET remoting interface. Therefore,
communication needs to be handled by an assembly that is called from within orchestration.

Design patterns used within the BPM scenario

In order to support the business requirements outlined above, the following design patterns were used:
 Decoupled orchestrations were used to provide mobility and flexibility of business processes.
 Request broker – The solution brokers requests to different processing departments based on
requirements.
 Business Process Versioning
 Need to be able to version the business process.
 Business Process Splitting
 Each business process was split up into separate orchestrations
 Because a single monolithic orchestration was not used it is easier to split up and change the
business process
 BAM was used in the solution to provide a contiguous view of activities within the system to the
business.
 Interruptible long running orchestrations
 Pattern for interrupting them when in-flight.
 Error routing with error envelope
 To avoid the operational overhead of dealing with suspended messages in BizTalk all
suspended messages are routed to a back end system to be manually repaired and eventually
reprocessed.
 Exception handling with code retry
 Custom code re-try ability is provided because one of the end point application servers used in
the solution exposes a .NET remoting interface for all communication. This requires that all
communication from BizTalk Server be done via custom code within an orchestration. When
doing this, you lose much of the functionality that BizTalk Server provides when communication
is done via adapters including retry capabilities and the ability to resume a suspended message
on the send side. In order to avoid unnecessary suspended orchestrations, these capabilities
need to be recreated in the orchestration and custom code. This enables the solution to handle
situations such as when the network is busy and communication is not possible via .NET
remoting. In this case, you don’t really want to suspend the orchestration and induce manual
intervention as this creates unnecessary operational overhead.
 Inverse Direct Partner Binding
 Direct partner binding – binding one orchestration to another direct binding.
 Ability to bind partners together in a backwards fashion.
 An Order manager orchestration has been implemented to manage the execution of each order
through the various required stages.
 Enterprise Single sign-on (ENTSSO) was used as a centralized data store for all configuration data
required by the solution. This approach avoids the need to store configuration individually across all
BizTalk Servers. As the number of servers in your group increases so does the number of
applications. Managing and versioning configuration for these applications across multiple servers
becomes an administrative and operational burden. This burden is compounded by the fact that
incorrect configuration data can lead to problems running the solution in production. Therefore, it is
highly recommended that you consider using ENTSSO as a central configuration data store in any
solutions that you build.

Note
Each of the design patterns discussed above are covered in greater depth in the BizTalk Server
documentation. For more information about these design patterns, see “Patterns in the
Business Process Management Solution” in the BizTalk Server 2006 documentation at
http://go.microsoft.com/fwlink/?LinkId=116298.

BPM Scenario Architecture

The business process for the Business Process Management solution is broken into a series of stages.
An order manager, which knows nothing about the business rules and backend systems, directs the
operation of the stages. The order manager receives orders from an order broker, which can direct
orders to several different order managers. This topic provides an overview of the Business Process
Management (BPM) scenario used in the topic Walkthrough: Using BizUnit to Test the BPM Scenario

High-level architecture overview of the BPM scenario

The figure below depicts the overall scenario architecture. The typical process is as follows:
 A customer service representative (CSR) sends a request into the system via an order broker.
 This information is recorded in the History database.
 The order is published to the Order Manager
The Order Manager is an orchestration that manages the overall business process. The Order Manager
is designed as a type agnostic orchestration, which means it does not have a dependency on a
particular version of a schema. This means changes to the Order Manager orchestration can be
minimized. The reasoning behind this is that changes to the Order Manager orchestration could impact
all in-flight messages (as opposed to messages in a particular stage) which may significantly impact the
overall solution. As discussed in Overview of the BPM Scenario, the system must support business
process changing and versioning, therefore the Order Manager has the capability to support multiple
stages, the number of which can change over time. The number of stages to be processed is
maintained in the Enterprise Single Sign-On configuration store.
The BPM scenario records information in the History database each time a stage is executed. The BPM
scenario also automatically sends any errors to an operations team via a custom operational adapter
that was designed for this scenario.

BPM scenario workflow overview

The sequence diagram below illustrates the high level steps involved in processing an order in the
Southridge system. As you can see from the diagram the system enables the CSR to initiate orders,
interrupt orders (e.g. cancel them) and update orders that are being processed. Each of these
functionality requirements were driven by the business requirements described in Overview of the BPM
Scenario.
BPM scenario workflow sequence diagram

BPM Message Flow and Entry Points

This topic describes the Business Process Management message flow, the various entry points into the
solution, and provides a high-level view of the components used in the solution.

BPM message flow and explanation of entry points to

the system
The BPM scenario provides multiple entry points to the system. As can be seen in the diagram below,
the default service interface is the SOAP transport. In this solution, the SOAP transport is utilized by an
ASP.NET Web application, which calls this service interface. The BPM Scenario also exposes another
service interface, which in this case is an FTP location where batched order requests can be sent. The
FTP service interface makes use of the non-atomic interchange functionality introduced in BizTalk
Server 2006. This means that if a single message within the interchange is invalid, only that message is
suspended, the rest of the interchange is processed normally.
Business Process Management application patterns

The message then enters pre-processing by translators, implemented as BizTalk Server maps. The
translators create an acknowledgement for the service interface, generate an entry in the history or
tracking database and make an entry in the service system. The fourth and final translator creates the
message which is required by the Process Manager (Order Manager in previous diagram); the Process
Manager then controls the execution of the required number of stages and writes the history of the
process to the History database.

BPM message flow: high-level view of components

used
The diagram below shows the same message flow but this time from a component perspective. As you
can see, the Southridge solution utilizes many different transports; the communication with these
systems is provided through a combination of MSMQ, FTP, Custom Ops and SQL BizTalk adapters.
.NET remoting is used for the communication with the Order Management System.
Business Process Management application components

The solution also supports single and batched requests via different service interfaces; it detects
duplicates and supports sending interrupts to in-flight orchestrations.
This system has multiple end points, supports different message types and communicates over many
different transports. There are multiple points of failure here, so full and thorough testing of an
application such as this significantly reduces risk to the project. Building out of the test harness over
time should be looked at as an investment in test assets which will provide a return on the investment
every time you run the test suite.

Walkthrough: Using BizUnit to Test the BPM

Scenario
This topic provides a walkthrough of using BizUnit to test the Business Process Management end-to-
end sample scenario that is available in the \Msi\Program Files\SDK\BPM\ folder of the BizTalk Server
2006 R2 CD.

Objectives of testing the BPM scenario

As discussed in the topic Why Is It Important to Test?, thorough and continuous testing of a solution
should be planned from the inception of a project and performed until the project is placed into
production. Integration of testing into the daily build process from the onset of the project allows the test
suite for the solution to expand from the baseline as functionality is added to the solution. If this process
is followed, it is much easier to detect whether a change made during development of the project has
created a regression or broken any of the functional aspects of the solution. An integrated testing
methodology is vastly preferable to a “bolt on” approach that only tests at the tail-end of the project that
leaves little margin for error. Testing the BPM solution, as described in this topic, should help
accomplish the following objectives:
1. Examine a solution to determine the functional flows through the system.
2. Verify that all custom code in the solution has been tested by using the Visual Studio 2005 code
coverage tools.
3. Build functional tests quickly and easily in BizUnit.
4. Combine Visual Studio 2005 Web testing with BizUnit.

Prerequisite software required

In order to test the BPM scenario using the techniques described in this topic, the following software
must be installed:
 Visual Studio 2005 Team System (with testing tools).
 BizUnit 3.0, available for download at http://go.microsoft.com/fwlink/?LinkID=85168.
 The Business Process Management Solution must be installed per the instructions at
http://go.microsoft.com/fwlink/?LinkId=116567.

Creating a BizUnit testing project in Visual Studio

2005
After installing the prerequisite software, complete the following steps to create a testing project in
Visual Studio 2005:
1. Create a directory to house the BizUnit test project, for example C:\BizUnit Walkthrough.
2. Click Start, point to Programs, point to Microsoft Visual Studio 2005, and then click Microsoft
Visual Studio 2005 to launch Visual Studio 2005.
3. In Visual Studio 2005, click the File menu, click New, and then click Project to open the New
Project dialog box.
4. In the New Project dialog box, under Project types, click to expand Visual C# and then select
Test.
5. Enter these values for the specified edit boxes, and then click OK:
 Name: Enter BPM Tests.
 Location: Enter the name of the directory that you created to house the BizUnit test project, for
example C:\BizUnit Walkthrough.
 Solution Name: Enter BPM E2E Scenario Tests.
 Create directory for solution: Check this box.
In order for the testing project to make use of the BizUnit assemblies, a reference to the BizUnit
assemblies must be added to the project. Follow these steps to add references to the specified BizUnit
assemblies:
1. In Solution Explorer, click to expand BPM Tests, right-click References, and then click Add
Reference to display the Add Reference dialog box.
2. In the Add Reference dialog box, click the Browse tab and navigate to the \Program
Files\BizUnit\BizUnit 3.0\bins directory.
3. Ctrl+click to multi-select the files BizUnit.dll, BizUnit.BizTalkSteps.dll, BizUnit.LoadGenSteps and
BizUnit.MQSeriesSteps, and then click OK.
This adds references to the assemblies as these will be used later on. Also, verify that this project
has a reference to the Microsoft.VisualStudio.QualityTools.UnitTestFramework assembly. This
should have automatically been added as a reference when this project was created.
When this project is created, a default class is added to the file UnitTest1.cs. In Solution Explorer, right-
click UnitTest1.cs, select Rename from the shortcut menu, and then rename this file to BPMTests.cs.
This file will contain the “boilerplate” code that will drive BizUnit tests from Visual Studio’s testing tools.
Replace the contents of this file with the following code:
using System;

using System.Text;

using System.Collections.Generic;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using BizUnit;

namespace BPM_Tests

[TestClass]

public class BPMTests

[TestMethod]

public void CSRWebForm_BizUnit_Data_Validation()

BizUnit.BizUnit bizUnit = new BizUnit.BizUnit(@"C:\BizUnit Walkthrough\BPM E2E

Scenario Tests\BPM Tests\TestCases\CSRWebForm_BizUnit_Data_Validation.xml");

bizUnit.RunTest();

}
 [TestMethod]

public void CancelOrder_CSRWebForm_BizUnit_Data_Validation()

BizUnit.BizUnit bizUnit = new BizUnit.BizUnit(@"C:\BizUnit Walkthrough\BPM E2E

Scenario Tests\BPM Tests\TestCases\CancelOrder_CSRWebForm_BizUnit_Data_Validation.xml");

bizUnit.RunTest();

As can be seen in the code listing above, it is necessary to include a “using” statement for the BizUnit
assembly. This code defines a single class, BPMTests, which has been given the [TestClass] attribute.
The class includes two methods, both of which simply instantiate a new BizUnit object with a parameter
for the location of the test case configuration file.
This is literally all the code required to define a BizUnit test case; everything else is done through the
test case XML configuration file. This allows for separation between code and test configuration, which
means that tests can be changed or modified without the need for recompiling.

Structuring the project

Follow these best practices when creating a testing project that combines BizUnit and Visual Studio unit
testing:
 Create a separate Test Cases directory - This makes it easier to manage and modify your test
cases during the development. It is also recommended that you name your test case files
appropriately. For example, “test_1_Call_BPM_Order_Web_Service” implies what the test does
whereas “test_1” does not.
 Create a separate Test Data directory - This provides a separation between your test
configuration and the data used by the test.
 Use consistent naming for artifacts in the project - Large integration projects can easily contain
more than 1000 functional tests; failure to follow a consistent naming convention may have
significant ramifications later on in the project. Consistent naming conventions will help ensure data
consistency and will simplify management of these tests.
To create a separate test cases and test data directory for the testing project, follow these steps:
1. In Solution Explorer, right-click the BPM Tests project to display the shortcut menu.
2. On the shortcut menu, click Add and New Folder.
3. Enter TestCases and press the Enter key on your keyboard.
4. Repeat steps 1 – 3 above, except for step 3, enter the name TestData to create a new folder
named TestData.
Creating the test case configuration
When creating a test it is important to first consider what should be tested and then consider how to test
it. For maximum confidence in a solution you should include every single component, endpoint and
message flow in your functional testing suite. In this section we will walk through an example of how the
BPM scenario could be tested this way. Providing a walkthrough of a full functional testing suite for the
BPM scenario is beyond of the scope of this topic, instead this walkthrough focuses on practical
examples and background information that can be implemented in your own projects.
Deciding what needs to be tested in a functional test case
The high-level flow diagram of the BPM solution below highlights the primary entry points of the system.
In the case of creating an order for a standard cable TV service, which is placed once and does not get
cancelled, the following endpoints should be tested:

BPM solution endpoints to be tested

1. The service interface - In this case the CSR Web form which can be accessed at
http://localhost/CSRWebApp/CSRMainForm.aspx is the Web form used to drive the application.
The test should validate that the CSR form is accessible; that the correct data can be entered and
that the correct response is returned. The screenshot below depicts this Web page:
 The CSR Web form interface

2. The History database - As highlighted in the diagram below the history database should be
updated throughout the process to reflect the start, completion and any cancellation of an order.
Therefore this test should validate that the history database is updated. The screenshot below
shows the row stored in the orderlog table in the SouthRidgeVideoHistory database for the
information entered in the CSR Web form in step 1:

The orderlog table in the SouthRidgeVideoHistory database

3. The BAM database - BAM is used by the solution to provide comprehensive business information.
Because this provides essential information to the business users the test needs to validate that the
order information is stored successfully here.
The query in the screenshot below can be used to return the last updated row in the BAM Order
Manager view.

BPM BAM Order Manager view

Combining a Visual Studio Web test and BizUnit to functionally test the BPM Scenario
Now that we have defined what should be tested, we will establish how to test it. To test the functional
flow through the system, we combine Visual Studio Web Testing (to test the CSR Web form) and
BizUnit (to validate that the BAM and History database information is updated). To do this, complete the
following steps:
1. Complete steps 1 through 6 in the section “To start the Business Process Management Solution” of
the topic “How to Run the Business Process Management Solution” at
http://go.microsoft.com/fwlink/?LinkId=117752.
2. Follow these steps to add a new Web test to the BPM Tests project:
a. In Solution Explorer, right-click the BPM Tests project, click Add, and then click New Test to
display the Add New Test dialog box.
b. In the Add New Test dialog box, click Web Test, enter CSRWebFormCreateOrder.webtest
for Test Name, and then click OK. This displays a CSRWebFormCreateOrder.webtest form in
the Visual Studio IDE and also opens a Web Test Recorder interface in Internet Explorer.
Enter the address of the CSR Web form into the address bar of the Web Test Recorder
interface in Internet Explorer: http://localhost/CSRWebApp/CSRMainForm.aspx
c. After the Web page is displayed, enter the following values into the Web form, and then click
the Submit Order button.
 Field Value

Customer ID 999
Order ID 999
Sequence Number 1
Service Type Code New Standard Service

3. After you click Submit Order, the form should display a Last Message Sent acknowledgement as
in the screenshot below.

Using Visual Studio Web test recorder

In the Web Test Recorder section, click Stop and switch back to the Visual Studio IDE. The Web
test configuration will display in Visual Studio.
In the Web test configuration window, click to expand each of the nodes under
CSRWebFormCreateOrder to display the Form Post Parameters for the Web test. Note that the
form post parameters correspond to the values entered in the Web Test Recorder interface in
Internet Explorer.
4. Launch Internet Explorer, open the CSR Web form at
http://localhost/CSRWebApp/CSRMainForm.aspx, enter the same values into the form that you
entered when submitting the order except select the value Cancel Standard Service for Service
Type Code, and then click Submit Order. This will clean up the original Web test and allow you to
run the Web test using the same parameters in the future. Later on we will illustrate how this clean
up logic is incorporated into the testing harness to perform the cleanup process automatically.
The preceding steps define how to create a Web test to test the service interface. The following
steps define how to validate that the correct information is inserted into the History and BAM
databases. Follow these steps to confirm that the correct information is inserted into the History and
BAM databases.
5. Create the file CSRWebForm_BizUnit_Data_Validation.xml in the C:\BizUnit Walkthrough\BPM E2E
Scenario Tests\BPM Tests\TestCases directory of the BPM Tests project. This file is referenced by
the CSRWebForm_BizUnit_Data_Validation() test method defined in the BPMTests class in the file
BPMTests.cs. The contents of this file are listed below:
<TestCase testName="CSRWebForm_BizUnit_Data_Validation">

<TestSetup>

<TestStep assemblyPath="" typeName="BizUnit.DelayStep">

<Delay>20000</Delay>

<!--

Set <Delay> to a value large enough to allow enough time for the BPM
scenario to update the History database,

the Tracking database, and the BAM database or else the test steps that
validate the updated values

in these databases will fail. For most environments a value of 20000 (20
seconds) will be sufficient.

-->

</TestStep>

</TestSetup>

<TestExecution>

<TestStep assemblyPath="" typeName="BizUnit.DBQueryStep" failOnError="true">

<DelayBeforeCheck>0</DelayBeforeCheck>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=SouthridgeVideoHistory;server=(local);Connect
Timeout=30</ConnectionString>

<NumberOfRowsExpected>1</NumberOfRowsExpected>

<!--
 This SQL Query validates that the correct information has been tracked in
the History Database which is used by the BPM scenario

-->

<SQLQuery>

<RawSQLQuery>select top 1 * from orderlog order by OrderTime

desc</RawSQLQuery>

</SQLQuery>

<Rows>

<Columns>

<!--

Here we validate the values for some of the key columns returned. This
validates that the correct row of data related to the test case is returned.

Please note: BizUnit does support test context, therefore if you

wanted to expand on this test case to check different messages you could do this

by passing context between test steps. For more information please see
the BizUnit documentation.

-->

<OrderNumber>999</OrderNumber>

<CustNumber>999</CustNumber>

<OrderType>NS</OrderType>

<OrderDetails>New Order</OrderDetails>

</Columns>

</Rows>

</TestStep>

<TestStep assemblyPath="" typeName="BizUnit.DBQueryStep" failOnError="true">

<DelayBeforeCheck>0</DelayBeforeCheck>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=BAMPrimaryImport;server=(local);Connect
Timeout=30</ConnectionString>

<NumberOfRowsExpected>1</NumberOfRowsExpected>

<!--

Here we validate that tracking data has been correctly recorded in the
ServiceOrderRequest BAM activity

-->
 <SQLQuery>

<RawSQLQuery>select top 1 * from dbo.bam_ServiceOrderRequest_AllInstances

order by recordid desc</RawSQLQuery>

</SQLQuery>

<Rows>

<Columns>

<!--

Column validation on data returned by the query above

-->

<OrderID>999</OrderID>

<CustomerID>999</CustomerID>

<ServiceType>NS</ServiceType>

</Columns>

</Rows>

</TestStep>

<TestStep assemblyPath="" typeName="BizUnit.DBQueryStep" failOnError="true">

<DelayBeforeCheck>0</DelayBeforeCheck>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=BAMPrimaryImport;server=(local);Connect
Timeout=30</ConnectionString>

<NumberOfRowsExpected>1</NumberOfRowsExpected>

<!--

Here we validate that tracking data has been correctly recorded in the
Custom Order Request BAM Activity

-->

<SQLQuery>

<RawSQLQuery>select top 1 * from "bam_Customer Order

Request_AllInstances" order by recordid desc</RawSQLQuery>

</SQLQuery>

<Rows>

<Columns>

<!--

Column validation in data returned by the above query

-->
 <OrderID>999</OrderID>

<CustomerID>999</CustomerID>

<RequestType>CSR Placed Order</RequestType>

</Columns>

</Rows>

</TestStep>

<TestStep assemblyPath="" typeName="BizUnit.DBQueryStep" failOnError="true">

<DelayBeforeCheck>0</DelayBeforeCheck>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=BAMPrimaryImport;server=(local);Connect
Timeout=30</ConnectionString>

<NumberOfRowsExpected>1</NumberOfRowsExpected>

<!--

Here we validate that data has been correctly recorded in the OrderManager
BAM activity

-->

<SQLQuery>

<RawSQLQuery>select top 1 * from dbo.bam_OrderManager_AllInstances order

by recordid desc</RawSQLQuery>

</SQLQuery>

<Rows>

<Columns>

<!--

Column validation on query results.

-->

<OrderID>999</OrderID>

<CustomerID>999</CustomerID>

<SequenceNum>1</SequenceNum>

</Columns>

</Rows>

</TestStep>

</TestExecution>

<TestCleanup>
 <!-- Test cleanup: test cases should always leave the system in the state they
found it -->

</TestCleanup>

</TestCase>

6. Verify that the three BAM activities that are part of the BPM scenario have been deployed to the
BizTalk group as part of the BPM scenario. To do this, start a command prompt, change directories
to the \Program Files\Microsoft BizTalk Server 2006\Tracking directory and then run the following
command:
BM get-activities

This command returns all of the BAM activities that have been deployed to the BizTalk Server group
which should include the following BAM activities:
 Customer Order Request
 OrderManager
 ServiceOrderRequest
Note that the CSRWebForm_BizUnit_Data_Validation.xml file makes use of the
“BizUnit.DBQueryStep” function to validate that the correct information is captured in the History
database and the three BAM Activities all contain the correct monitoring data.
7. You are now ready to run the test. To do this, in Visual Studio, click the Test menu, select
Windows, and click Test View to display the Test View window. Then right-click the
CSRWebForm_BizUnit_Data_Validation test and select Run Selection.
The Test Results window should display detailed information for each test stage. Upon completion
of the test, a result of Passed should be displayed. If you right-click the test result and click View
Test Results Details, a console output is displayed, which provides detailed information about
each BizUnit step that was completed. The test results details should be examined to ensure that
each of the BizUnit.DBQueryStep test steps has completed. The detailed output that BizUnit
generates can be used to quickly debug test case failures.
So far we have illustrated how to use a Visual Studio Web Test to generate input for the CSR Web form
and to run a BizUnit test, which uses tracking data to verify data is submitted to the system correctly.
However, in order to accommodate full functional testing, we must also implement test cleanup
functionality. As mentioned earlier in the topic, it is important that each test can run autonomous of other
tests.
The next section examines how to integrate Visual Studio Web testing and BizUnit to provide cleanup
and verification functionality. To do this, we will to expand on the previous test and utilize the Cancel
Standard Service option provided by the CSR Web form.
Test Cleanup: Utilizing Visual Studio Web Testing and BizUnit
In this section we will create a Web test that will be used to cancel the order created previously. We will
then use BizUnit to validate that the OrderHistory is updated successfully. To do this, follow these steps:
1. In Solution Explorer, right-click the BPM Tests project, click Add, and then click New Test to
display the Add New Test dialog box.
2. In the Add New Test dialog box, click Web Test, enter CSRWebFormCancelOrder.webtest for
Test Name, and then click OK. This displays a CSRWebFormCancelOrder.webtest form in the
Visual Studio IDE and also opens a Web Test Recorder interface in Internet Explorer.
Enter the address of the CSR Web form into the address bar of the Web Test Recorder interface in
Internet Explorer (http://localhost/CSRWebApp/CSRMainForm.aspx).
3. Enter the following values into the Web form, and then click the Submit Order button.

Field Value

Customer ID 999
Order ID 999
Sequence Number 1
Service Type Code Cancel Standard Service

4. In the Web Test Recorder section, click Stop and switch back to the Visual Studio IDE. The Web
test configuration will be displayed in Visual Studio.
In the Web test configuration window, click to expand each node under
CSRWebFormTerminateOrder to display the Form Post Parameters for the Web test. Note that
the form post parameter for OrderTypeCodeDropDownList is “XS,” which is the internal code
used by Southridge to represent cancellation of a standard cable service order.
5. In the C:\BizUnit Walkthrough\BPM E2E Scenario Tests\BPM Tests\TestCases directory of the BPM
Tests project, create the file CancelOrder_CSRWebForm_Bizunit_Data_Validation.xml. This file is
referenced by the CancelOrder_CSRWebForm_BizUnit_Data_Validation() test method defined in
the BPMTests class in the file BPMTests.cs. This test configuration file is used to check that an “XS”
type (Cancel Standard Service) request is recorded in the History database and the Service Order
BAM activity. In this instance, it is only necessary to check the Service Order BAM Activity. The
contents of this file are listed below:
<TestCase testName="CancelOrder_CSRWebForm_BizUnit_Data_Validation">

<TestSetup>

<TestStep assemblyPath="" typeName="BizUnit.DelayStep">

<Delay>20000</Delay>

<!--

Set <Delay> to a value large enough to allow enough time for the BPM
scenario to update the History database,

the Tracking database, and the BAM database or else the test steps that
validate the updated values

in these databases will fail. For most environments a value of 20000 (20
seconds) will be sufficient.
 -->

</TestStep>

</TestSetup>

<TestExecution>

<TestStep assemblyPath="" typeName="BizUnit.DBQueryStep" failOnError="true">

<DelayBeforeCheck>0</DelayBeforeCheck>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=SouthridgeVideoHistory;server=(local);Connect
Timeout=30</ConnectionString>

<NumberOfRowsExpected>1</NumberOfRowsExpected>

<!--

This SQL Query validates that the correct information has been tracked in
the History Database which is used by the BPM scenario

-->

<SQLQuery>

<RawSQLQuery>select top 1 * from orderlog order by OrderTime

desc</RawSQLQuery>

</SQLQuery>

<Rows>

<Columns>

<!--

Here we validate the values for some of the key columns returned. This
validates that the correct row of data related to the test case is returned.

Please note: BizUnit supports test context, therefore if you wanted to

expand on this test case to check different messages you could do this by

passing context between test steps. For more information please see the
BizUnit documentation.

Note Order Type that is now verified is XS for cancel service

-->

<OrderNumber>999</OrderNumber>

<CustNumber>999</CustNumber>

<OrderType>XS</OrderType>

<OrderDetails>New Order</OrderDetails>
 </Columns>

</Rows>

</TestStep>

<TestStep assemblyPath="" typeName="BizUnit.DBQueryStep" failOnError="true">

<DelayBeforeCheck>0</DelayBeforeCheck>

<ConnectionString>Persist Security Info=False;Integrated

Security=SSPI;database=BAMPrimaryImport;server=(local);Connect
Timeout=30</ConnectionString>

<NumberOfRowsExpected>1</NumberOfRowsExpected>

<!--

Here we validate that tracking data has been correctly recorded in the
ServiceOrderRequest BAM activity

-->

<SQLQuery>

<RawSQLQuery>select top 1 * from dbo.bam_ServiceOrderRequest_AllInstances

order by recordid desc</RawSQLQuery>

</SQLQuery>

<Rows>

<Columns>

<!--

Column validation of data returned by the query above

-->

<OrderID>999</OrderID>

<CustomerID>999</CustomerID>

<ServiceType>XS</ServiceType>

</Columns>

</Rows>

</TestStep>

</TestExecution>

<!-- Test cleanup: test cases should always leave the system in the state they
found it -->

<TestCleanup>

</TestCleanup>
 </TestCase>

6. Run the CancelOrder_CSRWebForm_BizUnit_Data_Validation test. To do this, in Visual Studio,

click the Test menu, select Windows, and then click Test View to display the Test View window.
Then right-click the CancelOrder_CSRWebForm_BizUnit_Data_Validation test and select Run
Selection. The Test Results window should then display detailed information for each test stage.
Upon completion of the test, a result of Passed should be displayed. If you right-click the test result
and click View Test Results Details a console output is displayed that provides detailed
information about each BizUnit step that was completed. The test results details should be
examined to ensure that each of the BizUnit.DBQueryStep test steps have been completed.
Your testing project should now contain the following four tests:
 CSRWebFormCreateOrder - Creates a new Standard Service request using the CSR Web form.
 CSRWebForm_BizUnit_Data_Validation - Verifies the data for the Standard Service request is
recorded in the History database and the BAM activities for the BPM application.
 CSRWebFormCancelOrder - Cancels the Standard Service request using the CSR Web form.
 CancelOrder_CSRWebForm_BizUnit_Data_Validation - Verifies the Standard Service request
was cancelled by checking the History Database and the Service Order BAM activity.

Running BizUnit tests in a specific order

Using an ordered test to run tests in a specific order
In order for the functions of the system to be tested correctly, the tests must be run in the correct order.
Visual Studio accommodates the execution of a set of tests in a specific order through the use of an
Ordered Test. Follow these steps to add an Ordered Test to the BPM Tests project:
1. In Solution Explorer, right-click the BPM Tests project, click Add, and then click New Test to
display the Add New Test dialog box.
2. In the Add New Test dialog box, click Ordered Test, enter CSRWebForm.orderedtest for Test
Name and then click OK.
3. In Solution Explorer, double-click CSRWebForm.orderedtest to display the list of tests in the BPM
Tests project.
4. In the Available tests section, double-click each test displayed so they are displayed under
Selected tests in the following order:
a. CSRWebFormCreateOrder
b. CSRWebForm_BizUnit_Data_Validation
c. CSRWebFormCancelOrder
d. CancelOrder_CSRWebForm_BizUnit_Data_Validation
5. You can now run the CSRWebForm ordered test by right-clicking CSRWebForm in the Test View
window and then selecting Run Selection from the context menu.
 After the tests have successfully completed, you can right-click the CSRWebForm test in the Test
Results window and select View Test Results Details to view the results of each individual test.
Additionally, you can double-click each individual test to view the specific results for the test.
Calling multiple BizUnit tests from a single test method as an alternative to ordered tests
Ordered tests were used as the approach in the example above to group Visual Studio Web tests and
BizUnit tests into one autonomous test. The ordered test used four separate test methods to check that
an order submitted through the CSR Web form can be tracked appropriately, cancelled, and that the
associated tracking data is recorded.
An alternative approach to using an ordered test is to implement a single test method in Visual Studio
that drives all of the tests with BizUnit. This approach avoids multiple tests appearing in the test window
and reduces the chances of accidentally running tests out of order. BizUnit provides the
SOAPHTTPRequestResponseStep for this purpose. For more information about the
SOAPHTTPRequestResponseStep, see the BizUnit documentation. This step can be used to directly
test the BPM Web service that the CSR Web form uses.
It is a good practice to avoid using large monolithic BizUnit test cases that become difficult to manage
and edit. To avoid this it is possible to call multiple BizUnit objects from a single test method. This also
allows you to easily combine Visual Studio Unit Testing code with BizUnit testing logic. The code
snippet below illustrates how this might be accomplished.
[TestMethod]

public void Test_Calling_Multiple_BizUnit_Tests()

//Create BizUnit object 1 and specify test case configuration

BizUnit.BizUnit bizUnit1 = new BizUnit.BizUnit(@"..\Test Cases\BizUnit1.xml");

bizUnit1.RunTest();

//Create BizUnit object 2 and specify test case configuration

BizUnit.BizUnit bizUnit2 = new BizUnit.BizUnit(@"..\Test Cases\BizUnit2.xml");

bizUnit2.RunTest();

Conclusion
Functional testing plays an important role in the performance tuning and optimization process. In many
cases during a performance lab changes will need to be made that can affect the functionality of the
system. An example of this would be improving the latency of an Orchestration by replacing a send port
with a .NET assembly that makes in-line sends. When making changes such as this it is important that
you do not impact the functionality of the system. By automating functional testing of your solution you
reduce the risk associated with any changes to the solution because you can fully functionally test your
system for positive and negative (failure) scenarios. Automated functional testing becomes critical to the
success of a project because manual functional testing becomes burdensome as the complexity and
scope of the project increases.
BizUnit provides over 70 predefined test steps and the BizUnit framework is extensible, so you can add
your own steps relatively easily. It is important to use the right tool for the job. Visual Studio Web testing
is an excellent tool for functional testing of Web services and BizUnit’s test steps make it very easy to
validate tracking data, start and stop BizTalk hosts, monitor performance monitor counters, and much
more.
For more information and best practices about unit testing with the Visual Studio 2005 testing tools, see
the following documentation:
 Working with Ordered Tests - http://go.microsoft.com/fwlink/?LinkId=117837
 Working with Unit Tests - http://go.microsoft.com/fwlink/?LinkId=62412
 Unit Test Walkthrough - http://go.microsoft.com/fwlink/?LinkId=117843

Optimizing Performance
A default installation of the Windows operating system, SQL Server, and BizTalk Server can be
significantly optimized to provide optimal performance for a production BizTalk Server environment.
This section provides specific performance optimizations that should be followed when deploying a
production BizTalk Server solution.

In This Section
 Optimizing Operating System Performance
 Optimizing Network Performance
 Optimizing Database Performance
 Optimizing BizTalk Server Performance
 Windows PowerShell Scripts

Optimizing Operating System Performance

This topic provides recommendations for optimizing performance of Windows Server for use in a
production BizTalk Server environment.

Important
Some of the recommendations in this topic require modifications to the Windows Server
registry. Incorrect use of Registry Editor may cause problems requiring you to reinstall your
operating system. Use Registry Editor at your own risk. For more information about how to
 back up, restore, and modify the registry, see the Microsoft Knowledge Base article
"Description of the Microsoft Windows registry" at http://go.microsoft.com/fwlink/?LinkId=62729.

General guidelines for improving operating system

performance
The following recommendations can be used to increase operating system performance:

Install the latest BIOS, storage area network (SAN) drivers, network
adapter firmware and network adapter drivers
Hardware manufacturers regularly release BIOS, firmware, and driver updates that can improve
performance and availability for the associated hardware. Visit the hardware manufacturer’s Web site to
download and apply updates for the following hardware components on each computer in the BizTalk
Server environment:
1. BIOS updates
2. SAN drivers (if using a SAN)
3. NIC firmware
4. NIC drivers

Disable hyper-threading on BizTalk Server and SQL Server

computers
 It is critical hyper-threading be turned off for BizTalk Server computers. This is a BIOS setting,
typically found in the Processor settings of the BIOS setup. Hyper-threading makes the server
appear to have more processors/processor cores than it actually does; however hyper-threaded
processors typically provide between 20 and 30% of the performance of a physical
processor/processor core. When BizTalk Server counts the number of processors to adjust its self-
tuning algorithms; the hyper-threaded processors cause these adjustments to be skewed which is
detrimental to overall performance.
 Hyper-threading should be turned off for SQL Server computers because applications can cause
high levels of contention (such as BizTalk Server) may cause decreased performance in a hyper-
threaded environment on a SQL Server computer.

Note
On most computers, hyper-threading is configured via the computer BIOS. Steps will vary by
computer type and manufacturer.

Assign the MSDTC log file directory to a separate dedicated drive

In a BizTalk Server environment with multiple MessageBox databases on separate SQL Server
computers, additional overhead associated with Microsoft Distributed Transaction Coordinator
(MSDTC) is incurred. By default the MSDTC log files are located in the %systemdrive
%\windows\system32\msdtc directory of the computers running the DTC service. To mitigate the
possibility that DTC logging could become a performance bottleneck, consider moving the MSDTC log
file directory to a fast disk drive. To change the MSDTC log file directory follow these steps:
1. Click Start, click Run, and type dcomcnfg to launch the Component Services Management
console.
2. Expand Component Services, expand Computers, right-click My Computer, and then click
Properties.
3. In the My Computer Properties dialog box, click the MSDTC tab.
4. In the Location edit box under Log Information, type the path where you want the new log to be
created (for example, G:\Logs\DTCLog).
5. Click Reset log, and you will be prompted for service restart. Click OK to restart the DTC service,
and then click OK to confirm the MSDTC service has been restarted.

Configure antivirus software to avoid real-time scanning of BizTalk

Server executables and file drops
Antivirus software real-time scanning of BizTalk Server executable files and any folders or file shares
monitored by BizTalk Server receive locations can negatively impact BizTalk Server performance. If
antivirus software is installed on the BizTalk Server computer(s), disable real-time scanning of non-
executable file types referenced by any BizTalk Server receive locations (usually .XML, but can also
be .csv, .txt, etc.) and configure antivirus software to exclude scanning of BizTalk Server executable
Files

Disable intrusion detection network scanning between computers in

the BizTalk Server environment
Intrusion detection software can slow down or even prevent valid communications over the network. If
intrusion detection software is installed, disable network scanning between BizTalk Server computers
and external data repositories (SQL Server) computers or messaging services (Message Queuing,
WebSphere MQSeries, etc.) computers.

Defragment all disks in the BizTalk Server environment on a regular

basis
Excessive disk fragmentation in the BizTalk Server environment will negatively impact performance.
Follow these steps to defragment disks in the BizTalk Server Environment:
1. Defragment all disks (local and SAN/NAS) on a regular basis by scheduling off-hours disk
defragmentation.
2. Defragment the Windows PageFile and pre-allocate the Master File Tables of each disk in the
BizTalk Server environment to boost overall system performance.
 Note
Use the PageDefrag utility available at http://go.microsoft.com/fwlink/?LinkId=108976 to
defragment the Windows PageFile and pre-allocate the Master File Tables.

If antivirus software is installed on the SQL Server computer(s),

disable real-time scanning of data and transaction files
Real-time scanning of the SQL Server data and transaction files (.mdf, .ndf, .ldf, .mdb) can increase
disk I/O contention and reduce SQL Server performance. Note that the names of the SQL Server data
and transaction files may vary between BizTalk Server environments. For more information about the
data and transaction files created with a default BizTalk Server configuration, see Optimizing Filegroups
for the Databases.

Configure MSDTC for BizTalk Server

Review the following information to configure MSDTC for BizTalk Server:
 "How to Enable MSDTC on the BizTalk Server" at http://go.microsoft.com/fwlink/?LinkId=108445.
 "Troubleshooting Problems with MSDTC" at http://go.microsoft.com/fwlink/?LinkId=101609.

Configure firewall(s) for BizTalk Server

Note
This step is only required if one or more firewalls are in place in your BizTalk Server
environment.
Review the following information to configure firewall(s) for BizTalk Server:
 "Required Ports for BizTalk Server" at http://go.microsoft.com/fwlink/?LinkId=101607.
 "How to configure RPC dynamic port allocation to work with firewalls" at
http://support.microsoft.com/kb/154596.

Install appropriate COM+ and MSDTC hotfix rollup packages

Review the following information to install the appropriate COM+ and MS DTC hotfix rollup packages:
 The final version of the COM+ rollup is the “Windows Server 2003 Post-Service Pack 2 COM+ 1.5
Hotfix Rollup Package 12”. This hotfix will install on any version of Windows Server 2003, even
those without a service pack installed. More information about this hotfix can be found in Microsoft
Knowledge Base article 934016, "Availability of Windows Server 2003 Post-Service Pack 2 COM+
1.5 Hotfix Rollup Package 12" at http://support.microsoft.com/kb/934016.
 The latest DTC hotfix rollup package KB article can be found by searching
http://support.microsoft.com for the phrase (including the quotes):
"MS DTC Hotfix Rollup Package"
 The following query does this search for you. Choose the latest one:
http://support.microsoft.com/search/default.aspx?query="MS+DTC+Hotfix+Rollup+Package"

Install Windows Server 2003 SP2 to address problems that may

occur with PAC verification for services
For more information about problems that may occur with PAC verification for services, see Microsoft
Knowledge Base article 906736, "You experience a delay in the user-authentication process when you
run a high-volume server program on a domain member in Windows 2000 or Windows Server 2003" at
http://support.microsoft.com/kb/906736.

Use the Interrupt Filter Configuration tool to bind network adapter

interrupts to specific processors on multiprocessor computers
The Windows Server 2003 Resource Kit includes a tool called the Interrupt Filter Configuration tool
(IntFltr). The Intfltr tool allows you to “bind” or change the CPU affinity of the interrupts for a given
device (such as a network adapter) to a specific processor or processors on a multiprocessor computer.
This binding is also referred to as partitioning. The binding of interrupts from a specific network adapter
to specific processors on a multiprocessor computer enforces running deferred procedure calls (DPCs)
and interrupt service routines (ISRs) for the network adapter on the designated processors. Note that
interrupt affinity cannot be configured on single processor computers.

Note
A DPC is defined as a queued call to a kernel-mode function that will usually be executed at a
later time. An ISR is defined as a routine whose purpose is to service a device when it
generates an interrupt. For more information about deferred procedure calls and interrupt
service routines, see the Windows Driver Kit documentation at http://go.microsoft.com/fwlink/?
LinkId=84418.
Interrupt Filter Configuration Tool

On Windows Server 2003 based multiprocessor computers, the default behavior of the interrupt
controller is to assign device interrupts to any available processor. When network connections and file
server sessions for a given network adapter are filtered/bound/partitioned to run on a specific set of
processors, rather than any available processor, the performance and scalability of the associated
network processing is improved. Large BizTalk Server solutions often employ the use of multi-processor
SQL Server computers with multiple network adapters for which interrupt filtering may be particularly
beneficial.
Interrupt filtering using Intfiltr should always be evaluated in a test environment before employing in a
production environment. The hardware, operating system and application configuration of the test
environment should approximate the production environment as closely as possible. This will allow you
to test various permutations of interrupt filtering and determine the extent that interrupt filtering will
increase performance.
It is recommended that you disable hyper-threading before configuring Intfiltr on a computer with CPUs
that supports hyper-threading. This will ensure that interrupts are assigned to physical processors
rather than logical processors. Assigning interrupt affinity to logical processors that refer to the same
physical processor will not increase performance and could even degrade system performance.
The Interrupt Filter Configuration tool is available with the Server 2003 Resource Kit Tools at
http://go.microsoft.com/fwlink/?LinkId=106079.

Use the NTFS file system on all volumes

Windows Server offers multiple file system types for formatting drives, including NTFS, FAT, and FAT32.
NTFS should always be the file system of choice for servers.
NTFS offers considerable performance benefits over the FAT and FAT32 file systems and should be
used exclusively on Windows servers. In addition, NTFS offers many security, scalability, stability and
recoverability benefits over FAT and FAT32.
Under previous versions of Windows, FAT and FAT32 were often implemented for smaller volumes (say
<500 MB) because they were often faster in such situations. With disk storage relatively inexpensive
today and operating systems and applications pushing drive capacity to a maximum, it is unlikely that
such small volumes will be in use. FAT32 scales better than FAT on larger volumes but is still not an
appropriate file system for Windows servers.
FAT and FAT32 have often been implemented in the past as they were seen as more easily recoverable
and manageable with native DOS tools in the event of a problem with a volume. Today, with the various
NTFS recoverability tools built both natively into the operating system and available as third-party
utilities available, there should no longer be a valid argument for not using NTFS for file systems.

Do not use NTFS file compression

Though using NTFS file system compression is an easy way to reduce space on volumes, it is not
appropriate for enterprise file servers. Implementing compression places an unnecessary overhead on
the CPU for all disk operations and is best avoided. Think about options for adding additional disks,
near-line storage or consider archiving data before seriously considering file system compression.

Review disk controller stripe size and volume allocation units

When configuring drive arrays and logical drives within your hardware drive controller, ensure you
match the controller stripe size with the allocation unit size that the volumes will be formatted with. This
will ensure disk read and write performance is optimal and offer better overall server performance.
Configuring larger allocation unit (or cluster or block) sizes will cause disk space to be used less
efficiently, but will also provide higher disk I/O performance as the disk head can read in more data
during each read activity.
To determine the optimal setting to configure the controller and format the disks with, you should
determine the average disk transfer size on the disk subsystem of a server with similar file system
characteristics. Use the Windows Performance Monitor tool to monitor the Logical Disk object counters
of Avg. Disk Bytes/Read and Avg. Disk Bytes/Write over a period of normal activity to help determine
the best value to use.
Although smaller allocation unit sizes may be warranted if the system will be accessing many small files
or records, an allocation unit size of 64 KB delivers sound performance and I/O throughput under most
circumstances. Improvements in performance with tuned allocation unit sizes can be particularly noted
when disk load increases.

Note
Either the FORMAT command line tool or the Disk Management tool is required to specify an
allocation unit size larger than 4096 bytes (4 KB) when formatting volumes. Windows Explorer
will only format up to this threshold. The CHKDSK command can be used to confirm the current
allocation unit size of a volume however it needs to scan the entire volume before the desired
information is displayed (shown as Bytes in each allocation unit).
Monitor drive space utilization
The less data a disk has on it, the faster it will operate. This is because on a well defragmented drive,
data is written as close to the outer edge of the disk as possible, as this is where the disk spins the
fastest and yields the best performance.
Disk seek time is normally considerably longer than read or write activities. As noted above, data is
initially written to the outside edge of a disk. As demand for disk storage increases and free space
reduces, data is written closer to the center of the disk. Disk seek time is increased in locating the data
as the head moves away from the edge, and when found, it takes longer to read, hindering disk I/O
performance.
This means that monitoring disk space utilization is important not just for capacity reasons but for
performance also.
As a rule of thumb, work towards a goal of keeping disk free space between 20% to 25% of total disk
space. If free disk space drops below this threshold, then disk I/O performance will be negatively
impacted.

Implement a strategy to avoid disk fragmentation

Run a defragmenter utility regularly on your disks, including the root drive, to prevent performance
degradation. Do this weekly on busy disks. A disk defragmenter is installed with Windows and can be
run from a Scheduled Task at specified intervals.

Optimize Windows Server performance for background services

The BizTalk Server process (BTSNTSVC.exe) runs as a background service. By default, Windows
Server is configured to adjust for best performance of application programs and not for background
services.
Windows Server 2003 uses preemptive multi-tasking to prioritize process threads that will be attended
to by the CPU. Preemptive multi-tasking is a methodology whereby the execution of a process is halted
and another process is started, at the discretion of the operating system. This scheme prevents a single
thread from dominating the CPU.
Switching the CPU from executing one process to the next is known as context-switching. The
Windows operating system includes a setting that determines how long individual threads are allowed
to run on the CPU before a context-switch occurs and the next thread is serviced. This amount of time
is referred to as a quantum. This setting lets you choose how processor quanta are shared between
foreground programs and background services. Typically for a server it is not desirable to allow a
foreground program to have more CPU time allocated to it than background services. That is, all
applications and their processes running on the server should be given equal consideration for CPU
time.
To increase performance for background service like BizTalk host instances, follow these steps:
1. Click Start, click Control Panel, and then click System.
2. Click the Advanced tab, and then click Settings under Performance.
3. Click the Advanced tab, click Background services, and then click OK twice.
Disable non-essential services
A default installation of Windows Server 2003 enables several services that may not be required in a
BizTalk Server environment. Each running service consumes system resources and so unnecessary
services should be disabled to improve overall performance.
Care should be taken when disabling services. Thoroughly research the purpose of a service before
disabling the service as Windows Server requires certain services are running. If services required by
Windows Server 2003 are disabled, the operating system may become inoperable and possibly even
unable to boot.
To disable Windows Server 2003 services that are not required for a dedicated BizTalk Server, follow
these steps:
1. Click Start, point to Programs, point to Administrative Tools, and then click Computer
Management.
2. Under Computer Management (Local), expand Services and Applications, and then click
Services.
In the Status column, each service that is running is labeled "Started." Stop and disable any
service that is started unnecessarily, for example, the following services are not required on a
dedicated BizTalk Server:
 Alerter
 ClipBook
 DHCP Client
 DHCP Server
 Fax Service
 File Replication
 Infrared Monitor
 Internet Connection Sharing
 Messenger
 NetMeeting Remote Desktop Sharing
 Network DDE
 Network DDE DSDM
 NWLink NetBIOS
 NWLink IPX/SP
 Print Spooler
 Telephony
 Telnet
 Uninterruptible Power Supply
3. Note the services that depend on each service that you want to disable. To do this, follow these
steps:
 a. Double-click the service you want to disable.
b. Click the Dependencies tab.
c. In the This service depends on the following system components list, note the services
this service depends on.
d. In the The following system components depend on this service list, note the services that
cannot start without this service, and then click OK.
4. One at a time, disable each service you have selected. To do this, follow these steps:
a. Right-click the service you want to disable, and then click Properties.
b. In the Startup type list, click Disabled.
c. If you want to stop the service immediately, click Stop.
If the Stop Other Services dialog box appears, note the other dependent services that will also
stop, and then click Yes, and then click OK.
5. Repeat step 4 to disable the other nonessential services.

Note
Test the server for correct operation after you disable each service to make sure you did not
disable a service you want to continue to use.
If the server is a member of a Windows Server 2003 domain, which BizTalk Servers typically
are, you must have the TCP/IP helper service on your system to correctly apply Group Policy to
the computer.
When you disable the DHCP client, the DHCP client stops DNS dynamic update protocol
registration and requires manual DNS records to be added for this client in the DNS server.

Manually load Microsoft Certificate Revocation lists

When starting a .NET application, the .NET Framework will attempt to download the Certificate
Revocation list (CRL) for any signed assembly. If your system does not have direct access to the
Internet, or is restricted from accessing the Microsoft.com domain, this may delay startup of BizTalk
Server. To avoid this delay at application startup, you can use the following steps to manually download
and install the code signing Certificate Revocation Lists on your system.
1. Download the latest CRL updates from http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
and http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl.
2. Move the CodeSignPCA.crl and CodeSignPCA2.crl files to the isolated system.
3. From a command prompt, enter the following command to use the certutil utility to update the local
certificate store with the CRL downloaded in step 1:
certutil –addstore CA c:\CodeSignPCA.crl
The CRL files are updated regularly, so you should consider setting a reoccurring task of downloading
and installing the CRL updates. To view the next update time, double-click the .crl file and view the
value of the Next Update field.
Synchronize time on all servers
Many operations involving tickets, receipts and logging rely on the local system clock being accurate.
This is especially true in a distributed environment, where time discrepancies between systems may
cause logs to be out of sync or tickets issued by one system to be rejected by another as expired or not
yet valid.
For more information on configuring a server to automatically synchronize time, see
http://go.microsoft.com/fwlink/?LinkId=99420.

Configure the Windows PAGEFILE for optimal performance

Follow these guidelines to configure the Windows PAGEFILE (paging file) for optimal performance:
1. Move the paging file to a physical volume separate from the physical drive that operating
system is installed on to reduce disk contention and increase disk performance - On BizTalk
Server computers, the performance gain associated with moving the paging file will vary depending
on the document processing load. On SQL Server computers, moving the paging file to a separate
volume is considered a best practice in all scenarios due to the disk intensive nature of SQL Server.
2. Isolate the paging file onto one or more dedicated physical drives that are configured as
either RAID-0 (striping) or RAID-1 (mirroring) arrays, or on single disks without RAID - By
using a dedicated disk or drive array where PAGEFILE.SYS is the only file on the entire volume, the
paging file will not become fragmented, which will also improve performance. As with most disk-
arrays, performance of the array is improved as the number of physical disks in the array is
increased. If the paging file is distributed between multiple volumes on multiple physical drives in a
disk array, the paging file size should be the same size on each drive in the array. When configuring
a disk array, it is also recommended to use physical drives that have the same capacity and speed.
Note that redundancy is not normally required for the paging file.
3. Do not configure the paging file on a RAID 5 array - Configuration of the paging file on a RAID 5
array is not recommended because paging file activity is write intensive and RAID 5 arrays are
better suited for read performance than write performance.
4. If you do not have resources to move the paging file to a physical volume other than the
operating system is installed on, configure the paging file to reside on the same logical
volume as the operating system - Configuring the paging file to reside on a another logical
volume which is on the same physical disk as the operating system will increase disk seek time and
reduce system performance as the disk drive platter heads will be continually moving between the
volumes, alternately accessing the page file, operating system files, application files, and data files.
Also, the operating system is typically installed on the first partition of a physical disk, which is
usually the closest to the outside edge of the physical disk and where disk speed is and associated
performance are optimal for the disk.

Important
If you do remove the paging file from the boot partition, Windows cannot create a crash
dump file (MEMORY.DMP) in which to write debugging information in the event that a
kernel mode STOP error occurs. If you do require a crash dump file, then you will have no
 option but to leave a paging file of at least the size of physical memory + 1 MB on the boot
partition.
5. Manually set the size of the paging file – Manually setting the size of the paging file typically
provides better performance than allowing the server to size it automatically or having no paging file
at all. Best-practice tuning is to set the initial (minimum) and maximum size settings for the paging
file to the same value. This ensures that no processing resources are lost to the dynamic resizing of
the paging file, which can be intensive. This is especially true given that this resizing activity
typically occurs when the memory resources on the system are already becoming constrained.
Setting the same minimum and maximum page file size values also ensures the paging area on a
disk is one single, contiguous area, improving disk seek time. Windows Server 2003 automatically
recommends a total paging file size equal to 1.5 times the amount of installed RAM. On servers
with adequate disk space, the paging file on all disks combined should be configured up to twice
the physical memory for optimal performance.

Remove CPU-intensive screen savers

3D or OpenGL screen savers are known to be CPU-intensive and use important system resources
when they are running. It is best to avoid installing these altogether as an option at server-build time, or
to remove them if they have been installed. The basic “Windows Server 2003” or blank screen savers
are an excellent alternative to using CPU-intensive screen savers.

Registry settings that can be modified to improve

operating system performance
This section provides a description of recommended values for several registry entries that impact
operating system performance. These registry entries can be applied manually or can be applied via
the operating system optimization PowerShell script included in Windows PowerShell Scripts.

Increase available worker threads

At system startup, Windows creates several server threads that operate as part of the System process.
These are called system worker threads. They exist with the sole purpose of performing work on the
behalf of other threads generated by the kernel, system device drivers, the system executive and other
components. When one of these components puts a work item in a queue, a thread is assigned to
process it.
The number of system worker threads should ideally be high enough to accept work tasks as soon as
they become assigned. The trade off, of course, is that worker threads sitting idle consume system
resources unnecessarily. Modify and/or create the following REG_DWORD values in the registry and
then set to the recommended values listed below.
The AdditionalDelayedWorkerThreads value increases the number of delayed worker threads
created for the specified work queue. Delayed worker threads process work items that are not
considered time-critical and can have their memory stack paged out while waiting for work items. An
insufficient number of threads will reduce the rate at which work items are serviced; a value that is too
high will consume system resources unnecessarily.

AdditionalDelayedWorkerThreads
Key: HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Executiv
e
Value: AdditionalDelayedWorkerThreads
Data Type: REG_DWORD
Range: 0x0 (default) to 0x10 (16)
Recommended value: 0x10 (16)
Value exists by default? Yes

The AdditionalCriticalWorkerThreads value increases the number of critical worker threads created
for a specified work queue. Critical worker threads process time-critical work items and have their stack
present in physical memory at all times. An insufficient number of threads will reduce the rate at which
time-critical work items are serviced; a value that is too high will consume system resources
unnecessarily.

AdditionalCriticalWorkerThreads
Key: HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Executiv
e
Value: AdditionalCriticalWorkerThreads
Data Type: REG_DWORD
Range: 0x0 (default) to 0x10 (16)
Recommended value: 0x10 (16)
Value exists by default? Yes

Disable Windows Server 2003 SP 1 and SP2 denial of service

checking
Windows Server 2003 Service Pack 1 and Service Pack 2 denial of service checking should be
disabled. This is because under certain high-load scenarios, Windows Server 2003 SP1 and SP2 denial
of service checking may incorrectly identify valid TCP/IP connections as a denial of service attack.

Important
Only disable this feature in an intranet scenario when you are sure you will not suffer from
actual denial of service attacks.
For more information about disabling Windows Server Denial of Service Checking, see Microsoft
Knowledge Base article 889599, "A BizTalk Server Host instance fails, and a 'General Network' error is
written to the Application log when the BizTalk Server-based server processes a high volume of
documents" at http://support.microsoft.com/kb/899599. Follow the instructions in this article to create
the SynAttackProtect registry entry on computers running SQL Server that host BizTalk Server
databases and on any computers running BizTalk Server running Windows Server 2003 SP1 or later.
Registry settings that govern the level of denial of service attack protection - In certain scenarios
you may want to maintain denial of service protection but reduce how aggressively the denial of service
functionality is applied. It is possible to tune the default behavior of the denial of service protection
feature by following these steps:
1. Ensure the SynAttackProtect registry entry is set to a REG_DWORD value of 1 as described at
http://go.microsoft.com/fwlink/?LinkId=111477.
2. Configure the TcpMaxHalfOpen registry entry as described at http://go.microsoft.com/fwlink/?
LinkId=111478.
3. Configure the TcpMaxHalfOpenRetried registry entry as described at
http://go.microsoft.com/fwlink/?LinkId=111479.

Disable LDAP client signing requirements for computers in a secure

intranet environment
Computers running Windows XP with Service Pack 1 (SP1) and higher, and Computers running
Windows Server 2003 SP3 and higher provide the ability to enforce LDAP client signing requirements
to mitigate “man in the middle” attacks where an intruder captures packets between a client and a
server, modifies them, and then forwards them to the server. When this occurs on an LDAP server, an
attacker could cause a server to respond based on false queries from the LDAP client. Such “man-in-
the-middle” attacks can be mitigated by requiring digital signatures on all network packets by means of
IPSec authentication headers. Computers in a secure intranet environment should disable this option to
reduce the overhead associated with LDAP client signing. You can modify this setting on computers
running Windows Server 2003 SP3 and higher by changing the following registry entry from a
REG_DWORD value of 1 to a REG_DWORD value of 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\ldapclientintegrity = REG_DWORD 0x0

Increase space available for the master file table

Add the NtfsMftZoneReservation entry to the registry to allow the master file table (MFT) to grow
optimally. When you add this entry to the registry, the system reserves space on the volume for the
master file table. If your NTFS volumes contain relatively few large files, set the value of this registry
entry to 1 (the default). Typically you can set this entry to a value of 2 or 3 for volumes that contain a
moderate numbers of files, and use a value of 4 (the maximum) if your volumes tend to contain a
relatively large number of files.
 Important
Test any settings greater than 2, because setting this entry to a value greater than 2 will cause
the system to reserve a much larger portion of the disk for the master file table.

NtfsMftZoneReservation
Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSyste
m
Value: NtfsMftZoneReservation
Data Type: REG_DWORD
Range: 1–4
Default value: 1
Recommended value:  1 if volumes typically store fewer files.
 2 or 3 if volumes typically store a moderate
number of files.
 4 if volumes typically store a large number of files.
Value exists by default? No, needs to be added.

Change registry settings to maximize server service performance

The maximum number of concurrent outstanding network requests between a Windows Server
Message Block (SMB) client and server is determined when a session between the client and server is
negotiated. The maximum value negotiated is determined by registry settings on both the client and
server. If these values are set too low on the server, they can restrict the number of client sessions that
can be established with the server.
The values that can be adjusted to improve system performance for work items exist in the
LanmanServer and LanmanWorkstation registry keys and are:
 MaxWorkItems
 MaxMpxCt
 MaxCmds

Note
These values do not exist in the registry by default.
The MaxWorkItems value specifies the maximum number of receive buffers, or work items, the Server
service is permitted to allocate at one time. If this limit is reached, then the transport must initiate flow
control, which can significantly reduce performance.

MaxWorkItems
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameter
s
 Value: MaxWorkItems
Data Type: REG_DWORD
Range: 0 – 65535
Default value: Configured dynamically
Recommended value: 8192
Note
The MaxWorkItems value must be at least four times as large
as the MaxMpxCt value.
Value exists by default? No, needs to be added.

The MaxMpxCt value enforces the maximum number of simultaneous outstanding requests from a
particular client to a server. During negotiation of a Server Message Block between the client and the
server, this value is passed to the client's redirector where the limit on outstanding requests is enforced.
A higher value can increase server performance but requires more use of server work items
(MaxWorkItems).

MaxMpxCt
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameter
s
Value: MaxMpxCt
Data Type: REG_DWORD
Range: 0 – 65535
Default value: 50
Recommended value: 2048
Note
The MaxWorkItems value must be at least four times as large
as the MaxMpxCt value.
Value exists by default? No, needs to be added.

The MaxCmds value specifies the maximum number of network control blocks the redirector can
reserve. The value of this entry coincides with the number of execution threads that can be outstanding
simultaneously. Increasing this value will improve network throughput, especially if you are running
applications that perform more than 15 operations simultaneously. This value is set on the SMB client
computer.
MaxCmds
Key: HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameter
s
Value: MaxCmds
Data Type: REG_DWORD
Range: 0 – 65535
Default value: 50
Recommended value: 2048
Value exists by default? No, needs to be added.

Note
Start with the default or recommended values for these registry keys, and increase the value in
small increments as needed. The more outstanding connections that exist, the more memory
resources will be used by the server. If you set the values too high, the server could run out of
resources such as paged pool memory.
For more information about setting these values, see Microsoft Knowledge Base article “How to
troubleshoot Event ID 2021 and Event ID 2022” at http://support.microsoft.com/kb/317249 and see
Microsoft Knowledge Base article "The network BIOS command limit has been reached" error message
in Windows Server 2003, in Windows XP, and in Windows 2000 Server available at
http://support.microsoft.com/kb/810886.

Disable short-file-name (8.3) generation

When a long file name is created using the Windows NTFS file system, the default behavior is to
generate a corresponding short file name in the older 8.3 DOS file name convention for compatibility
with older operating systems. This functionality can be disabled through a registry entry, offering a
performance increase.

Caution
Before disabling short name generation, ensure there are no DOS or 16-bit applications
running on the server that require 8.3 file names.

NTFSDisable8dot3NameCreation
Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSyste
m
Value: NTFSDisable8dot3NameCreation
Data Type: REG_DWORD
 Range: 0–1
Default value: 0
Recommended value: 1
Value exists by default? Yes

In Windows Server 2003, this value can be set by using the following command:
fsutil behavior set disable8dot3 1

Optimize data throughput for network applications

If Windows Server is configured to optimize data throughput for network applications, the working set of
BizTalk Server and other applications will have a priority over the working set of the file system cache.
This setting is normally the best setting to use for all servers except dedicated file servers or with
applications exhibiting file server-like characteristics.
To optimize data throughput for network applications follow these steps:
1. In Windows Explorer, right-click My Network Places, and then click Properties.
2. Right-click the Local Area Connection you want to optimize, and then click Properties.
3. In the This connection uses the following items list, click (but do not clear its check box) File
and Printer Sharing for Microsoft Networks, and then click Properties.
4. Click Maximize data throughput for network applications, click OK, and then click Close.
Optimize data throughput for network applications can also be applied by setting the following registry
entries to the recommended values:

Size
Key: HKLM\System\CurrentControlSet\Services\LanmanServer\Parameter
s
Value: Size
Data Type: REG_DWORD
Recommended value: 3
Value exists by default? Yes

LargeSystemCache
Key: HKLM\System\CurrentControlSet\Control\Sessio
n Manager\MemoryManagement
Value: LargeSystemCache
Data Type: REG_DWORD
 Recommended value: 0
Value exists by default? Yes

Disable random driver verification

The driver verifier at random intervals verifies drivers for debugging. Disabling this functionality might
improve system performance. For many high-throughput systems, every CPU cycle counts. Disable
random driver verification with the following registry entry:

DontVerifyRandomDrivers
Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSyste
m
Value: DontVerifyRandomDrivers
Data Type: REG_DWORD
Range: 0–1
Default value: 0
Recommended value: 1
Value exists by default? No, needs to be added.

Disable NTFS last access updates

Each file and folder on an NTFS volume includes an attribute called Last Access Time. This attribute
shows when the file or folder was last accessed, such as when a user performs a folder listing, adds
files to a folder, reads a file, or makes changes to a file. Maintaining this information creates
performance overhead for the file system especially in environments where a large number of files and
directories are accessed quickly and in a short period of time, for example when using the BizTalk File
Adapter. Apart from in highly secure environments, retaining this information might add a burden to a
server that can be avoided by updating the following registry key:

NTFSDisableLastAccessUpdate
Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSyste
m
Value: NTFSDisableLastAccessUpdate
Data Type: REG_DWORD
Range: 0–1
Default value: 0
Recommended value: 1
 Value exists by default? No, needs to be added.

In Windows Server 2003, this value can be set by using the following command:
fsutil behavior set disablelastaccess 1

For more information about disabling NTFS last access update, see the Windows Server 2003
Deployment Guide at http://go.microsoft.com/fwlink/?LinkID=111188

Applying registry settings with the operating system

optimization Windows PowerShell script
This guide includes a Windows PowerShell script that can be executed on each computer in the BizTalk
Server environment to apply registry settings that will optimize operating system performance, using the
recommended values discussed in this topic. To run this script follow these steps:
1. Install Windows PowerShell – Windows PowerShell can be downloaded from
http://go.microsoft.com/fwlink/?LinkId=77521. PowerShell must be installed in order to run the
operating system optimization script.
2. Run the operating system optimization script
a. Copy the script from the “Optimizing operating system performance registry settings” section of
Windows PowerShell Scripts into notepad and save as Set-OSRegSettings.ps1.
b. Launch PowerShell and change directories to the folder that contains the saved script.
c. Execute the script with the following command:
.\Set-OSRegSettings.ps1 –RAMMb <Installed memory in MB> -NumCPU <number of CPUs>
-VolType <Volume types, valid values are 1(few files), 2 or 3(moderate files), 4(many
files)>

Note
If the script does not run, or opens in Notepad instead of running, ensure the
PowerShell execution policy permits running PowerShell scripts. To determine the
current PowerShell execution policy run the Get-ExecutionPolicy PowerShell
command. To change the current PowerShell execution policy run the Set-
ExecutionPolicy PowerShell command.
The operating system optimizations PowerShell script generates a log file named “OSSettings.log”
in the directory from which the script was executed. This log file details which values were changed
and lists the original value as well as the new value. For simplicity sake, and so that all logs are
accessible from the same place, it is recommended that this script is placed in a networked file
share and that the script is run from that file share on all computers in the BizTalk Server
environment.
Optimizing Network Performance
In a BizTalk Server environment where the BizTalk Server computer(s) are separate from the SQL
Server computer(s), each and every message processed by BizTalk Server requires communication
over the network. This communication includes considerable traffic between the BizTalk Server
computers and the BizTalk Message Box database(s), the BizTalk Management database(s), the BAM
databases, and other databases. In high-load scenarios, this communication can result in considerable
network traffic and can become a bottleneck, especially when network settings have not been
optimized, not enough network interface cards are installed, or insufficient network bandwidth is
available.
This topic provides some general recommendations for improving network performance and describes
several registry entries that can be modified to optimize the network stack to mitigate the occurrence of
bottlenecks on the network.

Important
Some of the recommendations in this topic require modifications to the Windows registry.
Incorrect use of Registry Editor may cause problems requiring you to reinstall your operating
system. Use Registry Editor at your own risk. For more information about how to back up,
restore, and modify the registry, see the Microsoft Knowledge Base article "Description of the
Microsoft Windows registry" at http://go.microsoft.com/fwlink/?LinkId=62729.
Adjusting network settings to optimal values has been shown to effectively address network bottlenecks
and improve overall network performance in BizTalk Server solutions. This should be done on all
computers involved in the solution, including BizTalk Server computers, SQL Server computers, and
any other server computers.

Note
The most common indicator that Network IO is a bottleneck is the counter “SQL Server:Wait
Statistics\Network IO waits”. When the value for Avg Wait Time in this counter is greater than
zero on one or more of your SQL Server computers, then Network IO is a bottleneck.

General guidelines for improving network

performance
The following recommendations can be used to increase network performance:

Add additional network cards to computers in the BizTalk Server

environment
Just as adding additional hard drives can improve disk performance, adding additional network cards
can improve network performance. If the network cards on the computers in your BizTalk Server
environment are saturated and the card is a bottleneck, consider adding one or more additional network
cards to improve performance.
Implement network segmentation
Follow the recommendations in the Subnets section of the "BizTalk Server Database Optimization"
whitepaper at http://go.microsoft.com/fwlink/?LinkID=101578.

Where possible, replace hubs with switches

Switches contain logic to directly route traffic between the source and destination whereas hubs use a
broadcast model to route traffic. Therefore switches are more efficient and offer improved performance.

Remove unnecessary network protocols

Windows Server computers sometimes have more network services and protocols installed than are
actually required. Each additional network client, service or protocol places additional overhead on
system resources.
In addition, each installed protocol generates network traffic. By removing unnecessary network clients,
services and protocols, system resources are made available for other processes, excess network
traffic is avoided and the number of network bindings that must be negotiated is reduced to a minimum.
To see the currently installed network clients, protocols and services, follow these steps:
1. Click Start, point to Settings, and then click Control Panel.
2. Double-click Network Connections to display the network connections on the computer.
3. Right-click Local Area Connection (or the entry for your network connection), and then click
Properties to display the properties dialog box for the network connection.
4. To remove an unnecessary item, select it and click Uninstall. To disable an item, simply clear the
checkbox associated with the item.
If you are unsure about the effects of uninstalling an item for the connection, then disable the item
rather than uninstalling it. Disabling items allows you to determine which services, protocols and clients
are actually required on a system. When it has been determined that disabling an item has no adverse
affect on the server, the item can then be uninstalled.
In many cases, only the following three components are required for operation on a standard TCP/IP
based network:
 Client for Microsoft Networks
 File and Printer Sharing for Microsoft Networks
 Internet Protocol (TCP/IP)

Scalable Network Pack

The Scalable Network Pack (SNP) contains enhancements to support network acceleration and
hardware-based offloading features present in some newer network cards. Installing the Scalable
Network Pack (enabled by default in Windows Service Pack 2,) may enable performance gains on
some systems, however, on some systems you may experience network related problems, such as
slow network performance or the inability to use some networking protocols such as RDP or FTP.
If you experience network problems after installing Windows SP2, uninstalling, or disabling the SNP
may resolve these issues. For more information on removing or disabling the SNP, see
http://support.microsoft.com/kb/948496.

Network adapter drivers on all computers in the BizTalk Server

environment should be tuned for performance
Adjust the network adapter device drivers to maximize the amount of memory available for packet
buffering, both incoming and outgoing. Also maximize buffer counts, especially transmit buffers and
coalesce buffers. The default values for these parameters, and whether they are even provided, vary
between manufacturers and driver versions. The goal is to maximize the work done by the network
adapter hardware, and to allow the greatest possible buffer space for network operations to mitigate
network traffic bursts and associated congestion.

Note
Steps to tune network adapter drivers vary by manufacturer.
Follow these steps to access settings for network adapters in Windows Server 2003:
1. Click Start, point to Settings, click Control Panel, and then double-click Network Connections.
2. Right-click Local Area Connection (or the name of your network connection), and then click
Properties.
3. On the General tab, click Configure.
4. Click the Advanced tab to access properties that can be configured for the network adapter.
The following properties should be configured for each network adapter in the BizTalk Server
environment:

Note
You apply these settings for each physical network adapter, including the individual network
adapters within a teamed set of network adapters that are configured for aggregation, load
balancing, or fault tolerance. With some teaming software, you might need to apply these
settings to the team also. Note that some network adapters are self-tuning and may not offer
the option to configure parameters manually.
 Power Option – Configure the network adapter driver to prevent power management functionality
from turning off the network adapter to save power. This functionality may be useful for client
computers but should seldom, if ever, be used on a BizTalk Server or SQL Server computer.
 Fixed Speed/Duplex (do not use AUTO) - It is very important that the network speed, duplex, and
flow control parameters are set to correspond to the settings on the switch to which they are
connected. This will mitigate the occurrence of periodic “auto-synchronization” which may
temporarily take connections off-line.
 Max Coalesce Buffers - Map registers are system resources used to convert physical addresses
to virtual addresses for network adapters that support bus mastering. Coalesce buffers are
available to the network driver if the driver runs out of map registers. Set this value as high as
 possible for maximum performance. On servers with limited physical memory, this may have a
negative impact as coalesce buffers consume system memory. On most systems however, the
maximum setting can be applied without significantly reducing available memory.
 Max Transmit/Send Descriptors and Send Buffers - This setting specifies how many transmit
control buffers the driver allocates for use by the network interface. This directly reflects the number
of outstanding packets the driver can have in its “send” queue. Set this value as high as possible for
maximum performance. On servers with limited physical memory, this may have a negative impact
as send buffers consume system memory. On most systems however, the maximum setting can be
applied without significantly reducing available memory.
 Max Receive Buffers - This setting specifies the amount of memory buffer used by the network
interface driver when copying data to the protocol memory. It is normally set by default to a
relatively low value. Set this value as high as possible for maximum performance. On servers with
limited physical memory, this may have a negative impact as receive buffers consume system
memory. On most systems however, the maximum setting can be applied without significantly
reducing available memory.
 All offload options ON - In almost all cases performance is improved when enabling network
interface offload features. Some network adapters provide separate parameters to enable or
disable offloading for send and receive traffic. Offloading tasks from the CPU to the network adapter
can help lower CPU usage on the server which will improve overall system performance. The
Microsoft TCP/IP transport can offload one or more of the following tasks to a network adapter that
has the appropriate capabilities:
 Checksum tasks - The TCP/IP transport can offload the calculation and validation of IP and
TCP checksums for sends and receives to the network adapter, enable this option if the
network adapter driver provides this capability.
 IP security tasks - The TCP/IP transport can offload the calculation and validation of encrypted
checksums for authentication headers (AH) and encapsulating security payloads (ESP) to the
network adapter. The TCP/IP transport can also offload the encryption and decryption of ESP
payloads to the network adapter. Enable these options if the network adapter driver provides
this capability.
 Segmentation of large TCP packets - The TCP/IP transport supports large send offload
(LSO). With LSO, the TCP/IP transport can offload the segmentation of large TCP packets.
 Stack Offload – The entire network stack can be offloaded to a network adapter that has the
appropriate capabilities. Enable this option if the network adapter driver provides this capability.
 Wake On LAN disabled (unless being used) – Configure the network adapter driver to disable
wake-on lan functionality. This functionality may be useful for client computers but should seldom if
ever be used on a BizTalk Server or SQL Server computer.
For more information about tuning network adapters for performance, see the Network Device
Settings section of the "BizTalk Server Database Optimization" whitepaper at
http://go.microsoft.com/fwlink/?LinkID=101578.
Registry settings that can be modified to improve
network performance
This section provides a description of recommended values for several registry entries that impact
network performance. These registry entries can be applied manually or can be applied via the
operating system optimization PowerShell script included in Windows PowerShell Scripts.
The DisablePagingExecutive value governs whether or not Windows will page the NT executive to
disk. Setting this entry to a value of 1 will prevent pageable drivers and system code in the Windows NT
Executive from being paged out to disk. Although this decreases the response time in systems with
extremely large amounts of physical memory (RAM), it is critical that there is enough RAM installed,
otherwise the server could be rendered unstable. For more information about the
DisablePagingExecutive registry entry, see http://go.microsoft.com/fwlink/?LinkId=113707.

DisablePagingExecutive
Key: HKLM:\System\CurrentControlSet\Control\Sessio
n Manager\Memory Management
Value: DisablePagingExecutive
Data Type: REG_DWORD
Range: 0 to 1
Default value: 0
Recommended value: 1
Value exists by default? Yes

The IRPStackSize value specifies the number of stack locations in I/O request packets (IRPs) that are
used by Windows 2000 Server, by Windows Server 2003, and by Windows XP. You may have to
increase this number for certain transports, for media access control (MAC) drivers, or for file system
drivers. Each stack uses 36 bytes of memory for each receive buffer. For more information about the
IRPStackSize registry entry, see Microsoft Knowledge Base Article 285089, “Description of the
IRPStackSize parameter in Windows 2000, in Windows XP, and in Windows Server 2003” at
http://support.microsoft.com/kb/285089.

IRPStackSize
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Para
meters
Value: IRPStackSize
Data Type: REG_DWORD
Range: 11 to 50
Default value: 15
 Recommend 32
ed value:
Value exists No, needs to be added.
by default?

The SizReqBuf value specifies the size in bytes of the raw receive buffers (work items) that the Server
service uses. Small work items use less memory, but large work items can improve performance. The
value that works best in a particular environment depends on the configuration of that environment. For
an optional value, you might try increasing the value as high as 4410 (hexadecimal); this has been
shown to work well in a fairly standard Ethernet environment. However, going over setting a value over
4000 hexadecimal has been seen to cause other issues on some servers. Therefore, the default
starting point for the SizeReqBuf entry should be 4000 hexadecimal (16384 decimal). By default, the
value for this entry is 4356 bytes on servers with less than 512 MB of memory. On servers with more
than 512 MB of memory, this value is increased to 16384 bytes (16 KB). A receive buffer that is larger
can improve performance on directory queries and similar commands, but at the price of more memory
per work item.
Increasing the SizReqBuf value can increase performance significantly in a high-latency environment.
However, note that increasing the SizReqBuf value also increases the non-paged pool memory used
by the Server service. If you increase the SizReqBuf value, monitor non-paged pool memory to make
sure that the change does not adversely impact the performance of the server.

SizReqBuf
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Para
meters
Value: SizReqBuf
Data Type: REG_DWORD
Range: 1-65535
Default value: 16,384 (bytes) on servers with 512 MB or more or physical memory, 4,356 (bytes) on
servers with less than 512 MB physical memory.
Recommend 17424 (bytes) on servers with 512 MB or more or physical memory, 4,356 (bytes) on
ed value: servers with less than 512 MB physical memory.
Value exists No, needs to be added.
by default?

Review the following information to configure TCP/IP registry settings for optimal performance:
 "Avoiding TCP/IP Port Exhaustion" at http://go.microsoft.com/fwlink/?LinkId=101610.
 Review the "HKLM\SYSTEM\CurrentControlSet\ Services\Tcpip\Parameters" section of "BizTalk
Server Database Optimization" whitepaper at http://go.microsoft.com/fwlink/?LinkID=101578.
 Review Optimizing Network Performance.

The DefaultTTL value specifies the default time-to-live (TTL) value set in the header of outgoing IP
packets. The TTL determines the maximum amount of time that an IP packet may live in the network
without reaching its destination. It is effectively a limit on the number of links on which an IP packet is
allowed to travel before being discarded.

DefaultTTL
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: DefaultTTL
Data Type: REG_DWORD
Range: 1 to 255 (seconds)
Default value: 128
Recommended 64
value:
Value exists by No, needs to be added
default?

The EnablePMTUDiscovery value governs whether TCP will attempt to discover the Maximum
Transmission Unit (MTU), or largest packet size for the entire path to a remote host. By discovering the
Path MTU (PMTU) and limiting TCP segments to this size, TCP can eliminate packet fragmentation at
routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP
throughput and causes network congestion. Setting this parameter to 0 (or off) causes an MTU of 576
bytes to be used for all connections to destinations other than the local subnet.

Important
This entry should not be set to a value of 1 if the server is directly exposed to potential
attackers.

EnablePMTUDiscovery
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: EnablePMTUDiscovery
Data Type: REG_DWORD
Range: 0 to 1
 Default value: 1
Recommended 1
value:
Value exists by No, needs to be added.
default?

The EnablePMTUBHDetect value governs whether TCP tries to detect black hole routers during the
Path MTU (maximum transmission unit) discovery process. Enabling black hole detection increases the
maximum number of times TCP retransmits a given segment. If the value of this entry is 1, TCP
recognizes when it has transmitted the same segment several times without receiving an
acknowledgement. It reduces the maximum segment size (MSS) to 536 bytes, and it sets the Don't-
Fragment bit. If, as a result, receipt of the segment is acknowledged, TCP continues this practice in all
subsequent transmissions on the connection.

EnablePMTUBHDetect
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: EnablePMTUBHDetect
Data Type: REG_DWORD
Range: 0 to 1
Default value: 0
Recommended 1
value:
Value exists by No, needs to be added.
default?

The TcpMaxDupAcks value determines the number of duplicate ACKs that must be received for the
same sequence number of sent data before fast retransmit is triggered to resend the segment that has
been dropped in transit. If you set the value of this entry to 1, then the system retransmits a segment
when it receives an ACK for a segment with a sequence number that is less than the number of the
segment currently being sent.
When data arrives with a sequence number that is greater than expected, the receiver assumes that
data with the expected number was dropped, and it immediately sends an ACK with the ACK number
set to the expected sequence number. The receiver sends ACKs set to the same missing number each
time it receives a TCP segment that has a sequence number greater than expected. The sender
recognizes the duplicate ACKs and sends the missing segment. The recommended value of 2 is also
the default value but Windows Server 2003 does not add this entry to the registry, so it should be
added.
TcpMaxDupAcks
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: TcpMaxDupAcks
Data Type: REG_DWORD
Range: 1 to 3
Default value: 2
Recommended 2
value:
Value exists by No, needs to be added.
default?

The Tcp1323Opts value governs whether TCP uses the timestamping and window scaling features
described in RFC 1323, TCP Extensions for High Performance. Window scaling permits TCP to
negotiate a scaling factor for the TCP receive window size, allowing for a very large TCP receive
window of up to 1 GB. The TCP receive window is the amount of data that the sending host can send at
one time on a connection. Timestamps help TCP measure round trip time (RTT) accurately in order to
adjust retransmission timeouts. The Timestamps option provides two timestamp fields of 4 bytes each
in the TCP header, one to record the time the initial transmission is sent and one to record the time on
the remote host. This entry is a 2-bit bitmask. The lower bit determines whether scaling is enabled; the
higher bit determines whether timestamps are enabled.

Tcp1323Opts
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: Tcp1323Opts
Data Type: REG_DWORD
Range: 0 to 3
Default value: 3
Recommended 1 (also consider setting to a value of 3 if high packet loss / retransmits are
value: occurring).
Value exists by No, needs to be added.
default?

The SackOpts value governs whether the Selective Acknowledgment (SACK) feature of
Windows Server 2003 TCP/IP is enabled. SACK is an optimizing feature based upon RFC 2018, TCP
Selective Acknowledgement Options. SACK permits receipt acknowledgement of individual blocks of
data in a continuous sequence, rather than just the last sequence number. When SACK is enabled, the
recipient can tell the sender that one or more data blocks are missing from the middle of a sequence,
and the sender can retransmit only the missing data.

SackOpts
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: SackOpts
Data Type: REG_DWORD
Range: 0 to 1
Default value: 1
Recommended 1
value:
Value exists by No, needs to be added.
default?

The MaxFreeTcbs value determines the number of TCP control blocks (TCBs) the system creates to
support active connections. Because each connection requires a control block, this value determines
how many active connections TCP can support simultaneously. If all control blocks are used and more
connection requests arrive, TCP can prematurely release connections in the TIME_WAIT state in order
to free a control block for a new connection.

Note
If the value for this entry is increased, then the value for the MaxHashTableSize value should
also be increased.

MaxFreeTcbs
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: MaxFreeTcbs
Data Type: REG_DWORD
Range: 0 to 4294967295
Default value: Varies with the system and amount of physical memory on the computer. For more
information, see “Appendix A: TCP/IP Configuration Parameters” at
http://go.microsoft.com/fwlink/?LinkId=113716
Recommended 65535
value:
Value exists by No, needs to be added.
 default?

The MaxHashTableSize value controls how fast the system can find a TCB and should be increased if
the MaxFreeTcbs value is increased from its default value.

Note
This value should be set to a power of 2 (for example, 512, 1024, 2048, and so on.) If this value
is not a power of 2, the system configures the hash table to the next power of 2 value (for
example, a setting of 513 is rounded up to 1024).

MaxHashTableSize
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: MaxHashTableSize
Data Type: REG_DWORD
Range: 64 to 65536
Default value: 512
Recommended 65536
value:
Value exists by No, needs to be added.
default?

The MaxUserPort value controls the maximum port number used when an application requests any
available user port from the system. Normally, short-lived ports are allocated in the range from 1024
through 5000. Setting this parameter to a value outside of the valid range causes the nearest valid
value to be used (5000 or 65534).

MaxUserPort
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: MaxUserPort
Data Type: REG_DWORD
Range: 5000 to 65534
Default value: 5000
Recommended 65534
value:
Value exists by No, needs to be added.
 default?

The TcpTimedWaitDelay value determines the length of time that a connection stays in the
TIME_WAIT state when being closed. While a connection is in the TIME_WAIT state, the socket pair
cannot be reused. This is also known as the 2MSL state because the value should be twice the
maximum segment lifetime on the network. For more information, see Internet RFC 793 at
http://go.microsoft.com/fwlink/?LinkId=113719.

TcpTimedWaitDelay
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: TcpTimedWaitDelay
Data Type: REG_DWORD
Range: 30 to 300
Default value: 240
Recommended 30
value:
Value exists by No, needs to be added.
default?

The GlobalMaxTcpWindowSize value specifies the maximum size of the TCP receive window. The
receive window specifies the number of bytes that a sender can transmit without receiving an
acknowledgment. In general, larger receive windows improve performance over high-latency, high-
bandwidth networks. For greatest efficiency, the receive window should be an even multiple of the TCP
Maximum Segment Size.
The TCP/IP stack of Windows Server 2003 was designed to tune itself in most environments. Instead of
using a fixed size for the receive window, TCP negotiates for and adjusts to an even increment of the
maximum segment size. Matching the receive window to even increments of the maximum segment
size increases the percentage of full-sized TCP segments used during bulk data transmission.

Note
Setting this entry to a value greater than 64 KB can only be achieved when connecting to other
systems that support window scaling as described in Internet RFC 1323. For more information
about RFC 1323, see http://go.microsoft.com/fwlink/?LinkId=84406.

GlobalMaxTcpWindowSize
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
 Value: GlobalMaxTcpWindowSize
Data Type: REG_DWORD
Range: 0 to 1073741823
Default value: This value does not exist by default
Recommended 65535
value:
Value exists by No, needs to be added.
default?

The NumTcpTablePartitions value controls the number of TCB table partitions. The TCB table can be
portioned to improve scalability on multi-processor systems by reducing contention on the TCB table.
This value should not be modified without a careful performance study. A suggested maximum value is
(number of CPUs) * 2 (not counting hyper-threaded CPUs).

NumTcpTablePartitions
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: NumTcpTablePartitions
Data Type: REG_DWORD
Range: 1 to 65535
Default value: 4
Recommended Number of physical CPUs or physical CPU cores * 2 (not counting hyper-threaded
value: CPUs)
Value exists by No, needs to be added.
default?

The TcpAckFrequency value specifies the number of ACKs that will be outstanding before the delayed
ACK timer is ignored. The TcpAckFrequency value can only be set after installing Hotfix 815230,
described in Microsoft Knowledge Base article 815230, “Changing the TcpAckFrequency value to 1
does not have any effect” at http://support.microsoft.com/kb/815230.

Caution
Do not change the value of this entry before carefully studying the effect of different values in a
test environment.

TcpAckFrequency
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
 s
Value: TcpAckFrequency
Data Type: REG_DWORD
Range: 0 to 255
Default value: 2
Recommended  5 for 100 MB networks
value:  13 MB for 1 GB networks
Value exists by No, needs to be added.
default?

The SynAttackProtect value specifies whether the SYN flooding attack protection feature of TCP/IP is
enabled. The SYN flooding attack protection feature of TCP detects symptoms of denial-of-service
(DOS) attacks (also known as SYN flooding), and it responds by reducing the time that the server
spends on connection requests that it cannot acknowledge. For more information about the
SynAttackProtect registry entry, see the “Disable Windows Server 2003 Service Pack 1 and Service
Pack 2 denial of service checking” section of Optimizing Operating System Performance.

SynAttackProtect
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: SynAttackProtect
Data Type: REG_DWORD
Range: 0 to 1
Default value: 1 for Windows Server 2003 SP1 and later, 0 otherwise
Recommended 0 (Only set this on systems with Web exposure if other hardware or software is
value: providing denial of service (DOS) attack protection)
Value exists by No, needs to be added.
default?

The MTU value specifies the size of the maximum transmission unit (MTU) that TCP/IP uses for the
network interface. The value of this entry takes precedence over the MTU that the network adapter
detects dynamically. For more information about the MTU value, see “Appendix A: TCP/IP Configuration
Parameters” at http://go.microsoft.com/fwlink/?LinkId=113716.

MTU
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interf
 aces\interfaceGUID
Value: MTU
Data Type: REG_DWORD
Range: 88 to the dynamically determined MTU (in bytes)
Default 4294967295
value:
Recommen Determine the optimal MTU value as described in the Find the Optimal MTU below,
ded value: under “Applying registry settings with the network optimization Windows PowerShell
script”
Value exists No, needs to be added.
by default?

The ForwardBufferMemory value specifies the size of the buffer that IP allocates for storing packet
data in the router packet queue. Because packet queue data buffers are 256 bytes long, the value of
this entry must be a multiple of 256.

ForwardBufferMemory
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: ForwardBufferMemory
Data Type: REG_DWORD
Range: 0 to 4294967295 (bytes, in 256 byte increments
Default value: 74240
Recommended Set to a value 100 * the optimal MTU value as described in the Find the Optimal
value: MTU below, under “Applying registry settings with the network optimization
Windows PowerShell script”
Value exists by No, needs to be added.
default?

The MaxForwardBufferMemory value limits the total amount of memory that IP can allocate to store
packet data in the router packet queue

MaxForwardBufferMemory
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: MaxForwardBufferMemory
 Data Type: REG_DWORD
Range: Dynamically determined MTU to 4294967295 (in bytes)
Default value: 2097152 (bytes)
Recommended Set to a value 100 * the optimal MTU value as described in Find the Optimal
value: MTU below, under “Applying registry settings with the network optimization
Windows PowerShell script”. This value must be greater than or equal to the value
specified for ForwardBufferMemory.
Value exists by No, needs to be added.
default?

The NumForwardPackets value determines the number of IP packet headers that are allocated for the
router packet queue. When all headers are in use, the system attempts to allocate more, up to the
value configured for MaxNumForwardPackets. This value should be at least as large as the
ForwardBufferMemory value divided by the maximum IP data size of the networks that are connected
to the router. It should be no larger than the ForwardBufferMemory value divided by 256 because at
least 256 bytes of forward buffer memory is used for each packet. The optimal number of forward
packets for a given ForwardBufferMemory size depends on the type of traffic that is carried on the
network and is somewhere between these two values. This parameter is ignored and no headers are
allocated if routing is not enabled.

NumForwardPackets
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: NumForwardPackets
Data Type: REG_DWORD
Range: 1 to 4294967295
Default value: 50
Recommended Set to 1/256 of the value specified for ForwardBufferMemory
value:
Value exists by No, needs to be added.
default?

The MaxNumForwardPackets value limits the total number of IP packet headers that can be allocated
for the router packet queue. This value must be greater than or equal to the value of the
NumForwardPackets entry.
MaxNumForwardPackets
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: MaxNumForwardPackets
Data Type: REG_DWORD
Range: 1 to 4294967295
Default value: 4294967295
Recommended Set to 1/256 of the value specified for ForwardBufferMemory
value:
Value exists by No, needs to be added.
default?

The TcpWindowSize value specifies the maximum size of the TCP receive window. The receive
window specifies the number of bytes that a sender can transmit without receiving an acknowledgment.
In general, larger receive windows improve performance over high-latency, high-bandwidth networks.
For greatest efficiency, the receive window should be an even multiple of the TCP Maximum Segment
Size.
The TCP/IP stack of Windows Server 2003 was designed to tune itself in most environments. Instead of
using a fixed size for the receive window, TCP negotiates for and adjusts to an even increment of the
maximum segment size (MSS). For more information about MSS, see http://go.microsoft.com/fwlink/?
LinkId=113755. Matching the receive window to even increments of the MSS increases the percentage
of full-sized TCP segments used during bulk data transmission.

Note
Setting this entry to a value greater than 64 KB can only be achieved when connecting to other
systems that support window scaling as described in Internet RFC 1323. For more information
about RFC 1323, see http://go.microsoft.com/fwlink/?LinkId=84406

TcpWindowSize
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
s
Value: TcpWindowSize
Data Type: REG_DWORD
Range: 0 to 4294967295 ( bytes, in 256-byte increments )
Default value: The smaller of the following values:
 65535
 The value of the GlobalMaxTcpWindowSize registry entry. For more
information, see “Appendix A: TCP/IP Configuration Parameters” at
 http://go.microsoft.com/fwlink/?LinkId=113716
 16384 rounded up to an even multiple of the TCP Maximum Segment Size
(MSS)
Recommended Value closest to 64420 that is a multiple of the MSS value.
value:
Value exists by No, needs to be added.
default?

The EnableDynamicBacklog value is a global switch that enables AFD.SYS functionality to withstand
large numbers of SYN_RCVD connections efficiently. For more information, see "Internet Server
Unavailable Because of Malicious SYN Attacks," at http://support.microsoft.com/kb/142641.

EnableDynamicBacklog
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameter
s
Value: EnableDynamicBacklog
Data Type: REG_DWORD
Range: 0 to 1
Default value: 0
Recommended 1
value:
Value exists by No, needs to be added.
default?

The MinimumDynamicBacklog value spcifies the minimum number of free connections allowed on a
listening endpoint. If the number of free connections drops below this value, a thread is queued to
create additional free connections.

MinimumDynamicBacklog
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameter
s
Value: MinimumDynamicBacklog
Data Type: REG_DWORD
Range: 0 to 4294967295
Default value: This value does not exist by default
Recommended 200
 value:
Value exists by No, needs to be added.
default?

The MaximumDynamicBacklog value controls the maximum number of "quasi-free" connections

allowed on a listening endpoint. "Quasi-free" connections include the number of free connections plus
those connections in a half- connected (SYN_RECEIVED) state. No attempt is made to create
additional free connections if doing so would exceed this value.
To take advantage of the changes to Afd.sys, Windows Sockets applications must specifically request a
backlog greater than the value configured for MinimumDynamicBacklog when they issue a listen()
call. Microsoft applications, such as Internet Information Services (IIS), which has a default backlog of
25, are configurable.

MaximumDynamicBacklog
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameter
s
Value: MaximumDynamicBacklog
Data Type: REG_DWORD
Range: 0 to 4294967295
Default value: This value does not exist by default
Recommended 20000
value:
Value exists by No, needs to be added.
default?

The DynamicBacklogGrowthDelta value controls the number of free connections to create when
additional connections are necessary. Be careful with this value, as a very large value could lead to
explosive free connection allocations.

DynamicBacklogGrowthDelta
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameter
s
Value: DynamicBacklogGrowthDelta
Data Type: REG_DWORD
Range: 0 to 4294967295
Default value: This value does not exist by default
 Recommended 100
value:
Value exists by No, needs to be added.
default?

Applying registry settings with the network

optimization Windows PowerShell script
This topic includes a Windows PowerShell script that can be run on each computer in the BizTalk
Server environment to apply registry settings that will optimize networking performance, by using the
recommended values discussed in this topic. To run this script follow these steps:
1. Find the optimal MTU - Before running the network optimization PowerShell script, the “Maximum
Common MTU” for all computers in the solution must be determined. This means that if 1500 works
as an MTU value on all but one computer, either the value of that less capable computer must be
used everywhere, or the NIC on the less capable computer needs to be replaced with one as
capable as the others. To find the optimal MTU size that can be used on a particular network, do
the following:
a. On each computer that is part of the solution, open a PowerShell window or CMD.exe window
and ping that computer’s default gateway with the following command:
PING –f –l <MTU Size> <interface default gateway address>

Note
If you don’t know the default gateway IP address, run “IPCONFIG” from a command
prompt to display the address.
If this command returns the message “Packet needs to be fragmented but DF set,” then the
specified MTU value is too high and a lower value must be used.
b. Determine the highest MTU value that will work on all computers in the BizTalk Server
environment, this value will be passed as an argument to the network optimization PowerShell
script.
2. Install Windows PowerShell – Windows PowerShell can be downloaded from
http://go.microsoft.com/fwlink/?LinkId=77521. PowerShell must be installed in order to run the
network optimization script.
3. Run the network optimization script
a. Copy the script from the “Optimizing network performance registry settings” section of Windows
PowerShell Scripts into notepad and save as Set-NetworkRegSettings.ps1.
b. Launch PowerShell and change directories to the folder that contains the saved script.
c. Run the script with the following command:
.\Set-NetworkRegSettings.ps1 1400
 Note
In this example an “optimal MTU” size of 1400 is passed as an argument to the script
but the “optimal MTU” value may be different in your environment.

Note
If the script does not run, or opens in Notepad instead of running, ensure the
PowerShell execution policy permits running PowerShell scripts. To determine the
current PowerShell execution policy run the Get-ExecutionPolicy PowerShell
command. To change the current PowerShell execution policy run the Set-
ExecutionPolicy PowerShell command.
The network optimizations PowerShell script generates a log file named “COMPUTERNAME-
NetworkRegSettings.log” in the directory from which the script was run. This log file details which
values were changed and lists the original value as well as the new value. For simplicity sake, and
so that all logs are accessible from the same place, it is recommended that this script is placed in a
networked file share and that the script is run from that file share on all computers in the BizTalk
Server environment.

Optimizing Database Performance

BizTalk Server is an extremely database intensive application that may require the creation of up to 13
databases in SQL Server. Because one of the primary design goals of BizTalk Server is to ensure that
no messages are lost, BizTalk Server persists data to disk with great frequency and furthermore, does
so within the context of an MSDTC transaction. Therefore, database performance is paramount to the
overall performance of any BizTalk Server solution.
This section describes general methods for maximizing SQL Server performance as well as methods
for maximizing database performance that are specific to a BizTalk Server environment. For additional
information on optimizing BizTalk database performance, see the BizTalk Database Optimization
TechNet article at http://go.microsoft.com/fwlink/?LinkId=118001.

In This Section
 Pre-Configuration Database Optimization
 Post-Configuration Database Optimization
 Optimizing Filegroups for the Databases

Pre-Configuration Database Optimization

BizTalk Server is an extremely database-intensive application that may require the creation of up to 13
separate databases in Microsoft SQL Server. Because of the critical role that SQL Server plays in any
BizTalk Server environment, it is of paramount importance that SQL Server is configured/tuned for
optimal performance. If SQL Server is not tuned to perform well, then the databases used by BizTalk
Server will become a bottleneck and the overall performance of the BizTalk Server environment will
suffer. This topic describes several SQL Server performance optimizations that should be followed
before installing BizTalk Server and configuring the BizTalk Server databases.

Considerations for the version and edition of SQL

Server
Various versions and editions of SQL Server provide different features that can impact the performance
of your BizTalk Server environment. For example, under high-load conditions, the number of available
database locks that are available for the 32-bit version of SQL Server may be exceeded, which is
detrimental to the performance of the BizTalk solution. Consider housing your MessageBox database
on a 64-bit version of SQL Server if you are experiencing "out of lock" errors in your test environment.
The number of available locks is significantly higher on the 64-bit version of SQL Server.
Consider the table below when deciding on the database engine features that you will need for your
BizTalk environment. For small-scale solutions, for example when running BizTalk Server 2006 R2
Branch Edition, SQL Server 2000 Desktop Edition (MSDE) may be adequate for housing the BizTalk
Server databases. For large scale, enterprise-level solutions that require clustering support, BizTalk
Server log shipping support, or Analysis Services support, then you will need SQL Server 2005 or SQL
Server 2000 Enterprise Edition to house the SQL Server databases.

Note
Running BizTalk Server databases on SQL Server 2005 typically provides superior
performance to running BizTalk Server databases on SQL Server 2000.

Version and Edition 64-bit support Multi-Instance Clustering support Analysis Services
of SQL Server Support

SQL Server 2005 Yes Yes Yes Yes

Enterprise Edition
SQL Server 2005 Yes Yes Yes (2 node) Yes
Standard Edition
SQL Server 2005 No Yes No No
Workgroup Edition
SQL Server 2000 No Yes Yes Yes
Enterprise Edition
SQL Server 2000 No Yes No Yes
Standard Edition
SQL Server 2000 No Yes No No
Desktop Edition
(MSDE)
For a complete list of the features supported by the editions of SQL Server 2005, see "Features
Supported by the Editions of SQL Server 2005" in the SQL Server 2005 documentation at
http://go.microsoft.com/fwlink/?LinkId=72045. For a complete list of the features supported by the
editions of SQL Server 2000, see "Features Supported by the Editions of SQL Server 2000" in the SQL
Server 2000 documentation at http://go.microsoft.com/fwlink/?LinkId=104156.

Database planning considerations

We recommend that you host your SQL databases on fast storage (for example, fast SAN disks or fast
SCSI disks). We recommend RAID 10 (1+0) instead of RAID 5 since raid 5 is slower at writing. Newer
SAN disks have very large memory caches, so in these cases the raid selection is not as important. To
increase performance, databases and their log files can reside on different physical disks.

If using SQL Server 2000, install the cumulative

hotfix package for SQL Server 2000 SP4 build 2187
There is an issue with SQL Server 2000 Service Pack 4 whereby not all memory is available when AWE
is enabled on a computer running the 32-bit version of SQL Server 2000 SP4. For more information
about this issue see Microsoft Knowledge Base article 899761, “FIX: Not all memory is available when
AWE is enabled on a computer that is running a 32-bit version of SQL Server 2000 SP4” at
http://support.microsoft.com/kb/899761. To resolve this issue. download and install the cumulative hotfix
package for SQL Server 2000 SP4 build 2187 that is documented in Microsoft Knowledge Base Article
916287, “A cumulative hotfix package is available for SQL Server 2000 Service Pack 4 build 2187” at
http://support.microsoft.com/kb/916287.

If using SQL Server 2005, install the latest service

pack and cumulative update
We recommend installing the latest service packs and the latest cumulative updates for SQL Server
2005 as well as the latest .NET Framework service packs.

Install SQL Service Packs on both BizTalk Server and

SQL Server
When installing service packs for SQL Server, also install the service pack on the BizTalk computer.
BizTalk Server uses SQL Client components that are updated by the SQL Server service packs.
If using 32-bit SQL Server, configure SQL Server to
use AWE
On an x86 computer, SQL Server should be configured to use more than 2 GB of physical memory.
SQL Server Enterprise Edition introduced support for the use of Microsoft Windows Address Windowing
Extensions (AWE) to address up to 32 GB of memory. With AWE, SQL Server can reserve memory that
is not in use for other applications and the operating system. Each instance that uses this memory,
however, must statically allocate the memory it needs. SQL Server can only use this AWE allocated
memory for the data cache and not for executables, drivers, DLLs, and so forth. For more information,
see Microsoft Knowledge Base article 274750, "How to configure SQL Server to use more than 2 GB of
physical memory" at http://support.microsoft.com/kb/274750.

Set Min and Max Server Memory

The computers running SQL Server that host the BizTalk Server databases should be dedicated to
running SQL Server. When the computers running SQL Server that host the BizTalk Server databases
are dedicated to running SQL Server, we recommend that the 'min server memory' and 'max server
memory' options on each SQL Server instance are set to specify the fixed amount of memory to
allocate to SQL Server. In this case, you should set the “min server memory” and “max server memory”
to the same value (equal to the maximum amount of physical memory that SQL Server will use). This
will reduce overhead that would otherwise be used by SQL Server dynamically managing these values.
Run the following T-SQL commands on each computer running SQL Server to specify the fixed amount
of memory to allocate to SQL Server:
sp_configure ‘Max Server memory (MB)’,(max size in MB)

sp_configure ‘Min Server memory (MB)’,(min size in MB)

Before you set the amount of memory for SQL Server, determine the appropriate memory setting by
subtracting the memory required for Windows Server from the total physical memory. This is the
maximum amount of memory you can assign to SQL Server.

Note
If the computer(s) running SQL Server that host the BizTalk Server databases also host the
Enterprise Single Sign-On Master Secret Server then you may need to adjust this value to
ensure that there is sufficient memory available to run the Enterprise Single Sign-On Service. It
is not an uncommon practice to run a clustered instance of the Enterprise Single Sign-On
service on a SQL Server cluster to provide high availability for the Master Secret Server. For
more information about clustering the Enterprise Single Sign-On Master Secret Server, see the
topic “How to Cluster the Master Secret Server” in the BizTalk Server 2006 R2 documentation
at http://go.microsoft.com/fwlink/?LinkID=106874.
Split the tempdb database into multiple data files of
equal size on each SQL Server instance used by
BizTalk Server
Ensuring that the data files used for the tempdb are of equal size is critical because the proportional fill
algorithm used by SQL Server is based on the size of the data files. If data files are created with
unequal sizes, the proportional fill algorithm will use the largest file more for GAM allocations rather
than spreading the allocations between all the files, thereby defeating the purpose of creating multiple
data files. The number of data files for the tempdb database should be configured to be at least equal to
the number of processors assigned for SQL Server.

Enable Trace Flag T1118 as a startup parameter for

all instances of SQL Server
Implementing Trace Flag –T1118 helps reduce contention across the SQL Server instances by
removing almost all single page allocations. For more information, see Microsoft Knowledge Base
article 328551, "PRB: Concurrency enhancements for the tempdb database" at
http://support.microsoft.com/kb/328551.

Do not change default SQL Server settings for max

degree of parallelism, SQL Server statistics, or
database index rebuilds and defragmentation
If a SQL Server instance will house BizTalk Server databases, then there are certain SQL Server
settings should not be changed. Specifically, the SQL Server max degree of parallelism, the SQL Server
statistics on the MessageBox database, and the settings for the database index rebuilds and
defragmentation should not be modified. For more information, see the topic “SQL Server Settings That
Should Not Be Changed” in the BizTalk Server Operations Guide at http://go.microsoft.com/fwlink/?
LinkId=114358.

Post-Configuration Database Optimization

In addition to following the recommendations in Pre-Configuration Database Optimization, several steps
should be followed to optimize BizTalk Server database performance on SQL Server after BizTalk
Server has been installed and the BizTalk Server databases have been configured. This topic provides
a list of these optimizations.
Pre-allocate space for BizTalk Server databases and
define auto-growth settings for BizTalk Server
databases to a fixed value instead of a percentage
value
 SQL Server database auto-growth is a blocking operation which hinders BizTalk Server database
performance. Therefore it is important to allocate sufficient space for the BizTalk Server databases
in advance to minimize the occurrence of database auto-growth.
 Database auto-growth should be set to a fixed number of megabytes instead of to a percentage
(specify file growth In Megabytes). This should be done so if auto-growth occurs it does so in a
measured fashion which reduces the likelihood of excessive database growth. The growth
increment should generally be no larger than 100 MB (for large files), 10 MB (for medium-sized
files), or 1 MB (for small files).
 When SQL Server increases the size of a file, it must first initialize the new space before it can be
used. This is a blocking operation that involves filling the new space with empty pages. SQL Server
2005 running on Windows Server 2003 or later supports “instant file initialization.” This can greatly
reduce the performance impact of a file growth operation. For more information, see "Database File
Initialization" in the SQL Server 2005 documentation at http://go.microsoft.com/fwlink/?
LinkId=101579. This topic provides steps for enabling instant file initialization.

Verify the BizTalk Server SQL Agent Jobs are running

BizTalk Server includes several SQL Server Agent jobs that perform important functions to keep your
servers operational and healthy. You should monitor the health of these jobs and ensure they are
running without errors. One of the most common causes of performance problems in BizTalk Server is
the BizTalk Server SQL Agent Jobs are not running, which in turn can cause the MessageBox and
Tracking databases to grow unchecked. Follow these steps to ensure the BizTalk Server SQL Agent
Jobs are running without problems:
 Verify the SQL Server Agent service is running.
 Verify the SQL Server Agent jobs installed by BizTalk Server are enabled and running
successfully.
The BizTalk Server SQL Server Agent jobs are crucial: if they are not running, system performance
will degrade over time.
 Verify the BizTalk Server SQL Server Agent jobs are completing in a timely manner.
Set up Microsoft Operations Manager (MOM) 2005 or Microsoft System Center Operations
Manager 2007 to monitor the jobs.
You should be aware of schedules that are particular to certain jobs:
 The MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job runs continuously by
default. Monitoring software should take this schedule into account and not produce warnings.
  The MessageBox_Message_Cleanup_BizTalkMsgBoxDb job is not enabled or scheduled, but it
is started by the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job every 10
seconds. Therefore, this job should not be enabled, scheduled, or manually started.
 Verify the Startup type of the SQL Server Agent service is configured correctly.
Verify the SQL Server Agent service is configured with a Startup type of Automatic unless the
SQL Server Agent service is configured as a cluster resource on a Windows Server cluster. If the
SQL Server Agent service is configured as a cluster resource, then you should configure the
Startup type as Manual because the service will be managed by the Cluster service.

Configure Purging and Archiving of Tracking Data

Follow these steps to ensure that purging and archiving of tracking data is configured correctly:
 Ensure the SQL Agent job “DTA Purge and Archive” is properly configured, enabled, and
successfully completing. For more information, see "How to Configure the DTA Purge and Archive
Job" in the BizTalk Server R2 documentation at http://go.microsoft.com/fwlink/?LinkId=104908.
 Ensure the job is able to purge the tracking data as fast as the incoming tracking data is generated.
For more information, see "Measuring Maximum Sustainable Tracking Throughput" in the BizTalk
Server 2006 R2 documentation at http://go.microsoft.com/fwlink/?LinkId=104909.
 Review the soft purge and hard purge parameters to ensure you are keeping data for the optimal
length of time. For more information, see "Archiving and Purging the BizTalk Tracking Database" in
the BizTalk Server 2006 R2 documentation at http://go.microsoft.com/fwlink/?LinkId=101585.
 If you only need to purge the old data and do not need to archive it first, change the SQL Agent job
to call the stored procedure “dtasp_PurgeTrackingDatabase.” For more information, see "How to
Purge Data from the BizTalk Tracking Database" in the BizTalk Server 2006 R2 documentation at
http://go.microsoft.com/fwlink/?LinkId=101584.

Monitor and reduce DTC log file disk I/O contention

The Distributed Transaction Coordinator (DTC) log file can become a disk I/O bottleneck in transaction-
intensive environments. This is especially true when using adapters that support transactions, such as
SQL Server, MSMQ, or MQSeries, or in a multi-MessageBox environment. Transactional adapters use
DTC transactions, and multi-MessageBox environments make extensive use of DTC transactions. To
ensure the DTC log file does not become a disk I/O bottleneck, you should monitor the disk I/O usage
for the disk where the DTC log file resides on the SQL Server database server(s). If disk I/O usage for
the disk where the DTC log file resides becomes excessive then consider moving the DTC log file to a
faster disk. In an environment where SQL Server is clustered, this is not as much of a concern because
the log file will already be on a shared drive, which will likely be a fast SAN drive with multiple spindles.
You should nevertheless still monitor the disk I/O usage because it can become a bottleneck in non-
clustered environments or when the DTC log file is on a shared disk with other disk-intensive files.
Separate the MessageBox and Tracking Databases
Because the BizTalk MessageBox and BizTalk Tracking databases are the most active, we recommend
you place the data files and transaction log files for each of these on dedicated drives to reduce the
likelihood of problems with disk I/O contention. For example, you would need four drives for the
MessageBox and BizTalk Tracking database files; one drive for each of the following:
 MessageBox data file(s)
 MessageBox transaction log file(s)
 BizTalk Tracking (DTA) data file(s)
 BizTalk Tracking (DTA) transaction log file(s)
Separating the BizTalk MessageBox and BizTalk Tracking databases and separating the database files
and transaction log files on different physical disks are considered best practices for reducing disk I/O
contention. Try to spread the disk I/O across as many physical spindles as possible. You can also
reduce disk I/O contention by placing the BizTalk Tracking database on a dedicated SQL Server;
however, you should still follow the practices above with regards to separating data files and transaction
log files.

Optimize filegroups for the BizTalk Server databases

Follow the steps in Optimizing Filegroups for the Databases and the "BizTalk Server Database
Optimization" whitepaper at http://go.microsoft.com/fwlink/?LinkId=101578 to create additional
filegroups and files for the BizTalk Server databases. This will greatly increase the performance of the
BizTalk Server databases from a single disk configuration.

Install the BizTalk Server hotfix described in

Microsoft Knowledge Base article 944234, “FIX: The
CPU usage remains high for a long time on a
computer that is running SQL Server and BizTalk
Server 2006”
This fix updates known issues in the Bts_PurgeSubscriptions and Int_ToggleSubscriptions stored
procedures. For more information about this hotfix, see Microsoft Knowledge Base article 944234, “FIX:
The CPU usage remains high for a long time on a computer that is running SQL Server and BizTalk
Server 2006” at http://support.microsoft.com/kb/944234.

Optimizing Filegroups for the Databases

File input/output (I/O) contention is frequently a limiting factor, or bottleneck, in a production BizTalk
Server environment. BizTalk Server is a very database intensive application and in turn, the SQL Server
database used by BizTalk Server is very file I/O intensive. This topic describes how to make optimal use
of the files and filegroups feature of SQL Server to minimize the occurrence of file I/O contention and
improve the overall performance of a BizTalk Server solution.

Overview
Every BizTalk Server solution will eventually encounter file I/O contention as throughput is increased.
The I/O subsystem, or storage engine, is a key component of any relational database. A successful
database implementation typically requires careful planning at the early stages of a project. This
planning should include consideration of the following issues:
 What type of disk hardware to use, such as RAID (redundant array of independent disks) devices.
For more information about using a RAID hardware solution, see “About Hardware-based solutions”
in the SQL Server 2005 Books online at http://go.microsoft.com/fwlink/?LinkID=113944.
 How to apportion data on the disks using files and filegroups. For more information about using files
and filegroups in SQL Server 2005, see “Using Files and Filegroups” in the SQL Server 2005 Books
online at http://go.microsoft.com/fwlink/?LinkID=69369 and “Understanding Files and Filegroups” in
the SQL Server Books online at http://go.microsoft.com/fwlink/?LinkID=96447.
 Implementing the optimal index design for improving performance when accessing data. For more
information about designing indexes, see “Designing Indexes” in the SQL Server 2005 books online
at http://go.microsoft.com/fwlink/?LinkID=96457.
 How to set SQL Server configuration parameters for optimal performance. For more information
about setting optimal configuration parameters for SQL Server, see “Optimizing Server
Performance” in the SQL Server Books online at http://go.microsoft.com/fwlink/?LinkID=71418.
One of the primary design goals of BizTalk Server is to ensure that a message is never lost. In order to
mitigate the possibility of message loss, messages are frequently written to the MessageBox database
as the message is processed. When messages are processed by an Orchestration, the message is
written to the MessageBox database at every persistence point in the orchestration. These persistence
points cause the MessageBox to write the message and related state to physical disk. At higher
throughputs, this persistence can result in considerable disk contention and can potentially become a
bottleneck.
Making optimal use of the files and filegroups feature in SQL Server has been shown to effectively
address File IO bottlenecks and improve overall performance in BizTalk Server solutions. This
optimization should only be done by an experienced SQL Server database administrator and only after
all BizTalk Server databases have been properly backed up. This optimization should be performed on
all SQL Server computers in the BizTalk Server environment.
SQL Server files and filegroups can be utilized to improve database performance because this
functionality allows a database be created across multiple disks, multiple disk controllers, or RAID
(redundant array of independent disks) systems. For example, if your computer has four disks, you can
create a database that is made up of three data files and one log file, with one file on each disk. As data
is accessed, four read/write heads can concurrently access the data in parallel. This speeds up
database operations significantly. For more information about implementing hardware solutions for SQL
Server disks, see “Database Performance” in the SQL Server Books online at
http://go.microsoft.com/fwlink/?LinkID=71419.
Additionally, files and filegroups enable data placement, because tables can be created in specific
filegroups. This improves performance, because all file I/O for a given table can be directed at a specific
disk. For example, a heavily used table can be placed on a file in a filegroup, located on one disk, and
the other less heavily accessed tables in the database can be located on different files in another
filegroup, located on a second disk.
File IO bottlenecks are discussed in considerable detail in the topic Bottlenecks in the Database Tier.
The most common indicator that File I/O (Disk I/O) is a bottleneck is the value of the “Physical
Disk:Average Disk Queue Length” counter. When the value of the “Physical Disk:Average Disk Queue
Length” counter is greater than about 3 for any given disk on any of the SQL Servers, then file I/O is
likely a bottleneck.
If applying file or filegroup optimization doesn't resolve a file I/O bottleneck problem, then it may be
necessary to increase the throughput of the disk subsystem by adding additional physical or SAN
drives.
This topic describes how to manually apply file and filegroup optimizations but these optimizations can
also be scripted. A sample SQL script is provided at the end of this topic. It is important to note that this
script would need to be modified to accommodate the file, filegroup, and disk configuration used by the
SQL Server database(s) for any given BizTalk Server solution.

Note
This topic describes how to create multiple files and filegroups for the BizTalk MessageBox
database. For an exhaustive list of recommended files and filegroups for all of the BizTalk
Server databases, see Appendix B of the excellent "BizTalk Server Database Optimization"
whitepaper available at http://go.microsoft.com/fwlink/?LinkID=101578.

Databases created with a default BizTalk Server

configuration
Depending on which features are enabled when configuring BizTalk Server, up to 13 different
databases may be created in SQL Server and all of these databases are created in the default file
group. The default filegroup for SQL Server is the PRIMARY filegroup unless the default filegroup is
changed by using the ALTER DATABASE command. The table below lists the databases that are
created in SQL Server if all features are enabled when configuring BizTalk Server.

BizTalk Server Databases

Database Default Database Name Description
Configuration database BizTalkMgmtDb The central meta-information
store for all instances of BizTalk
Server in the BizTalk Server
group.
BizTalk MessageBox database BizTalkMsgBoxDb Stores subscriptions predicates.
It is a host platform, and keeps
queues and state tables for
each BizTalk Server host. The
MessageBox database also
stores the messages and
message properties.
BizTalk Tracking database BizTalkDTADb Stores business and health
monitoring data tracked by the
BizTalk Server tracking engine.
BAM Analysis database BAMAnalysis SQL Server Analysis Services
database that keeps the
aggregated historical data for
Business Activities.
BAM Star Schema database BAMStarSchema Transforms the data collected
from Business Activity
Monitoring for OLAP
Processing. This database is
required when using the BAM
Analysis database.
BAM Primary Import database BAMPrimaryImport Stores the events from
Business Activities and then
queries for the progress and
data after activity instances.
This database also performs
real-time aggregations.
BAM Archive database BAMArchive Stores subscription predicates.
The BAM Archive database
minimizes the accumulation of
Business Activity data in the
BAM Primary Import database.
SSO database SSODB Securely stores the
configuration information for
receive locations. Stores
information for SSO affiliate
applications, as well as the
encrypted user credentials to all
the affiliate applications.
Rule Engine database BizTalkRuleEngineDb Repository for:
 Policies, which are sets of
related rules.
 Vocabularies, which are
collections of user-friendly,
domain-specific names for
data references in rules.
 Base EDI database BizTalkEDIDb Stores EDI document tracking
and processing data.
Human Workflow Services BizTalkHwsDb Stores administrative
Administration database information required by the
BizTalk Human Workflow
Services.
Trading Partner Management TPM Stores trading partner data for
database Business Activity Services
(BAS).
Tracking Analysis Server BizTalkAnalysisDb Stores both business and health
Administration database monitoring OLAP cubes.

Separation of data files and log files

As noted above, a default BizTalk Server configuration places the MessageBox Database into a single
file in the default filegroup. By default, the data and transaction logs for the MessageBox database are
placed on the same drive and path. This is done to accommodate systems with a single disk. A single
file/filegroup/disk configuration is not optimal in a production environment. For optimal performance,
the data files and log files should be placed on separate disks.

Note
Log files are never part of a filegroup. Log space is managed separately from data space.

The 80/20 rule of distributing BizTalk Server

databases
The main source of contention in most BizTalk Server solutions, either because of disk I/O contention or
database contention, is the BizTalk Server MessageBox database. This is true in both single and multi-
MessageBox scenarios. It is reasonable to assume that as much as 80% of the value of distributing
BizTalk databases will be derived from optimizing the MessageBox data files and log file. The sample
scenario detailed below is focused on optimizing the data files for a MessageBox database. These
steps can then be followed for other databases as needed, for example, if the solution requires
extensive tracking, then the Tracking database can also be optimized.

Manually adding files to the MessageBox database,

step-by-step
This section describes the steps that can be followed to manually add files to the MessageBox
database. In this example three filegroups are added and then a file is added to each filegroup to
distribute the files for the MessageBox across multiple disks. In this example, the steps are performed
on SQL Server 2005.
1. Click Start, point to Programs, point to Microsoft SQL Server 2005, and then click SQL Server
Management Studio to display the Connect to Server dialog box.

2. Enter the name of the SQL Server instance that houses the BizTalk Server MessageBox databases
in the Server name edit box of the Connect to Server dialog box, and click the Connect button to
display the SQL Server Management Studio dialog box. In the Object Explorer pane of SQL
Server Management Studio, expand Databases to view the databases for this instance of SQL
Server.
3. Right-click the database for which to add the files, and then click Properties to display the
Database Properties dialog box for the database.
4. In the Database Properties dialog box, select the Filegroups page. Click the Add button to create
additional filegroups for the BizTalkMsgBoxDb databases. In the example below, three additional
filegroups are added.
5. In the Database Properties dialog box, select the Files page.
Click the Add button to create additional files to add to the filegroups, and then click OK. The
MessageBox database is now distributed across multiple disks, which will provide a significant
performance advantage over a single disk configuration.
In the example below, a file is created for each of the filegroups that were created earlier and each
file is placed on a separate disk.
Sample SQL script for adding filegroups and files to
the BizTalk MessageBox database
The sample SQL script below performs the same tasks that were completed manually in the previous
section. This sample script assumes the existence of distinct logical drives G through J. The script
creates filegroups and files for each filegroup and places the log files on the J drive.

Note
Because SQL Server writes to its log files sequentially, there is no performance advantage
realized by creating multiple log files for a SQL Server database.
-- Filegroup changes are made using the master database

USE [master]

GO

-- Script-wide declarations

DECLARE @CommandBuffer nvarchar(2048)

DECLARE @FG1_Path nvarchar(1024)

DECLARE @FG2_Path nvarchar(1024)

DECLARE @FG3_Path nvarchar(1024)

DECLARE @Log_Path nvarchar(1024)

-- Set the default path for all filegroups

SET @FG1_Path = N'G:\BizTalkMsgBoxDATA\'

SET @FG2_Path = N'H:\BizTalkMsgBoxDATA\'

SET @FG3_Path = N'I:\BizTalkMsgBoxDATA\'

SET @Log_Path = N'J:\BizTalkMsgBoxLog\'

ALTER DATABASE [BizTalkMsgBoxDb] ADD FILEGROUP [BTS_MsgBox_FG1]

SET @CommandBuffer = N'ALTER DATABASE [BizTalkMsgBoxDb] ADD FILE ( NAME =

N''BizTalkMsgBoxDb_FG1'', FILENAME = N''' + @FG1_Path +

N'BizTalkMsgBoxDb_FG1.ndf'' , SIZE = 102400KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10240KB ) TO

FILEGROUP [BTS_MsgBox_FG1]'

EXECUTE (@CommandBuffer)

ALTER DATABASE [BizTalkMsgBoxDb] ADD FILEGROUP [BTS_MsgBox_FG2]

SET @CommandBuffer = N'ALTER DATABASE [BizTalkMsgBoxDb] ADD FILE ( NAME =

N''BizTalkMsgBoxDb_FG1'', FILENAME = N''' + @FG2_Path +

N'BizTalkMsgBoxDb_FG2.ndf'' , SIZE = 102400KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10240KB ) TO

FILEGROUP [BTS_MsgBox_FG2]'

EXECUTE (@CommandBuffer)

ALTER DATABASE [BizTalkMsgBoxDb] ADD FILEGROUP [BTS_MsgBox_FG3]

SET @CommandBuffer = N'ALTER DATABASE [BizTalkMsgBoxDb] ADD FILE ( NAME =

N''BizTalkMsgBoxDb_FG1'', FILENAME = N''' + @FG3_Path +

N'BizTalkMsgBoxDb_FG3.ndf'' , SIZE = 102400KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10240KB ) TO

FILEGROUP [BTS_MsgBox_FG3]'

EXECUTE (@CommandBuffer)

ALTER DATABASE [BizTalkMsgBoxDb] MODIFY FILE ( NAME = N'BizTalkMsgBoxDb_log', SIZE = 10240KB ,

MAXSIZE = UNLIMITED, FILEGROWTH = 10240KB )
GO -- Completes the previous batch, as necessary

The sample SQL script below could be used to set a particular filegroup as the default filegroup:
USE [BizTalkMsgBoxDb]

GO

declare @isdefault bit

SELECT @isdefault=convert(bit, (status & 0x10)) FROM sysfilegroups WHERE

groupname=N'BTS_MsgBox_FG1'

if(@isdefault=0)

ALTER DATABASE [BizTalkMsgBoxDb] MODIFY FILEGROUP [BTS_MsgBox_FG1] DEFAULT

GO

The advantage to scripting is that scripts can perform multiple tasks quickly, can be reproduced
precisely, and reduce the possibility of human error. The disadvantage of scripting is that the execution
of an incorrectly written script can potentially cause serious problems that could require the BizTalk
Server databases to be re-configured from scratch. Therefore, it is of utmost importance that SQL
scripts such as the sample script listed in this topic are thoroughly tested before being executed in a
production environment.

Optimizing BizTalk Server Performance

This topic provides recommendations for optimizing performance of the BizTalk Server computers used
in a production BizTalk Server environment. The optimizations listed in this topic are applied after
BizTalk Server has been installed and configured.

General guidelines for improving BizTalk Server

performance
The following recommendations can be used to increase BizTalk Server performance:

Create multiple BizTalk Server hosts and separate host instances by

functionality
Separate hosts should be created for sending, receiving, processing, and tracking functionality.
Creating multiple BizTalk hosts provides flexibility when configuring the workload in your BizTalk group
and is the primary means of distributing processing across the BizTalk Servers in a BizTalk group.
Multiple hosts also allow 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 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
because 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.

Note
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).
For more information about modifying BizTalk Server Host properties, see "How to Modify Host
Properties" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=101588.

Configure 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. Because tracking is a resource intensive operation, a separate host should be
created that is dedicated to tracking, thereby minimizing the impact that tracking has on hosts dedicated
to message processing.
Using a dedicated tracking host also allows you to stop other BizTalk hosts without interfering with
BizTalk Server tracking. The movement of tracking data out of the MessageBox database is critical for a
healthy BizTalk Server system. If the BizTalk Host responsible for moving tracking data in the BizTalk
group is stopped, the Tracking Data Decode service will not run. The impact of this is as follows:
 HAT tracking data will not be moved from the MessageBox database to the BizTalk Tracking
database.
 BAM tracking data will not be moved from the MessageBox database to the BAM Primary Import
database.
 Because data is not moved, it cannot be deleted from the MessageBox database.
 When the Tracking Data Decode service is stopped, tracking interceptors will still fire and write
tracking data to the MessageBox database. If the data is not moved, this will cause the
 MessageBox database to become bloated, which will impact performance over time. Even if custom
properties are not tracked or BAM profiles are not set up, by default some data is tracked (such as
pipeline receive / send events and orchestration events). If you do not want to run the Tracking
Data Decode service, turn off all tracking so that no interceptors save data to the database. To
disable global tracking, see "How to Turn Off Global Tracking" in BizTalk Server 2006 R2 Help at
http://go.microsoft.com/fwlink/?LinkId=101589. Use the BizTalk Server Administration console to
selectively disable tracking events.
The tracking host should be run on at least two computers running BizTalk Server (for redundancy in
case one fails). For optimal performance, you should have at least one tracking host instance per
MessageBox database. The actual number of tracking host instances should be (N + 1), where N = the
number of MessageBox databases. The "+ 1" is for redundancy, in case one of the computers hosting
tracking fails.
A tracking host instance moves tracking data for specific MessageBox databases, but there will never
be more than one tracking host instance moving data for a specific MessageBox database. For
example, if you have three MessageBox databases, and only two tracking host instances, then one of
the host instances needs to move data for two of the MessageBox databases. Adding a third tracking
host instance distributes the tracking host work to another computer running BizTalk Server. In this
scenario, adding a fourth tracking host instance would not distribute any more tracking host work, but
would provide an extra tracking host instance for fault tolerance.
For more information about the BAM Event Bus service, see the following topics in BizTalk Server 2006
R2 Help:
 "Managing the BAM Event Bus Service" at http://go.microsoft.com/fwlink/?LinkId=101590.
 "Creating Instances of the BAM Event Bus Service" at http://go.microsoft.com/fwlink/?
LinkId=101591.

Increase the number of SOAP and HTTP adapter concurrent

connections
By default, the SOAP and HTTP adapters (and .NET, in general) open only two concurrent HTTP
connections from each BizTalk Server to any specific destination server. For example, if you have a
SOAP send port sending messages to http://www.contoso.com/SomeWebService.asmx, then by default
each BizTalk Server will open only two concurrent HTTP connections to www.contoso.com, no matter
how many messages need to be sent.
This setting conforms to the IETF RFC for the HTTP 1.1 specification, and although it is suitable for
user scenarios, it is not optimized for high throughput. The setting effectively throttles outbound SOAP
and HTTP calls to each server to two concurrent sends from each BizTalk Server.
To increase the number of concurrent connections, you can modify the entry in the BizTalk Server
configuration file, BTSNTSvc.exe.config (or BTSNTSvc64.exe.config for 64-bit hosts), on each BizTalk
Server. You can increase this for the specific servers being called. For information about modifying this
entry in the BTSNTSvc.exe.config or BTSNTSvc64.exe.config file, see "SOAP Adapter Configuration
and Tuning Parameters" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?
LinkId=101592.
The following is an example of the configuration for the maximum connections property:
<configuration>

<system.net>

<connectionManagement>

<add address="www.contoso.com" maxconnection="20" />

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

</connectionManagement>

</system.net>

</configuration>

Note
Do not increase the value for the maxconnection parameter to such a large value that the Web
server being called is overwhelmed with HTTP connections. Perform stress testing by sending
requests to each destination Web server to determine a value for maxconnection that will
provide good performance for SOAP and HTTP sends without overwhelming the target Web
servers.
For information about tuning IIS and ASP.NET settings for Web services, see the "ASP.NET settings
that can impact HTTP or SOAP Adapter performance" section of "Configuration Parameters that Affect
Adapter Performance" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkID=79435.

Manually define worker and I/O thread values for Web applications
that host orchestrations published as a Web service
When the autoConfig value in the machine.config file of an ASP.NET 2.0 application is set to true,
ASP.NET 2.0 manages the number of worker threads and I/O threads that are allocated to any
associated IIS worker processes:
<processModel autoConfig="true" />

The number of worker and I/O threads for an ASP.NET Web application that hosts an orchestration
published as a Web service should be modified under the following conditions:
 CPU utilization is not a bottleneck on the hosting Web server.
 The value of the ASP.NET Apps v2.0.50727 \ Request Wait Time or ASP.NET Apps
v2.0.50727\Request Execution Time performance counters is unusually high.
 The following error is generated in the Application log of the computer that hosts the Web
application:
Event Type: Warning
 Event Source: W3SVC Event Category: None

Event ID: 1013

Date: 6/4/2008

Time: 1:03:47 PM

User: N/A

Computer: <ComputerName>

Description: A process serving application pool 'DefaultAppPool' exceeded time limits

during shut down. The process id was '<xxxx>'.

To manually modify the number of worker and I/O threads for an ASP.NET Web application, open the
associated machine.config file, and then enter new values for the maxWorkerThreads and
maxIoThreads parameters:
<!-- <processModel autoConfig="true" /> -->

    <processModel maxWorkerThreads="200" maxIoThreads="200" />

Note
These values are for guidance only; ensure you test changes to these parameters.
For more information about tuning parameters in the machine.config file for an ASP.NET 2.0 Web
application, see the Microsoft Knowledge Base article 821268 “Contention, poor performance, and
deadlocks when you make Web service requests from ASP.NET applications” at
http://support.microsoft.com/kb/821268.

Define CLR hosting thread values for BizTalk host instances

Because a Windows thread is the most basic executable unit available to a Windows process, it is
important to allocate enough threads to the .NET thread pool associated with an instance of a BizTalk
host to prevent thread starvation. When thread starvation occurs, there are not enough threads
available to perform the requested work that negatively impacts performance. At the same time, care
should be taken to prevent allocating more threads to the.NET thread pool associated with a host than
is necessary. The allocation of too many threads to the .NET thread pool associated with a host may
increase context switching. Context switching occurs when the Windows kernel switches from running
one thread to a different thread, which incurs a performance cost. Excessive thread allocation can
cause excessive context switching, which will negatively impact overall performance.
Modify the number of Windows threads available in the .NET thread pool associated with an instance of
a BizTalk host by creating the appropriate CLR Hosting values in the registry of the BizTalk Server.

Warning
Incorrect use of Registry Editor may cause problems requiring you to reinstall your operating
system. Use Registry Editor at your own risk. For more information about how to back up,
 restore, and modify the registry, see the Microsoft Knowledge Base article "Description of the
Microsoft Windows registry" at http://go.microsoft.com/fwlink/?LinkId=62729.

Note
Worker threads are used to handle queued work items and I/O threads are dedicated callback
threads associated with an I/O completion port to handle a completed asynchronous I/O
request.
To modify the number of threads available in the .NET thread pool associated with each instance of a
BizTalk host, follow these steps:
1. Stop the BizTalk host instance.
2. Click Start, click Run, type regedit.exe, and then click OK to start Registry Editor.
Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname] where
hostname is the name of the host associated with the host instance.

Note
If you have upgraded your BizTalk Server 2006 installation from BizTalk Server 2004, this
registry key may be represented as
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvcguid] where
guid is a GUID unique to each instance of a BizTalk Server host.
3. Locate the CLR Hosting key. If this key does not exist, then create the key by following these
steps:
a. On the Edit menu, click New, and then click Key.
b. Type CLR Hosting, and then press ENTER.
4. Under the CLR Hosting key, create the following DWORD entries with the indicated values.
 DWORD entry Default value Recommended value

MaxIOThreads 20 100
MaxWorkerThreads 25 100
Important
Increasing this value
beyond 100 can have an
adverse effect on the
performance of the SQL
Server computer hosting
the BizTalk Server
MessageBox database.
When this problem
occurs, SQL Server may
encounter a deadlock
condition. It is
recommended this
parameter is not
increased beyond a value
of 100.
MinIOThreads 1 25
MinWorkerThreads 1 25

Note
These recommended values will be sufficient for most scenarios but may need to be
increased depending on how many adapter handlers or orchestrations are running in each
host instance.

Note
These values are implicitly multiplied by the number of processors on the server. For
example, setting the MaxWorkerThreads entry to a value of 100 would effectively set a
value of 400 on a 4 CPU server.
5. Close Registry Editor.
6. Restart the BizTalk host instance.

Disable tracking for orchestrations, send ports, receive ports, and

pipelines when tracking is not required
Tracking incurs performance overhead within BizTalk Server as data has to be written to the
MessageBox database and then asynchronously moved to the BizTalk Tracking database. If tracking is
not a business requirement, then disable tracking to reduce overhead and increase performance. For
more information about configuring tracking, see “Configuring Tracking Using the BizTalk Server
Administration Console” in the BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?
LinkID=106742.

Decrease the purging period for the DTA Purge and Archive job from
7 days to 2 days in high throughput scenarios
By default, the purging interval for tracking data in BizTalk Server is set to 7 days. In a high throughput
scenario, this can result in an excessive build up of data in the Tracking database, which will eventually
impact the performance of the MessageBox and in turn negatively impact message processing
throughput.

In high throughput scenarios, reduce the hard and soft purging interval from the default of 7 days to 2
days. For more information about configuring the purging interval, see “How to Configure the DTA
Purge and Archive Job” in the BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?
LinkID=104908.

Install the latest service packs

The latest service packs for both BizTalk Server and the .NET Framework should be installed, as these
contain fixes that can correct performance issues you may encounter.

Do not cluster BizTalk hosts unless absolutely neccessary

While BizTalk Server 2006 allows you to configure a BizTalk host as a cluster resource, you should only
consider doing this if you need to provide high availability to a resource that cannot be hosted across
multiple BizTalk computers. As an example, ports using the FTP adapter should only reside on one host
instance, as the FTP protocol does not provide file locking, however, this introduces a single point of
failure which would benefit from clustering. Hosts that contain adapters, such as file, SQL, HTTP or
processing only hosts, can be internally load balanced across machines and do not benefit from
clustering.

Low-latency scenario optimizations

By default, BizTalk Server is optimized for throughput rather than low-latency. The following
optimizations can be applied to BizTalk Server in scenarios where reduced latency is required.

Note
These optimizations will improve latency but may do so at some cost to overall throughput.

Increase the BizTalk Server host internal message queue size

Each BizTalk host has its own internal in-memory queue. Increase the size of this queue from the
default value of 100 to 1000 to improve performance for a low-latency scenario. For more information
about modifying the value of the internal message queue size, see “How to Modify the Default Host
Throttling Settings” in the BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?
LinkID=120225.

Optimize orchestration latency by reducing the number of

persistence points, if possible
The number of persistence points in an orchestration is one of the biggest factors influencing the
latency of messages flowing through orchestrations. Each time the orchestration engine encounters a
persistence point, it will serialize the orchestration instance into the MessageBox database and incur a
latency cost. Orchestration instance serialization includes all messages and variables instantiated in the
orchestration. The larger the messages and variables and the greater the number of these, the longer it
will take to persist. In situations where low-latency is required, eliminate of unnecessary persistence
points to significantly reduce latency. For more information about orchestration persistence points, see
“Persistence and the Orchestration Engine” in the BizTalk Server 2006 R2 Help at
http://go.microsoft.com/fwlink/?LinkID=108780.

Reduce the MaxReceiveInterval value in the adm_ServiceClass table

of the BizTalk Server management database
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 handlers
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.

Note
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.

Note
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.
 Note
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.

MQSeries adapter performance optimizations

Configure the MQSeries adapter using the following settings when possible to increase performance.

Adjust the value for the MQSeries receive adapter polling threads
Increase the value specified for Threads in the MQSeries Transport Properties when configuring
MQSeries adapter receive locations. Increasing this property from the default value of 2 to a value of 5
will significantly improve the rate at which messages can be received using the MQSeries adapter.

Disable transaction support on MQSeries receive locations where

not required
MQSeries adapter transaction support incurs significant overhead. If transaction support is not a
business requirement, set the Transaction Supported value in the MQSeries Transport Properties
from the default value of Yes to No.

MQSeries low-latency configuration

When using the BizTalk Adapter for MQSeries 2.0, you may notice that BizTalk Server does not
maintain end-to-end latency for all messages. For more information on this problem and the steps to
resolve it, see http://support.microsoft.com/kb/938986.

Performance optimizations in the BizTalk Server

documentation
Apply the following recommendations from the BizTalk Server documentation as appropriate:
 “Troubleshooting MessageBox Latency Issues” at http://go.microsoft.com/fwlink/?LinkId=114747
 “Identifying Performance Bottlenecks” at http://go.microsoft.com/fwlink/?LinkID=104418
 “Avoiding DBNETLIB Exceptions” at http://go.microsoft.com/fwlink/?LinkID=108787
 “Avoiding TCP/IP Port Exhaustion” at http://go.microsoft.com/fwlink/?LinkID=101610
 “Setting the EPM Threadpool Size” at http://go.microsoft.com/fwlink/?LinkId=114748

Windows PowerShell Scripts

This topic contains Windows PowerShell scripts that can be run on the computers in a BizTalk Server
environment to apply registry settings described in this guide.

Optimizing operating system performance registry

settings
The following Windows PowerShell script can be used to apply the registry settings described in
Optimizing Operating System Performance.
Copy the script below into notepad and save as Set-OSRegSettings.ps1. Then run the script on each
computer in the BizTalk Server environment by following the instructions in Optimizing Operating
System Performance:
#Set-OSRegSettings.ps1

param($RAMMb, $NumCPU,$VolType)

if (($RAMMb -eq $null) -or ($NumCPU -eq $null) -or ($VolType -eq $null) -or ($VolType -gt 4))

"`r"

"Please specify required paramemters of -RAMMb and -NumCPU and -VolType"

"Usage: .\OSSettings.ps1 -RAMMb 2048 -NumCPU 2 -VolType 4"

"Valid VolType values are: 1(few files), 2 or 3(moderate files), 4(many files)"

"`r"

exit

$ErrorActionPreference = "SilentlyContinue"

$LogFileName="OSSettings.log"

$LogTime=([System.DateTime]::Now).ToString("dd-MM-yyyy hh:mm:ss")

Add-Content $LogFileName "*********** Settings changed at $LogTime ************"

function SetProperty([string]$path, [string]$key, [string]$Value)

#Clear Error Count

$error.clear()
$oldValue = (Get-ItemProperty -path $path).$key

#Set the Registry Key

Set-ItemProperty -path $path -name $key -Type DWORD -Value $Value

#if error count is 0, regkey was updated OK

if ($error.count -eq 0)

$newValue = (Get-ItemProperty -path $path).$key

$data = "$path\$key=$oldValue"

if($oldvalue -eq $null)

Write-Output "Value for $path\$key created and set to $newValue"

Add-Content $LogFileName "Value for $path\$key created and set to $newValue"

else

Write-Output "Value for $path\$key changed from $oldValue to $newValue"

Add-Content $LogFileName "Value for $path\$key changed from $oldValue to $newValue"

#if error count is greater than 0 an error occurred and the regkey was not set

else

Add-Content $LogFileName "Error: Could not set key $path\$key"

Add-Content $LogFileName $Error[$error.count-1].exception.message

Write-Output "Error: Could not set key $path\$key"

Write-Output $Error[$error.count-1].exception

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Services\ldap" "ldapclientintegrity" 0x0

#Work out Value of $IoPageLockLimit

$IoPageLockLimit = ($RAMMb - 65) * 1024

if ($IoPageLockLimit -gt 4294967295)

$IoPageLockLimit = "0xFFFFFFFF"

else

#Convert to Hexadecimal

$IoPageLockLimit = "{0:X}" -f $IoPageLockLimit

$IoPageLockLimit = "0x" + $IoPageLockLimit

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management"

"IoPageLockLimit" ($IoPageLockLimit)

#Work out Value of $WorkerThreads

$WorkerThreads = $NumCPU * 16

if ($WorkerThreads -gt 64)

{$WorkerThreads = "0x40"} #Hexadecimal Value of 64

else

$WorkerThreads = "{0:X}" -f $WorkerThreads

$WorkerThreads = "0x" + $WorkerThreads

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Executive"

"AdditionalDelayedWorkerThreads" 0x10

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Executive"

"AdditionalCriticalWorkerThreads" 0x10

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" "MaxWorkItems"

8192

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" "MaxMpxCt" 2048

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" "MaxCmds"

2048

#Value depends of -VolType parameter passed in

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" "NtfsMftZoneReservation"
$VolType

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" "NTFSDisableLastAccessUpdate" 1

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" "NTFSDisable8dot3NameCreation"

1

SetProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" "DontVerifyRandomDrivers" 1

SetProperty "HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters" "Size" 3

SetProperty "HKLM:\System\CurrentControlSet\Control\Session Manager\Memory Management"

"LargeSystemCache" 0

Optimizing network performance registry settings

The following Windows PowerShell script can be used to apply the registry settings described in
Optimizing Network Performance.
Copy the script below into notepad and save as Set-NetworkRegSettings.ps1. Then run the script on
each computer in the BizTalk Server environment by following the instructions in Optimizing Network
Performance:
#Set-NetworkRegSettings.ps1

param([int] $MTUSize = $(throw "usage: ./Set-NetworkSettings <MTU Size>"))

$LogFileName="NetworkRegSettings.log"

$LogTime=([System.DateTime]::Now).ToString("dd-MM-yyyy hh:mm:ss")

Add-Content $LogFileName "*********** Settings changed at $LogTime ************"

function SetProperty([string]$path, [string]$key, [string]$Value) {

$oldValue = (Get-ItemProperty -path $path).$key

Set-ItemProperty -path $path -name $key -Type DWORD -Value $Value

$newValue = (Get-ItemProperty -path $path).$key

$data = "$path\$key=$oldValue"

Add-Content $LogFileName $data

Write-Output "Value for $path\$key changed from $oldValue to $newValue"

SetProperty "HKLM:\System\CurrentControlSet\Control\Session Manager\Memory Management"

"DisablePagingExecutive" 1
# Set SystemPages to 0xFFFFFFFF

# Maximize system pages. The system creates the largest number of page table entries possible
within physical memory.

# The system monitors and adjusts this value dynamically when the configuration changes.

SetProperty "HKLM:\System\CurrentControlSet\Control\Session Manager\Memory Management"

"SystemPages" 0xFFFFFFFF

# HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

# ============================================================================

$path = "HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters"

$returnValue = (Get-ItemProperty -path $path).IRPStackSize

if ( $returnValue -eq $null) {

SetProperty $path "IRPStackSize" 0x20 # IRPStackSize -> +10 (Use DWORD 0x20 (32) if not
present)

}else{

$returnValue = $returnValue + 1

SetProperty $path "IRPStackSize" $returnValue

SetProperty $path "SizReqBuf" 0x4000 # SizReqBuf -> 0x4000 (16384)

# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

# =====================================================================

$path = "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters"

SetProperty $path "DefaultTTL" 0x40 # DefaultTTL -> 0x40 (64)

SetProperty $path "EnablePMTUDiscovery" 1 # EnablePMTUDiscovery -> 1 (do not enable this if

your server is directly exposed to potential attackers)

SetProperty $path "EnablePMTUBHDetect" 1 # EnablePMTUBHDetect -> 1 (if your system is using a

SOAP or HTTP and/or initiating web connections to other systems)

SetProperty $path "TcpMaxDupAcks" 2 # TcpMaxDupAcks -> 2

SetProperty $path "Tcp1323Opts" 1 # Tcp1323Opts -> 1 (experiment with a value of 3 for possible
improved performance, especially if you are experiencing high packet loss/retransmits)

SetProperty $path "SackOpts" 1 # SackOpts -> 1 (VERY important for large TCP window sizes, such
as specified below)

SetProperty $path "MaxFreeTcbs" 0x5000 # MaxFreeTcbs -> 0x5000 (20480)

SetProperty $path "TcpMaxSendFree" 0xFFFF # TcpMaxSendFree -> 0xFFFF (65535)

SetProperty $path "MaxHashTableSize" 0xFFFF # MaxHashTableSize -> 0xFFFF (65535)

SetProperty $path "MaxUserPort" 0xFFFF # MaxUserPort -> 0xFFFF (65535)

SetProperty $path "TcpTimedWaitDelay" 0x1E # TcpTimedWaitDelay -> 0x1E (30)

SetProperty $path "GlobalMaxTcpWindowSize" 0xFFFF # GlobalMaxTcpWindowSize -> 0xFFFF (65535)

SetProperty $path "NumTCPTablePartitions" 4 # NumTCPTablePartitions -> 2 per Processor/Core

(include processor cores BUT NOT hyperthreading)

# TcpAckFrequency (requires Windows Server 2K3 Hotfix 815230)

# SetProperty $path "TcpAckFrequency" 5 #5 for 100Mb, 13 for 1Gb (requires Windows Server 2K3
Hotfix 815230) - can also be set at the interface level if mixed speeds; only set for
connections primarily processing data

SetProperty $path "SynAttackProtect" 0 # SynAttackProtect -> 0 (Only set this on systems with
web exposure if other H/W or S/W is providing DOS attack protection)

#Dedicated Network (DATA)

#------------------------

#Interfaces\<adapter ID>\MTU -> 1450-1500, test for maximum value that will pass on each
interface using PING -f -l <MTU Size> <Interface Gateway Address>, pick the value that works
across all interfaces

$RegistryEntries = Get-ItemProperty -path

"HKLM:\system\currentcontrolset\services\tcpip\parameters\interfaces\*"

foreach ( $iface in $RegistryEntries ) {

$ip = $iface.DhcpIpAddress

if ( $ip -ne $null ) { $childName = $iface.PSChildName}

else {

$ip = $iface.IPAddress

if ($ip -ne $null) { $childName = $iface.PSChildName }

$Interface = Get-ItemProperty -path

"HKLM:\system\currentcontrolset\services\tcpip\parameters\interfaces\$childName"

$path = $Interface.PSPath

SetProperty $path MTU $MTUSize

$path = "HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters"

$ForwardBufferMemory = 100*$MTUSize

SetProperty $path "ForwardBufferMemory" $ForwardBufferMemory # ForwardBufferMemory ->

100*MTUSize, rounded up to the nearest 256 byte boundary
SetProperty $path "MaxForwardBufferMemory" $ForwardBufferMemory # MaxForwardBufferMemory ->
ForwardBufferMemory

$NumForwardPackets = $ForwardBufferMemory/256

SetProperty $path "NumForwardPackets" $NumForwardPackets # NumForwardPackets ->

ForwardBufferMemory / 256

SetProperty $path "MaxNumForwardPackets" $NumForwardPackets # MaxNumForwardPackets ->

NumForwardPackets

SetProperty $path "TcpWindowSize" 0xFBA4 # TcpWindowSize -> 0xFBA4 (64420) (make this a
multiple of the TCP MSS (Max Segment Size)

# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters

# ===================================================================

$path = "HKLM:\SYSTEM\CurrentControlSet\Services\AFD\Parameters"

SetProperty $path "EnableDynamicBacklog" 1 # EnableDynamicBacklog -> 1

SetProperty $path "MinimumDynamicBacklog" 0xc8 # MinimumDynamicBacklog -> 0xc8 (200)

SetProperty $path "MaximumDynamicBacklog" 0x4e20 # MaximumDynamicBacklog -> 0x4e20 (20000)

SetProperty $path "DynamicBacklogGrowthDelta" 0x64 # DynamicBacklogGrowthDelta -> 0x64 (100)

#S/W Configuration

#=====================================================================

#Disable NETBIOS on cluster private network, if configured