BizTalk Throttling & Thresholds

Who am I? BizTalk Administrator for Bouvet in Norway Active contributer to the community Blog, www.biztalkadmin.com, www.biztalkadminsblogging.com Microsoft TechNet Wiki, forums and galleries Speaker Trainer

Want to learn more? 400$ discount for all attending BizTalk Boot Camp BizTalk Admin Deep Dive class Los Angeles 2nd - 4th of december 400$ discount for all attending BizTalk Boot Camp Read more here: www.biztalkadmin.com

So, is throttling good or bad?

What is thresholds? Containers Limits Bounderies

How does thresholds affect BizTalk Designed to… manage server resources manage rate-based flow manage dehydration behavior

Who should change the default settings? When you see thresholds being hit due to Rate of messages Use of server resources However 70% of all companies world-wide never change the defualt setting for threshold, but should they?

Why would you change them? Grant more resources to an application Limit the application to perform less However these changes only comes into play when you have to change them due to some of the above bullets.

Resource-based throttling

Rate-based throttling

Orchestration throttling

So what is throttling then? Throttling is a first-aid kit to the environment Prevent melt-downs Prevent memory leaks Prevent developer to bring problems into production But it may also Help you to manage the use of resources based on physical resources or rate of data flow

Are we throttling now? You can monitor your throttling states Performance Monitor Built in with BizTalk BizTalk Message Agent BizTalk360 Built in throttling analyzer

Two differences! Publishing Delivery Messages being sent into the messagebox Messages being sent out from BizTalk

Publishing happens in and may also appear in Receive Ports Orchestrations Send Ports with two-way communication

Delivery happens in and may also appear in Send ports Orchestrations Receive ports with two-way communication

Publishing throttling states 2 – Incoming rate exceeds outgoing rate Counter Sub counter BizTalk:Message Agent Message publishing incoming rate message publishing outgoing rate This will happen if the incoming message rate exceeds the message outgoing rate, and the database experience problems with coping with the increasing amount of messages being published to the BizTalk databases. In order for BizTalk to deal with this problems it simply blocks the publishing of messages until incoming rate is at par with the message outgoing rate. You can view this scenario in real-time by using the performance monitor.

Publishing throttling states 4 – memory exceeds specified threshold Counter Sub counter BizTalk:Message Agent High process memory process memory usage (MB) process memory usage threshold (MB) This will happen if the incoming message rate exceeds the message outgoing rate, and the database experience problems with coping with the increasing amount of messages being published to the BizTalk databases. In order for BizTalk to deal with this problems it simply blocks the publishing of messages until incoming rate is at par with the message outgoing rate. You can view this scenario in real-time by using the performance monitor

Publishing throttling states 5- System memory exceeds threshold Counter Sub counter BizTalk:Message Agent Physical memory usage threshold (MB) Physical memory usage (MB) This state couldn't be described any better, the system memory exceeds the specified threshold and simply stops the EPM to start processing new messages and reduce the current EPM thread count, if the reason for this state is because a steep memory usage of a batch file it will take longer to finish it, and if it is too big it will be dropped by BizTalk. use the following counters too see this issue in Performance Monitor

Publishing throttling states 6 – Host message size Counter Sub counter BizTalk:Message Agent database size BizTalk:MessageBox : General Counters Spool size Tracking data size BizTalk: MessageBox : Host Counters Host queue length Host queue suspend message length 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, 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

Publishing throttling states 8 – Database session exceeds threshold Counter Sub counter BizTalk:Message Agent Database session 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

Publishing throttling states 9 – Process count exceeds threshold Counter Sub counter BizTalk:Message Agent Thread count Thread count threshold 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

Delivery throttling states 1 – Incoming rate exceeds outgoing rate Counter Sub counter BizTalk:Message Agent Message publishing incoming rate message publishing outgoing rate This happens if the message incoming rate is greater and exceeds the message outgoing rate, it can be caused by a shortage in resources or by high process complexity. BizTalk perform a self throttling blocking the delivery thread for a computed time until the message incoming rate is at par with the outgoing rate. To monitor this use the following counters in the Performance Monitor

Delivery throttling states 3 – in-process delivery exceeds threshold Counter Sub counter BizTalk:Message Agent In-process message count In-process message count threshold 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

Delivery throttling states 4 – Process memory exceeds threshold Counter Sub counter BizTalk:Message Agent High process memory Process memory usage (MB) Process memory usage threshold (MB) Active instance count In-process message count 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;

Delivery throttling states 5 - System memory exceeds threshold Counter Sub counter BizTalk:Message Agent Physical memory usage 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;

Delivery throttling states 9 -Process thread count exceeds threshold Counter Sub counter BizTalk:Message Agent Thread count Thread count threshold 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;

Demo Slow running application vs. normal application

I ask again, is throttling good or bad?

?

BizTalk Tracking

Tracking, what? When is tracking needed What can it be used for? What are default settings Should you disable it in production When is tracking needed? Is tracking really needed, what can it be used for. I highly recommend you to disable all tracking in production, it will increase the size of the BizTalk database and therefor are not recommended due to performance, specially if your environment is huge. The only default tracking options that are turned on an can only be turned of is the global tracking, this can be turned off under the settings of your environment. Its the in and out events, and the tracking of all instances. The rest can be set as you want. For orchestrations the 1st and 3rd option is on by default.

