Scalability is the ability of a system to expand to meet the business needs.

BizTalk Server architecture provides a very good support for scalability, i.e., being able to scale BizTalk to meet increasing workload. The decisions for scaling BizTalk would depend on the complexity of your scenario, hardware, and the throughput/latency requirements.

In BizTalk Server, scalability refers to the ability to scale when:

• The throughput needs exceed current available resources
• It is necessary to reduce latency times

There are two ways to scale your BizTalk Server system:

• Scaling out is the process of adding additional BizTalk Servers to join the existing BizTalk group. For example, if the BizTalk Server is bottlenecked by CPU resources, adding another server provides double the CPU resources, which may provide double the throughput

• Scaling up is a process of upgrading the existing computer. For example, you can upgrade a BizTalk Server computer from a four-processor machine to an eight-processor machine, or increase the amount of memory on the existing BizTalk Server

If the bottleneck is not in the BizTalk Server layer, scaling out or scaling up would not help improve performance.

For example, if the BizTalk Servers use the WCF-HTTP or SOAP send adapters to call an external Web service and the external Web service could not cope with the rate at which BizTalk is sending messages, it is possible that the SQL Server hosting the BizTalk databases is running into some bottlenecks.

When to Scale Out the BizTalk Server Tier

• The decision on whether the scale-out (i.e., adding more BizTalk Servers to the BizTalk group) or the scale-up (i.e. adding more CPU on the existing BizTalk Servers) would depend on where the bottleneck is. For example, if the existing BizTalk Servers have reached their maximum limit on memory and I/O with the increased load, the only way to increase resources would be to add another physical computer (i.e., scale out).
• You might consider scaling out instead of scaling up, i.e., adding more CPUs, for cost reasons. Scaling up is usually more expansive, as it could mean replacing the hardware.
• Scaling out allows you to have dedicated servers for receiving messages, sending messages, and processing messages. When you have dedicated servers for each functionality, it is easier to isolate problems and do maintenance on one computer without impacting the others.

Above figure shows a scaled-out BizTalk topology, scaling from one BizTalk server to 2 BizTalk servers. In the one BizTalk server topology, three host instances are sharing the BizTalk computer resources. In the two BizTalk server topology, the transmit host is separated onto a different server, which achieves more throughput.

When to Scale Up the BizTalk Server Tier

If the existing BizTalk Servers in a group encounter a CPU or memory bottleneck, you can either scale out by adding more BizTalk Servers to the group or scale up by adding more CPU/memory to the existing servers.

There are some scenarios, which you should consider to scale up instead of scaling out. For example:

• Large message transforms
• Large message that require disassembling into many small messages
• High memory/CPU utilization of some of BizTalk components, such as pipelines

Here, each message that BizTalk receives/processes requires higher CPU and memory and could not be load balanced between different BizTalk Servers.

When You Can’t Scale Up the BizTalk Tier

• The MessageBox database is the bottleneck.
• An adapter becomes the bottleneck. For example, if you are using an adapter, after you increase the number of BizTalk receivers, lock contention might increase on the backend application where the BizTalk adapter is pulling data from. This limits your ability to scale up the adapter.

Scaling Up the SQL Server Tier

If possible, always consider scaling up the SQL Server Tier first, before adding more MessageBox databases. Scaling up, would mean adding more CPUs, memory, increasing I/O bandwidth on the SQL Server hosting the BizTalk Databases (in particular, BiztalkMsgboxDb).

The Master MessageBox database will eventually be the bottleneck. Therefore, the master MessageBox database should be faster and bigger (for example, an Itanium-based 64-bit or x64-based, dual core computer) with sufficient amount of memory.

Scale up cannot address lock contention bottlenecks on the SQL tier and in that case, scale out is a better option.

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

Scaling out the SQL Server Tier

When scaling out, you should always scale from one to three SQL MessageBox databases instead of one to two.

The reason is that if you add only one MessageBox database to this topology, the Master MessageBox database will still be CPU bound and the secondary MessageBox database will be underutilized.

In a two-MessageBox scenario, if you disable publishing on the Master MessageBox database and dedicate the Master MessageBox database only to do routing, the other secondary MessageBox database would be the only database doing the publishing. This would not help to increase the overall performance since that secondary MessageBox database is the only publisher/processor of messages.

Due to the above reason, adding two secondary MessageBox databases and disabling the publishing on the Master MessageBox database would be the recommended way to scale out.

The Master MessageBox database should always be on the hardware that is most powerful as it is most heavily used. In the case where the SQL server is not CPU bound or I/O bound, but is bound by a lock contention , you can minimize sending data over the network (and the associated DTC overhead) by placing multiple MessageBox databases on the same physical computer with dedicated drives.

The above figure shows a scenario where SQL tier is scaled-out from one MessageBox database to three MessageBoxes databases.

Resource:

https://msdn.microsoft.com/en-us/library/ee274580(v=bts.10).aspx