Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

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.

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 5 (RAID5/10) or a storage area network (SAN) with backup power supply.

  • Use the SQL Server disaster recovery process to back up your databases regularly. The BizTalk Server service automatically recovers from SQL Server connection malfunctions.

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

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.