Artefact tracking Information about data going through the environment Information gathered from artifacts in BizTalk

Global Tracking Setting to turn tracking on or off for the entire environment Can be changed by right-clicking the group

Orchestration tracking Track Events - Orchestration start and end Select this check box to track the orchestration instance before and after processing of the entire business process. Orchestration tracking enables you to see the instances in the tracking query result views. Track Events - Message send and receive Select this check box to track message send and receive events. This check box is available only if you select the Orchestration start and end check box. Track Events - Shape start and end Select this check box when you need to debug orchestration instances in the Orchestration Debugger. When this check box is selected, the event list in the Orchestration Debugger is populated. This check box is available only if you select the Orchestration start and end check box. Orcheastation tracking. Options 1 and 3 on this slide is turned on by default, this two options must be on for orchestration debugger.

Orchestration tracking Track Message Bodies - Before orchestration processing Select this check box to save and track the actual message content prior to processing by the orchestration instance. This check box is available only if you select the Message send and receive check box. Track Message Bodies - After orchestration processing Select this check box to save and track the actual message content after processing by the orchestration instance. This check box is available only if you select the Message send and receive check box. Track Message Properties - Incoming messages Select this check box to track the promoted properties of an inbound message. Track Message Properties - Outgoing messages Select this check box to track the promoted properties of an outbound message.

Receive Port tracking Track Message Bodies - Request message before port processing Select this check box to save and track message content before the message is received. Track Message Bodies - Request message after port processing Select this check box to save and track message content after the message is received. Track Message Properties - Request message before port processing Select this check box to track the promoted properties of an inbound message. Track Message Properties - Request message after port processing Select this check box if you want to track the promoted properties of an outbound message.

Send Port tracking Track Message Bodies - Request message before port processing Select this check box to enable you to save and track message content before the message is received. Track Message Bodies - Request message after port processing Select this check box to enable you to save and track message content after the message is received. Track Message Properties - Request message before port processing Select this check box to track the promoted properties of an inbound message. Track Message Properties - Request message after port processing Select this check box if you want to track the promoted properties of an outbound message.

BRE tracking Fast activity Select this check box to track the instance data on which the policy operates. Condition evaluation Select this check box to track the true/false results of conditions in the selected policy. Rule firings Select this check box to track the actions started as a result of the policy. Agenda updates Select this check box to track updates to the agenda. The agenda contains a list of actions that are "true" and need to fire. Messageboxes always has to be a odd number. Not even.

Schema tracking Select the schema you want to track By selecting the schema you want to track you can see changes made before and after a messages has passed through the schema

Pipeline tracking Port start and end events Select this check box to track only when an instance starts and ends. Details include item name, assembly, and other metadata. Message send and receive events Select this check box to track message send and receive events. This check box is available only if Port start and end events is selected. Messages before pipeline processing Select this check box to save and track the message bodies received by the pipeline, which holds metadata such as URLs and promoted properties. If this is a receive pipeline, the message body is the raw message as submitted to the pipeline by the transport component. Depending on the application, the message might be encrypted, signed, or encoded. When using a BizTalk map, if this is a receive pipeline, tracking takes place after the inbound map is processed. This check box is available only if Message send and receive events is selected. Messages after pipeline processing Select this check box to save and track the message bodies sent by the pipeline, which holds metadata such as URLs and promoted properties. If this is a receive pipeline, the message body is the processed message to be submitted to the MessageBox database, which may be XML depending on your application. When using a BizTalk map, if this is a send pipeline, tracking takes place before the outbound map is processed.

Two ways to move tracking data One for moving the content of the messages One for the rest of the tracking data

Dedicated tracking host Moves all events and execute cleanup within the tracking database One per MessageBox + one for redundancy

SQL Agent job TrackedMessages_Copy_BizTalkMsgBoxDb moves all content to the tracking database

Tables in the MessageBox TrackingData_0_x contains data waiting to be transferred to BAM TrackingData_1_x contains data waiting to be transferred to the DTA database

Gathering statistics How long did my orchestration take? How long did it take from receiving till it was sent How many messages do I transfer Specific information regarding tracking based on artifacts. When should you have maintenance hours How to keep statistics

How does it evolve Information gathered over time Simplify gathering by using PowerShell, databases or other software programs like Excel and PowerPivot

In and Out Events

Service Instances

Combination

Scripts and queries Powershell script to delete old files Find information for orphaned messages Statistics from in and out events in BizTalk Statistics from in out events grouped by portname and date Large files in tracking database Get statistics from Instances in BizTalk Instances in Messagebox being processed by a host instance Stop all applications BizTalk Powershell to clean messagebox and tracking database Count Send Ports by adapters in BizTalk Count Receive Location based on adapter usage Load more information from your BizTalk Tracking database Clean orphaned messages in BizTalk Find recieve locations by address Find send ports by port address

Resources online for tracking BizTalk Server 2010: BizTalkDTADb BizTalk Server Resources on the TechNet Wiki BizTalk Server: Administrator Queries and Scripts White Paper: Proactivity in BizTalk

?