There are many scenarios that may expose you to an automatic throttling state, a few of this are:
The automatic throttling states can be used to stabilize environment, you can set different thresholds to manage the use of resources for a host, by setting thresholds for threads will make sure that the host never will use more threads, and will make sure
it won't eat up all your threads. This can be used when performing performance optimizing by limiting the use of resources for some hosts, and granting more to others.
This may happen if you have a steep increment of memory use in for example large batch files. BizTalk will automatically reduce the size of the EPM thread pool, and stops any creation of new threads, if the batch requires a lot of resources it will actually
slow down the process in order to maintain the availability for the rest of the environment. Sometimes the message if it is too big and including too many messages may be blocked out completely by BizTalk. In order to monitor this you need to open the following
views in Performance Monitor:
The reason why you encounter this state maybe that some of your SQL jobs have stopped, tracking host is not running or the number of suspended messages is high. This state will as the one above create the same scenario as above, it will reduce the threads
for EPM, and it also blocks the EPM to process any new messages and creates a publishing delay for all messages. In this scenario there are several counters to monitor:
This state simply states that the sessions used by the host towards the database exceeds the specified threshold. The auto throttling here will do the same as in state 4 and 6, reduce the threads for EPM and stop the execution of any the threads, it will
also delay all ongoing messages until the database is back to normal. If this happens I recommend you to reduce the database connection threshold for the host. You can monitor this by looking at the following counters in Performance Monitor:
What it says is that the process counts exceeds a specified threshold, the reason for this may be that you have to many transactions on that hosts that creates too many processes, try reducing the amount of allowed threads on the host so that the system
don’t create too many threads. The self-throttling will do the exact same as in state 8 and basically reduce the EPM thread count, stop it from creating new and messages will be delayed until the host is back to normal state again. You can monitor this by
using the following counters in Performance Monitor:
This state informs us that the a number on in-process messages delivered to a service class exceeds the specified threshold and can be caused by processing high complexity messages, slow outbound adapters or a shortage in resources on the server. BizTalk
self-throttles and slows down the message delivery to XLANG or adapters, It also reduce the size of the thread pool by the message agent. You can monitor this by looking at the following counters in Performance Monitor:
This one is also covered well in publishing throttling states, it basically tells us that we exceed the specified value of the process memory threshold. It occurs when you have large and complex messages that are being processed, or a high amount of message
simultaneously. This sate will not make the system idle so no immediate action is needed if this is a once in a life-time scenario, however BizTalk will still perform self-throttling and slow down delivery of messages to adapters and XLANG. It may also reduce
the memory usage by dehydrating messages and reduce the size of the EPM thread pool sometimes it also force a .NET garbage collect. You can monitor this by using the counters described below:
Basically the systems memory exceeds the specified threshold and BizTalk will slow down message delivery to adapters and XLANG, it will also try to decrease the memory consumption by dehydrating messages it also reduce the thread pool size of EPM. If you
have this issue often you should consider reducing the EPM thread pool to decrease the occurrence of this throttling state as it will slow down BizTalk drastically. You can read the monitor for this in Performance Monitor as well by using the following counter:
You will encounter this sate if BizTalk has a process thread count that exceeds the specified threshold. BizTalk will automatic throttle to decrease the thread count used by EPM and you should consider changing the different thread throttling settings for
the different hosts. You can monitor this issue too in Performance Monitor by checking the following counters:
How BizTalk Server Implements Host Throttling
Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is
BizTalk Server Resources on the TechNet Wiki.
Compliments on this great article!
Thank you Steef-Jan!
A very important issue, and a good article.
From my experience, I dont remember much cases where a system I was working with, was going through a serious throttling state and managed to overcome the stress using the biztalk automatic mechanism. Even though many parameters are configurable, I think that most of the time, steps taken by the biztalk engine dont solve the cause of the throttling, but more help to avoid critical stress on resources that may cause general crash down.
I think it's not recommended to count on throttling mechanism to save the day in case of serious load on the systems. Better to make sure you dont get to that state at all
Hey Shay, I can see why you feel it like that, however remember that you can use this to limit the use of resources, and the throttling states will hit when such a scenario occur. I updated the article with more information regarding this.
Throttling states are vital to follow if you use them and need them, and whenever you have issues with BizTalk checking the throttling states will often give you a quick idea of what the issue might be. And network related issues can occur anytime, and by viewing the throttling state you can eaiser locate where the bottleneck is. Understanding BizTalk performance and optimizing is hard and time consuming but from my experience checking throttling states can often locate the bottleneck faster then checking all other locations first.
Anyways, a good tip and contribution to the wiki article! Have a nice day!
Nice article. Easy to understand
Awesome article Tord.
Thank you Nino!
Great article Tord, as you always say, BizTalk Throttling is your friend!
Its really a wonderful atricle but my bad i didnt see this while i was perfoming perfomance testing for a newly setup production environment. Anyway, this will help me in future!