Export (0) Print
Expand All

Key Performance Indicators

This topic provides test results that the BizTalk Server product group observed when using the following scale-out methods:

  • Key performance indicators (KPIs) when increasing the number of BizTalk Server computers in a BizTalk Server group. For these tests, only one BizTalk Server MessageBox database was configured for the BizTalk Server group. These tests focused solely on the impact of adding more BizTalk Server computers to a BizTalk Server group.

  • KPIs when increasing the number of BizTalk Server MessageBox databases used by the BizTalk Server group. These tests focused solely on the impact of adding more BizTalk Server MessageBox databases to a BizTalk Server group.

  • KPIs when increasing the number of both BizTalk Server computers and BizTalk Server MessageBox databases used by the BizTalk Server group. These tests measured the impact of adding both BizTalk Server computers and BizTalk Server MessageBox databases to a BizTalk Server group.

Messaging-only scenario, BizTalk Server scale-out – SQL KPI

Adding a second computer running BizTalk Server increases overall throughput by approximately 18 percent and reduces the load on the BizTalk Server CPU, which had become a bottleneck. The CPU for SQL Server increases from 40 percent to 50 percent when the second computer running BizTalk Server is added to the BizTalk Server group. Beyond this point, no further performance benefit was gained by increasing the number of BizTalk processing servers, as can be seen in the following results.The contention point was access to the shared tables within the MessageBox, specifically the Spool and Parts table. Due to this contention, further processing power actually results in overall system performance degradation. Each BizTalk host instance regularly polls the appropriate queue in the MessageBox. Any message that is referenced on the host queue is actually stored within the shared set of tables in the MessageBox. If throughput drops when adding more computers running BizTalk Server, a common cause is too much activity against the shared tables within the MessageBox database. A dedicated I/O path for SQL Server to these tables can be created by assigning these tables to a specific filegroup. Optimizing Filegroups for the Databases provides guidance on how to assign tables to specific filegroups. Scaling out to a multiple MessageBox configuration should only be considered after distributing MessageBox objects across multiple filegroups, and after all other SQL-related optimizations have been applied.

Percentage of SQL Server CPU utilization

SQL Server KPI / Scale BizTalk only

Messaging-only scenario, BizTalk Server scale-out - BizTalk KPI

Adding a second computer running BizTalk Server increases overall throughput by approximately 18 percent, and reduces the load on the CPU, which had become a contention point. Further processing power actually results in performance degradation. Each BizTalk host instance regularly polls the appropriate queue in the MessageBox. Any message that is referenced on the host queue is actually stored within a shared set of tables in the MessageBox. If you see throughput drop when adding computers running BizTalk Server, such as in the following figure, a common cause is too much activity against the shared tables within the MessageBox. A dedicated I/O path for SQL Server to these tables can be created by assigning these to a specific filegroup. The script included in BizTalk Server MessageBox Database Filegroups SQL Script of the guide tells how you can accomplish this.

Percentage of BizTalk Server CPU utilization

BizTalk KPI / Scale BizTalk only

Messaging-only scenario, BizTalk Server and SQL Server scale-out – SQL KPI

This test was performed to determine the effectiveness of scaling out the SQL Server tier by adding multiple MessageBox databases. In this scenario, adding up to three computers running BizTalk Server enabled a maximum sustainable throughput of 2,103 messages per second. This was 62 percent higher than the maximum obtainable throughput when using only a single MessageBox. Beyond this point, adding more processing power to the BizTalk Server tier degraded performance in a similar fashion to the single MessageBox scenario. Further analysis showed that, as with the single MessageBox case, the contention point was access to the shared tables within the MessageBox, specifically the Spool and Parts table. Due to this contention, further processing power actually results in overall system performance degradation.

The key findings from the Messaging scenario tests are that scaling out BizTalk Server is an effective technique to increase overall throughput if contention on SQL Server is not a bottleneck. If the MessageBox database becomes a contention point, first apply the optimizations detailed in Optimizing Database Performance, particularly the filegroup optimization script described in BizTalk Server MessageBox Database Filegroups SQL Script to distribute I/O load. If you are still unable to achieve your desired throughput, you should consider scaling out by adding more MessageBox databases.

Percentage of SQL Server CPU utilization

SQL Server KPI / Scale BizTalk and Messagebox DBs

Messaging-only scenario, BizTalk Server and SQL Server scale-out – BizTalk KPI

Comparing these to the Messaging scenario with a single SQL instance and MessageBox shows that scaling out BizTalk Server is an effective technique for increasing overall throughput if contention on SQL Server is not a bottleneck.

Percentage of BizTalk Server CPU utilization

BizTalk Server KPI / Scale BizTalk and MsgBox DBs

Orchestration scenario, BizTalk Server scale-out – SQL and BizTalk KPI

Adding a second computer running BizTalk Server increases overall throughput by approximately 56 percent, and reduces the load on the BizTalk Server CPU, which had become a bottleneck. The CPU for SQL Server increases from 38 percent to 60 percent when an additional computer running BizTalk Server is added. Beyond this point, no further performance benefit was gained by increasing the number of BizTalk processing servers, as can be seen in the following results. As with the Messaging scenario, the bottleneck was due to access to the shared tables within the MessageBox database, specifically the Spool and Parts table.

Percentage of SQL Server CPU utilization

SQL Server KPI / Scale BTS only / Orch Scenario

Percentage of BizTalk Server CPU utilization

SQL Server KPI / Scale BTS only / Orch Scenario

Orchestration scenario, BizTalk Server and SQL Server scale-out – SQL and BizTalk KPI

This test was performed to determine the effectiveness of scaling out both the BizTalk Server and SQL Server tier by adding more computers running BizTalk Server and more MessageBox databases for the Orchestration scenario. In this scenario, adding up to four computers running BizTalk Server enabled a maximum sustainable throughput of 1,005 orchestrations per second. This was 78 percent higher than the maximum obtainable result against a single MessageBox. Scaling out to three MessageBox databases on separate SQL Server computers accommodates increased throughput due to additional processing power and the ability to distribute database load across multiple MessageBox databases. This tactic also relieves contention on shared tables, which was a bottleneck in the single MessageBox environment. As with the Messaging scenario, increasing the number of MessageBox databases and distributing these across dedicated SQL instances enables the addition of several BizTalk Server computers to the BizTalk Server group. Interestingly, the addition of a fourth BizTalk Server computer increased effective throughput in the Orchestration scenario but marginally decreased it in the Messaging scenario.

Percentage of SQL Server CPU utilization

SQL Server KPI / Scale BTS_MsgBox / Orch scenario

Percentage of BizTalk Server CPU utilization

BTS Server KPI / Scale BTS_MsgBox / Orch scenario
Show:
© 2014 Microsoft