Deliberately slow down BizTalk by using throttling

BizTalk by itself is not the fastest message broker there is. It relies heavily on SQL Server instead of in-memory queues. BizTalk isn’t slow, far from it, but there are other  systems, like Mule or WSO2, that will process messages even faster. You will loose some control, but that’s the trade-of you make if you need to process messages the fastest way possible.

But speed isn’t everything, especially since you rely on the capabilities of other systems that have to process your messages. Systems that can’t handle ten messages a second, but just one. So I got the interesting question last week whether it was possible to slow down BizTalk and have it process one message per second.

Let’s start by saying that there’s no easy way to do this. There’s no setting on your receive port or send port to achieve this nor is there a setting on most of your adapters. An orchestration could be an option. Make it Singleton and process messages one by one, wait for the acknowledgement, wait for another second and send the next one. Of course this will take some time to develop and you will get other problems, like those darn zombies. Or maybe we can use a database and keep track of the messages sent out ourselves – or why don’t we just do it all in .Net and build our own queue then? 😉

The only relatively easy way to do this is deliberately initiating throttling on a host and make the host process one message per second. It’s a technique used by BizTalk admins to slow BizTalk down. The only problem I encountered was that I couldn’t find an article about it, hence this blogpost.

For most advanced BizTalk devs and admins, this is nothing new. I am publishing it especially for those new to the club. I hope this article will help out the guys who are new to BizTalk and its throttling capabilities.

Throttling

In most cases you don’t want BizTalk to be throttling. It’s mostly related to underpowered servers and you just need to add resources or scale-out BizTalk. Throttling is not a bad thing, it’s a way for BizTalk to make sure your server won’t crash under heavy loads, but it will significantly slow BizTalk down. So it shouldn’t happen too much.

But it’s perfect for our scenario here… 🙂 Deliberately slow down BizTalk!

In this example BizTalk will only publish one message per second to the messagebox.

1) Setup your throttling host

Of course you have to make a separate host and host instance to make sure you will not be throttling your normal processes. Go ahead and setup a throttling host and host instance. In this example called “ThrottlingHost”.

After the hosts have been created, make sure to add them to the appropriate adapters! In this example I will be using a FILE adapter. So go to the file adapter settings and add the ThrottlingHost. The receiving side is enough, but you may also add it for sending messages.

Now go to the BizTalk Settings Dashboard (right click on the BizTalk group, hosts or host instance and click settings). You will something that resembles the window below. Go to Hosts > Rate-Based Throttling.

In newer BizTalk versions we can easily initiate throttling ourselves by overriding the settings and select Initiate Throttling. We do need to provide a Maximum throttling delay of 1 second (the maximum time BizTalk will try to use for message delivery when in throttling state) and set the Throttling override severity to no less than 10. If you go to low (e.g. “1”), BizTalk will not use the full second for throttling, because it thinks the impact is not high enough. You may need to find a setting that suits your scenario best.

2) Setup your receive location

Setup a receive location to receive the files that need to be throttled. That’s an easy one. Just make sure your receive location is using the ThrottlingHost as the Receive handler.

After that we do need to change one more setting. By default the FILE adapter picks up 20 messages in a batch, we just want the one message. So go into the FILE Transport Properties and change the Number of messages in a batch to “1”.

After you make sure you have a subscribing service (i.e. a send port or orchestration) that picks up the received messages, restart the host instance and start testing! After a host instance restart BizTalk will not initiate the throttling immediately and you will notice some delay or maybe it’s processing too fast. But after a few messages BizTalk will get the hang of it and process one message at a time and miraculously process one message a second. Exactly the scenario I was looking for!

Of course the only problem is the receiving system. If the system goes down, BizTalk will queue up the messages (in case of an ordered delivery send port) and will deliver those messages just as fast as we are used to after we resume it. I will do some more testing and see if I can get around that as well and of course keep you guys posted!