แก้ไข

แชร์ผ่าน


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