BizTalk Server 2006 / R2 Throttling Mechanisms

BizTalk 2006 / R2 comes with good relief in terms of performance and throttling mechanism, if you work close to administrating and performance tuning job for BizTalk environment or any messaging system then you can visualize the complexity of pick processing time scenarios in any messaging system. Here with the article I am focusing to the particular BizTalk throttling scenarios and their solution. I have derived below contact by referring few books as well as my personal experience while working on performance criteria for BizTalk environment.

The below cases might not cover all the possibilities throttling scenarios of live BizTalk environment, but I have tried to collect as much from my memory.

Case: High message ratio for delivery rate / completion rate

The higher side of the ratio value indicates the service is unable to handle the rate of inbound/incoming messages to the environment. As solution we can throttle message delivery and make available as much resource as possible to BizTalk Server artifacts like XLANG and outbound transports. As a result of improved message completion rate, message latency rate and IO operation rate for message box will be reduced exponentially, also we can get more benefit by cleaning up the queue at out-bound end point.

Ideally environment should maintain ratio value around 1.05 – 1.07.

We can get monitor message delivery rate and message completion rate through various instruments like WMI / OM object / Perfmon counters / etc.

Case: High publishing ratio for request rate / completion rate

High ratio is indicates of the message box being unable to cope up with the load. To improve such scenario in our environment probably we can block publishing threads to slow down the rate and also we can indicate the service class to slow down the message-publishing rate. In the case there is no such solution available apart of scaling out the SQL Server environment where message box has been deployed, if the environment is facing such problems concurrently then it will be appropriate decision to scale-out the SQL Server environment.

I don’t have accurate observation for the value of the ratio, but I am sure that every organization must need 1 to called reliable messaging services :-).

To get the ratio value, we need to monitor entry and exit of commit batch call.

Case: Process memory exceeds a threshold

If process memory exceeds a threshold then probably your environment and batch process need steep memory, if you are getting such alerts or messages regularly then you should think about the steep memory for the environment. In this scenario, it has affect components like XLANG and all kind of transportation (adapters/pipelines). It also indicates services to dehydrate and shrink catch.

By monitoring private bytes of the process we can get clear idea about the memory threshold for the individual processes. In BizTalk hosts can be treat as processes.

Case: System memory exceeds a threshold

Same possibilities we can assume as we discussed for case “Process memory exceeds a threshold” above.

Here you can monitor the physical memory and trend through perfmon.

Case: Database session being used by the process exceed a threshold count

You can throttle publishing inside the BizTalk environment. To improve such condition, we need to tune the SQL Server Database properly and need to scale up/out as per our threshold requirement. In this scenario XLANG and all inbound transports will get affected. There is not such quick resolution available for the scenario but we can reduce/block the external/idle sessions available on SQL Server. If BAM Notification / BAS are configured to your environment and their database are also running on same server then you can disable / suspend those less priorities services to resume the message processing to normal.

Such scenario can affect XLANG objects as well as all type of inbound transports.

You can monitor session on message box by Perfmon counter / SQL Server Counters / Management Studio / etc. For cluster environment you can monitor session per message box.

Case: Process thread count exceeds a particular threshold

Throttle publishing, delivery and it indicates to reduce the thread pool size.

Such scenario affect XLANG objects as well as all kind of transports (adapters / pipeline). There is no direct solution for the scenario, long term solution could be scale-out the server box and suggestion will be to migrate 64x or itanium (or equivalent) processors server boxes. To handle some pick processing time during the day, we can provide more thread and priority to the host processes handling the threshold.

You can monitor count like threads per CPU to undertake such scenarios / cases.


BizTalk Server 2006 / R2 is handling such throttling automatically but we can get much improved performance by giving some favor to the mechanism. To perform auto throttling BizTalk Server uses the configuration parameters, I will try to come up with detail review of each parameter in next coming article.

Thanks for BEAR me during the article. Your valuable feedback and suggestion are welcome to nilayparikh@gmail.com.