Export (0) Print
Expand All

Observations and Recommendations

The results for the Messaging-only scenario were observed to be ~ 94,000,000 messages over a 24-hour period. For the Orchestration scenario, the results indicate that a single computer running BizTalk Server can process up to 37,411,200 messages per day. These results were achieved in a sandboxed environment using normal enterprise-class hardware deployed for many BizTalk Server solutions. Therefore, these results indicate the type of BizTalk Server performance of that can be achieved with no custom code. Customer solutions often involve custom-developed BizTalk artifacts; in many cases this increases processing requirements which in turn affects performance. By following the advice presented in this guide, particularly the Optimizing BizTalk Server Applications section, the impact of implementing custom-developed BizTalk Server artifacts can be minimized.

The following table provides a summary of the test results for this performance assessment.

Scenario Messaging (BizTalk KPI – Documents Processed per Second) Messaging (SQL KPI – SQL Processor Utilization) Orchestration (BizTalk KPI – Documents Processed per Second) Orchestration (SQL KPI – SQL Processor Utilization)

Single MessageBox 1 BizTalk Server computer

1088 documents processed per second

40% SQL CPU utilization

433 documents processed per second

38% SQL CPU utilization

Single MessageBox 2 BizTalk Server computers

1291 documents processed per second

50% SQL CPU utilization

676 documents processed per second

60% SQL CPU utilization

Single MessageBox 3 BizTalk Server computers

1090 documents processed per second

46% SQL CPU utilization

645 documents processed per second

49% SQL CPU utilization

Single MessageBox 4 BizTalk Server computers

1042 documents processed per second

44% SQL CPU utilization

562 documents processed per second

60% SQL CPU utilization

3 MessageBoxes 2 BizTalk Server computers

1459 documents processed per second

74% SQL CPU utilization

582 documents processed per second

78% SQL CPU utilization

3 MessageBoxes 3 BizTalk Server computers

2103 documents processed per second

67% SQL CPU utilization

830 documents processed per second

53% SQL CPU utilization

3 MessageBoxes 4 BizTalk Server computers

2070 documents processed per second

46% SQL CPU utilization

1005 documents processed per second

66% SQL CPU utilization

