Scalability is ability of a system, network, or process to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth.
Since BizTalk works on SQL layer, it is very common to find bottlenecks in the MessageBox database during performance and scalability tests of a high volume BizTalk solution when you try to determine the Maximum Sustainable Throughput.
These bottlenecks can be:
1. CPU – In case of complex orchestration scenarios, the MessageBox database consumes a lot of CPU resources.
2. Lock Contention – Complex scenarios with multiple host instances or orchestrations tend to create lock contention on the MessageBox database.
3. Disk I/O – Disk I/O is a common bottleneck for the MessageBox database.
One of the significant optimization step when dealing with scaling the BizTalk Message Box is adding new message boxes even when they are created in the same SQL Instance.
But you will need to add three message boxes to achieve the best performance. Why so?
Lets consider the 1 SQL server topology with 2 BizTalk Servers
Now lets say if CPU processing is a bottleneck, then 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 under-used.
If you disable publishing on the master MessageBox database and dedicate the master MessageBox database to do only routing, the secondary MessageBox database will do the publishing. However, this will not increase overall throughput because the secondary MessageBox database is the only publisher and becomes the bottleneck. So, adding 2 secondary MessageBox databases and disabling the publishing on the master MessageBox database is recommended for scaling-out in this scenario.
How to add multiple Message Box database in an existing BizTalk group