Scaling Your Solutions
It is important that you identify the root cause of performance issues, and solve them as much as possible before you change your hardware. After you optimize and tune the components of your BizTalk Server implementation for as much efficiency as possible, you might still encounter performance issues with BizTalk computers or the MessageBox database. In this case, the BizTalk Server system itself is the bottleneck. If the BizTalk Server system is causing performance problems, changing the hardware your system runs on is the best remedy to improve the performance.
A BizTalk Server system has two tiers: the BizTalk Server tier and the SQL Server tier, which contains your MessageBox databases. In any scenario, you can scale out or scale up each tier. That is, you can scale-out BizTalk Server and the MessageBox database, or scale up both of them.
Scalability is the ability to optimize performance by changing the hardware your system runs on. BizTalk Server architecture is designed to be scalable. You scale a system by adding or removing computers or by upgrading existing hardware. In the context of a BizTalk Server system, scalability refers to the ability of BizTalk Server to use the hardware you add to deal with increased throughput and to reduce latency times.
You can choose to scale your BizTalk Server solution up, down, or out. The scaling pattern you choose depends on the complexity of your scenario, hardware, and the throughput/Latency requirements. You can scale your BizTalk Server solution without having to radically change your application. You upgrade an existing computer to scale up; you add additional computers to scale out; and you reduce your existing system to scale down.
In most cases, if the BizTalk tier becomes a bottleneck, you improve performance by scaling it out. But, at some point, depending on complexity of your system and the hardware you use, you can’t scale out the BizTalk tier anymore and the MessageBox database becomes the bottleneck. Then, you scale up the SQL Server tier and next scale it out by adding more MessageBox databases.
|A new MessageBox database does not necessarily mean another server. A single SQL server can have multiple MessageBox databases. Also, multiple MessageBox databases incur DTC cost and network hop if the databases are on different computers.|
In theory, the MessageBox database can scale out indefinitely as long as the master MessageBox database is not saturated. For best results, start with a smaller topology and then scale-up or down based on the guidelines in this section. The topics in this section describe these scaling patterns in more detail. They also explain how to scale each pattern and how to determine when you can no longer use that pattern to scale your system.