The following table is taken from the BizTalk Server 2004 Performance Characteristics Whitepaper (http://go.microsoft.com/fwlink/?LinkId=160239).

Number of BizTalk Server Computers One Message Box Two Message Boxes Three Message Boxes Four Message Boxes































The maximum obtainable result with four MessageBox databases in this case was 520.83 messages per second (running on dual Xeon processor 2.0-GHz hyper-threaded SQL Server computers with 4 GB of RAM). The tests performed for the BizTalk Server 2004 Performance Characteristics Whitepaper (http://go.microsoft.com/fwlink/?LinkId=160239) involved variable message sizes (2 KB to 64 KB), whereas the tests we completed on BizTalk Server 2009 were 2-KB messages only. The tests performed for the BizTalk Server 2004 Performance Characteristics Whitepaper (http://go.microsoft.com/fwlink/?LinkId=160239) also used the File adapter whereas in our study the product team used the WCF-NetTCP adapter. The maximum obtainable throughput for the Messaging scenario when using three MessageBox databases in our scenario was 2103 documents per second, which represents an improvement of 303%. The main drivers for this performance improvement are:

  1. Hardware advancements - The computers running SQL Server that we had available in our lab were Quad Processors Quad Core systems running at 2.4 GHz with 32 GB of RAM. In the 2004 tests, Dual Xeon processors HT computers running at 2.0 GHz were used.

  2. MessageBox schema optimizations - The internal schema was optimized in 2006 for high throughput scenarios. In addition to this, various improvements originally provided for mission-critical deployments of BizTalk Server have been adopted into subsequent versions of BizTalk Server. Improvement areas include updates to core stored procedures and improvements to the inner workings of the SQL Agent jobs. Furthermore, we were also able to use knowledge gained through multiple performance labs to separate MessageBox schema objects across multiple filegroups, which relieves I/O contention on SQL Server. This technique was not a common practice in the BizTalk Server 2004 timeframe.

  3. Improvement of SQL Server Engine - The tests in 2004 were performed against SQL Server 2000, whereas our tests were performed with SQL Server 2008 as the underlying database platform.

  4. Improvement of the underlying Windows Platform - These tests were performed against a 64-bit environment, whereas the 2004 tests were performed against 32-bit Windows. The 64-bit platform that Windows Server 2008 provides offers dramatic improvements in memory availability and parallel processing performance for Microsoft SQL Server 2008 and Microsoft BizTalk Server 2009 64-bit editions compared to the same software running in a 32-bit environment. The primary differences between the 64-bit and 32-bit versions are derived from the benefits of the underlying 64-bit architecture. Some of these are:

    • Larger directly-addressable memory space offered by 64-bit architecture - In our tests, SQL Server 2008 (64-bit) and BizTalk Server 2009 (64-bit) is not bound by the memory limits of 32-bit systems. Therefore, more memory is available for performing complex queries, supporting essential SQL Server database operations, and processing messages at the BizTalk tier

    • Enhanced parallelism of 64-bit architecture – The enhanced parallelism of 64-bit architecture provides more linear scalability and support for up to 64 processors, and yields stronger returns per processor as compared to a 32-bit architecture.

    • Improved bus architecture - 64-bit architecture enhances performance by moving more data between cache and processors in shorter periods.

    • Larger on-die cache - Allows for faster completion of user requests and more efficient use of processor time.

By taking advantage of these architectural enhancements, SQL Server 2008 64-bit can handle large and complex query workloads, consolidate many database applications, and more easily scale to meet the increasing processing and performance demands of enterprise-level applications. For more information about the architectural advantages of running on a 64-bit platform, see Advantages of a 64-Bit Environment (http://go.microsoft.com/fwlink/?LinkId=147234).

With these results, the BizTalk Server Product Team was able to demonstrate that a single BizTalk Server computer and a single SQL Server computer can support over 94 million messages in a messaging scenario and 37 million orchestrations during a 24-hour period. By scaling the BizTalk Server and SQL tiers to the optimal configuration available in our environment, we were able to process over 181 million messages per day and over 86 million orchestrations. The results were performed in a sandboxed environment by using the class of hardware deployed in many enterprises. As stated earlier, these numbers represent realistic performance of BizTalk Server that can be achieved with no custom code and an optimized environment. With additional hardware, it is possible that even greater performance could have been achieved. Customer solutions often involve custom-developed BizTalk artifacts that incur additional processing requirements, hence increasing resource utilization and in turn reducing overall performance. However, by following the advice outlined throughout the guide, particularly the recommendations in Optimizing BizTalk Server Applications, the impact of this can be minimized.

The results demonstrate that scaling out the number of BizTalk Server computers is an effective scale-out strategy if the MessageBox SQL Server computer is not a bottleneck. After a certain point our results indicate that adding BizTalk Server computers becomes an ineffective scale-out technique because we observed that a contention point occurred on the shared tables within the MessageBox database, which caused performance to diminish. To maximize the results that can be obtained from a BizTalk Server group with a single MessageBox database, you should apply the optimizations described in Optimizing Database Performance. In particular, you should ensure that a fast storage subsystem is used for the SQL Server storage and that the logical disks used by SQL Server to store the MessageBox database files respond in the shortest possible time. A commonly used threshold for measuring acceptable read/write performance is 15 milliseconds; typically this is measured by the Avg. Disk sec/Read and Avg. Disk sec/Write counters that can be found under the Logical Disk performance object. Once all available optimizations have been applied to the SQL Server computer that hosts the MessageBox database, additional MessageBox databases can be added. The same optimization techniques that were applied to the primary MessageBox database should also be applied to the secondary databases. We recommend that you follow the guidelines in Scaling Out the SQL Server Tier (http://go.microsoft.com/fwlink/?LinkID=158075) in the BizTalk Server documentation.

For our testing, we found that the optimum number of computers running BizTalk Server was three for the Messaging scenario and four for the Orchestration scenario. Initializing orchestrations in this scenario is more expensive than the Messaging approach in a number of ways:

  1. The Orchestration scenario requires an additional trip to the MessageBox database; the message must be retrieved from the Processing host queue, processed by the XLANG/S engine, and then returned to the MessageBox.

  2. Orchestration processing requires the BizTalk host instance to load the XLANG/s sub service into memory.

  3. For our testing, we designated either one or two of the BizTalk Server computers as a dedicated processing host. This meant that there were less send and receive host instances available than in the Messaging-only scenario.

To gain optimal results, the whole hardware and software stack needs to be of appropriate quality and also configured correctly. First, good quality hardware should be purchased including, but not limited to, gigabit networking, fast storage (SAN or 15-K local SQL disks) and modern computers that have multiple CPUs with multiple cores per CPU. The SQL Server computer should be dedicated to BizTalk Server processing only. When running a single SQL Server computer, we recommend that two instances of SQL be created, one for the BizTalk MessageBox and one for all other databases. This enables instance-wide settings to be configured for optimal performance of the MessageBox. The optimizations recommended in Optimizing Performance should be applied step by step in the following order: Optimizing Operating System Performance, Optimizing Network Performance, Pre-Configuration Database Optimizations, Post-Configuration Database Optimizations and General BizTalk Server Optimizations. Creating dedicated filegroups for the MessageBox database and allocating these across the SAN LUNs, as described in Optimizing Filegroups for the Databases, provides considerable performance improvement.

To effectively determine how to scale the BizTalk Server or SQL tier, we recommend that load testing be performed using messages that approximate actual production data. Before scaling the BizTalk Server tier, ensure that SQL Server is not already a bottleneck, as recommended in Monitoring SQL Server Performance. If SQL Server is not a bottleneck and there is CPU headroom on any of the BizTalk Server computers, you may be able to improve throughput by modifying your host instance layout. It is important to establish four or five key performance indicators (KPIs), which are used as high-level comparison points for all test runs. Following this advice, you will be able to quickly gauge whether a particular change degraded overall performance of the solution.

Before scaling out the SQL Server tier, apply all of the optimizations in Optimizing Database Performance. During the course of customer performance labs, the observation was that disk storage configuration for the MessageBox and TempDb databases in particular can provide over 30 percent throughput improvement. When scaling to multiple MessageBox databases, three MessageBox databases were used because there is little performance advantage when scaling out from a single MessageBox database to two MessageBox databases. For more information about scaling out the BizTalk Server MessageBox, see Scaling Out the SQL Server Tier (http://go.microsoft.com/fwlink/?LinkID=158075) in the BizTalk Server documentation.

This section provides a checklist of all optimizations that were applied for the lab test scenarios.

These should be tested in accordance with your change management procedures before applying these within your production environment.

Applying the optimizations in a systematic, controlled manner—by applying a set of optimizations, then testing the impact—will result in the maximum performance benefit. Applying optimizations without periodically testing the impact of the optimizations may actually result in a performance degradation of the solution.

Checklists of Optimizations Applied

Platform and Network Optimizations

Optimization Reference

BIOS: Configure settings for performance.

Optimizing Operating System Performance

Disable real-time scanning on SQL Server files.

Optimizing Operating System Performance

Move PAGEFILE onto a separate local disk on SQL Server computers.

General Guidelines for Improving Operating System Performance

Disable Antivirus on all BizTalk Server and SQL Server computers.

General Guidelines for Improving Operating System Performance

SQL Server Optimizations: General

Optimization Reference

Set NTFS File Allocation Unit to 64 KB.

Pre-Configuration Database Optimizations

Install SQL Server 2008 Service Pack 1.

Pre-Configuration Database Optimizations

Configure SQL Server 2008 Data Collector/Warehouse.

Pre-Configuration Database Optimizations

Ensure that appropriate Windows privileges have been extended to the SQL Server Service accounts.

SQL Server 2008:Setting Up Windows Service Accounts (http://go.microsoft.com/fwlink/?LinkID=132144)

SQL Server 2005: Setting Up Windows Service Accounts (http://go.microsoft.com/fwlink/?LinkId=160305).

Set Minimum and Maximum Server Memory for SQL Server.

Pre-Configuration Database Optimizations

Grant the Windows Lock Pages In Memory privilege to the account that is used for SQL Server.

Pre-Configuration Database Optimizations

Pre-allocate (size) space for the data and log files of BizTalk databases and TempDB.

Post-Configuration Database Optimizations

Configure SQL Server Client Protocols.

Troubleshooting SQL Server (http://go.microsoft.com/fwlink/?LinkID=154250)

SQL Server Optimizations: BizTalk Databases

Optimization Reference

Set Autogrowth of BizTalk databases to a fixed value and not a percentage value.

Post-Configuration Database Optimizations

Move/split BizTalk database data and log files to separate LUNS.

Post-Configuration Database Optimizations

BizTalk Optimizations

Optimization Reference

Separate receive ports, send ports, orchestrations, and tracking on separate, dedicated hosts.

General BizTalk Server Optimizations

Decrease the polling interval that BizTalk Server uses.

Low-Latency Scenario Optimizations

Adjust the BizTalk configuration file maximum connection property.

“Increase the number of SOAP and HTTP concurrent connections allowed by changing the value for the maxconnection parameter” section of General BizTalk Server Optimizations

Define CLR Hosting parameters for each host instance on each BizTalk Server node:

MaxIOThreads: 100

MaxWorkerThreads: 100

MinIOThreads: 25

MinWorkerThreads: 25

“Define CLR hosting thread values for BizTalk host instances” section of General BizTalk Server Optimizations

Increase Internal Message Queue Size to 1000.

“Increase the BizTalk Server host internal message queue size” section of Low-Latency Scenario Optimizations

Disable BizTalk Server tracking.

“Disable tracking for orchestrations, send ports, receive ports, and pipelines when tracking is not required” section of General BizTalk Server Optimizations

IIS Optimizations

Optimization Reference

Log only essential information or completely disable IIS logging.

Optimizing IIS Performance

Disable IIS application debugging.

Optimizing IIS Performance

Tune the value of the ASP Queue Length and MaxPoolThreads.

Optimizing IIS Performance

Disable IIS Application Logging.

Optimizing IIS Performance

Change the default value for maxConcurrentReguestsPerCPU to govern the number of concurrently executing requests.

Optimizing IIS Performance

WCF Configuration Optimizations

Optimization Reference

For each WCF service, apply the serviceThrottling service behavior, and set maxConcurrentCalls and maxConcurrentSessions to 200.

Optimizing BizTalk Server WCF Adapter Performance

Configure the usage of serviceThrottling behavior in the backend WCF service configuration file.

Optimizing WCF Web Service Performance

© 2014 Microsoft