Scaling Up the SQL Server Tier

In this pattern, the existing SQL MessageBox database is upgraded to scale according to the requirements in throughput or latency.

The following figure shows a scenario where the master MessageBox database is upgraded from quad processor server to 8 processor server.

Scale-up MSGBOX

When to Scale-up the SQL Tier

  • When you can scale up the master MessageBox database.

  • When the master MessageBox database becomes the bottleneck. Those bottlenecks can be:

    • CPU In case of very expensive and complex orchestration scenarios, Message box consumes heavy CPU resources. Scaling-up the SQL server by adding more CPUs should scale the scenario.

    • Memory or I/O Memory or I/O can be bottleneck and can be upgraded.

  • When scaling-up is cheaper than scaling-out and scaling-up can address the bottleneck. For example, if the master MessageBox database has an issue with SQL lock contention, this issue cannot be solved by scaling-up.

When do you decide SQL cannot scale-up?

Scale-up cannot address lock contention bottlenecks on the SQL tier. If these kinds of bottlenecks are hit, scale-out is better option than scale-up.

Strategies and Considerations for Scaling Up the SQL Tier

  • Scale-up the master MessageBox database first and then scale-out.

  • The master MessageBox database will eventually be the bottleneck. So, the master MessageBox database should be faster and bigger (for example, an Itanium-based 64-bit or x64-based, dual core computer).

See Also

Scaling Out the BizTalk Server Tier
Scaling Up the BizTalk Server Tier
Scaling Out the SQL Server Tier
Scaled-Out Receiving Hosts
Scaled-Out Processing Hosts
Scaled-Out Sending Hosts
Using Windows Server Cluster to Provide High Availability for BizTalk Server Hosts2
Scaled-Out Databases
Clustering the BizTalk Server Databases