Host scaling in BizTalk – When to do it!

@omegar (Gareth Kavanagh) is one of my “long time followers” on Twitter and after my last blog post he had a question regarding scaling of hosts. In this blog post I would like to go through my best practices when it comes to this matter.

So, BizTalk is built to handle, process, receive and sending data. including this you have the tracking functionality of the data as well. By default global tracking is turned on and stores information about in and out events and instances. Most company (for some reason) store debugging information in the production environments. So by default in all environments you should have at least 4 hosts (we are talking about enterprise licenses for BizTalk because of scalability). Those are receiving, sending, orchestrations and tracking.

Receiving will only have one purpose in BizTalk, that is receiving. In many scenarios you might have different options, you might want to pick up more files in receive then you are sending out, or you want to stop all receiving, Having a dedicated receive host will make this easy and comprehensible. However this is where you in almost all environments are bound to have 2 receive host, on is in-process the other one is isolated running your webservices etc.

Sending is basically the same as receiving and you get the same benefits, however for sending isolated hosts are not necessary since send ports are not hosted in your IIS.

Orchestration hosts are dedicated to perform orchestration, their need differ from sending and receiving benefits of splitting orchestrations from other artefacts in BizTalk is the benefit to grant or add more resources (thresholds).

The dedicated tracking host on the other hand should not do anything within BizTalk itself it should only move tracking data from the messagebox to the tracking and bam database.

But then we get into the subject I was supposed to discuss, scaling the hosts, when do you need to do it.

First of all when you feel like you have to change throttling, maybe some hosts should be dedicated for high throughput and some for low latency. Rumor has it that an environment should never have more than 20 host instances, I can tel you that this is a lie and there isn’t a maximum nor a minimum (well there is a minimum though). When the load on one host instance is breached you might want to add another one, I’ve seen where application start having trouble when they hit 150 active threads at once (this rarely happens) adding a new host to take some more of the load could solve the problem, or if you have a multi-server environment adding another host instance may resolve it (and of course changing the threshold for threads per CPU). So if you scale out too far you will see problems basically because the shared resources on the server wont be able to split the resources between each other and of course it will be very messy in the console and the messagebox database will have more tables than needed.

So if you experience strange delay and thresholds being hit, you can grant more (as long as the server has more to give) or scale out. I like to make sure that application running a lot of files (I’m talking about millions of files) have their own host instances so I can tweak them as I want without interfering with other application where default thresholds are more than sufficent.

However this is a large topic, and hard to explain. If you have any other questions please add a comment.

1 Response to "Host scaling in BizTalk – When to do it!"

Leave a Comment