Export (0) Print
Expand All

Measuring Maximum Sustainable Engine Throughput

One of the primary considerations when planning a BizTalk Server system should be to determine the maximum sustainable throughput (MST) of the system. The MST of a BizTalk Server system is measured as the highest load of message traffic that the BizTalk system can handle indefinitely in production. This is important because as load exceeds MST, messages are backlogged in the MessageBox database and message delivery may be delayed. If you calculate the MST of your BizTalk Server system as part of normal testing then you can scale your system to avoid extended overload scenarios in production.

Maximum sustainable throughput is directly impacted by a wide range of factors such as available server resources, the type of features used in the solution, message size, and overall message load. There are other factors to be considered though that may not be immediately obvious. The following factors should also be considered when estimating maximum sustainable performance:

Messages do not usually flow into a production BizTalk Server environment at a predictable, consistent rate. Instead, business needs dictate that BizTalk Server process messages at a variable rate which has peaks and valleys. When peaks occur, the BizTalk Server processing requirements may quickly jump from negligible to an overdrive condition where messages are received faster than they are processed. In this scenario, published messages are backlogged in the MessageBox database until BizTalk Server delivers the backlogged messages to the appropriate subscribers. As long as BizTalk Server is able to process the backlog of messages accumulated between peak load periods then this is not problematic.

Because of the variable pattern of message flow into a BizTalk Server environment, testing scenarios should be run for an extended period of time to ensure that the solution can sustain the desired throughput indefinitely, recovering from all peak loads over time.

During the life of a production solution, there is a host of monitoring and maintenance activities that can impact BizTalk Server performance and so should be factored into any testing scenarios. These activities include:

  • BizTalk Administration console and Health and Activity Tracking (HAT) queries These queries consume resources and affect overall throughput depending on the type and frequency of the query.

  • Backup, archiving, and purging activities These activities also consume resources and should be factored into any testing scenarios. All BizTalk Server databases should be backed up periodically and their transaction logs truncated. If this is not performed, the transaction log may grow un-checked and consume all of the available disk space for the transaction database. If tracking is used, the BizTalk Tracking database must periodically be purged and optionally archived to keep it from growing too large. For more information about maintaining BizTalk Server databases, see "Backing Up and Restoring BizTalk Server Databases" in BizTalk Server 2006 R2 Help at http://go.microsoft.com/fwlink/?LinkId=105450.

  • SQL Server autogrow The BizTalk databases, by default have autogrow enabled with a maximum size of 1 MG to allow tables to grow when needed. If autogrow occurs frequently, the memory used by the tables can become highly fragmented. Because of this, we recommend that you do not rely on autogrowth to manage your data and log growth on a day-to-day basis. You should consider autogrowth to be a contingency for unexpected growth only, and instead manually grow the BizTalk Server data files on a regular basis. For more information about autogrowth, see knowledge base article 315512, "INF: Considerations for Autogrow and Autoshrink configuration in SQL Server," at http://support.microsoft.com/kb/315512.

Show:
© 2014 Microsoft