BizTalk Server 2009 : Threading and Persistence

Threads are a limited resource in BizTalk hosts and persisting a running instance state to the Messagebox is an expensive operation. The orchestration engine balances the use of threads and orchestration persistence and dehydration delicately to ensure the continued execution of the maximum number of instances possible with the minimum overhead required.

1. Dehydration

The XLANG engine saves to persistent storage the entire state of a running orchestration instance at various points so that the instance can later be completely restored in memory. The state includes

• The internal state of the engine, including its current progress

• The state of any .NET components—variables—that maintain state information and are being used by the orchestration

• Message and variable values

The XLANG engine saves the state of a running orchestration instance at various points. If it needs to rehydrate the orchestration instance, start up from a controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration instance from the last persistence point as though nothing else occurred. For example, if a message is received but an unexpected shutdown occurs before state can be saved, the engine will not record that it has received the message and will receive it again upon restarting.

According to the BizTalk Server 2009 documentation (Microsoft, 2009), the orchestration state is persisted under the following circumstances:^[]

^[] Copyright © 2009 by Microsoft Corporation. Reprinted with permission from Microsoft Corporation.

• The end of a transactional scope. The engine saves state at the end of a transactional scope to ensure transactional integrity and to ensure that the point at which the orchestration should resume is defined unambiguously, and that compensation can be carried out correctly if necessary. The orchestration will continue to run from the end of the scope if persistence was successful; otherwise, the appropriate exception handler will be invoked. If the scope is transactional and atomic, the engine will save state within that scope. If the scope is transactional and long running, the engine will generate a new transaction and save the complete state of the runtime.

• A debugging breakpoint is reached.

• A message is sent. The only exception to this is when a message is sent from within an atomic transaction scope.

• The orchestration starts another orchestration asynchronously, as with the Start Orchestration shape.

• The orchestration instance is suspended.

• The system shuts down under controlled conditions.^[] Note that this does not include abnormal termination; in that case, when the engine next runs, it will resume the orchestration instance from the last persistence point that occurred before the shutdown.

  ^[] During a controlled shutdown, the engine saves control information as well as the current state of all running orchestration instances so that it can resume running them when it is started again. The engine will continue to run the instance until it reaches the next persistence point, when it will save the orchestration state and shut down the instance before shutting itself down.

• The orchestration instance is finished.

• The engine determines that the instance should be dehydrated.

Transactions have an impact on the number of persistence points within an orchestration and the overall performance of the BizTalk Messagebox, SQL Server, and BizTalk server. An increasing number of persistence points may impede the performance of the BizTalk solution, due to the contention on access to the Messagebox database while storing orchestration instances' state. When using atomic and long-running transactions, the BizTalk developer needs to understand the performance impact of each. Although atomic transactions hold limited system resources, like threads and memory, during the lifetime of the transaction scope, they could be used to minimize the number of persistence points in an orchestration and to minimize the contention and round-trips to the database. Long-running transactions, on the other hand, may be used to optimize the use of limited system resources—threads and memory, as the XLANG engine can dehydrate an orchestration instance within the scope of a long-running transaction and reclaim its memory and threads if it meets the dehydration criteria. For this to be achieved, the XLANG engine needs to persist the orchestration instance's state at various points throughout the long-running transaction scope. Proper solution load testing and load modeling can give you indications of the number of persistence points over time, and contention over the database may be predicted and proper sizing of the servers implemented to mitigate the risk of these contentions.^[]

^[] For proper scalability and sizing techniques, refer to the BizTalk Performance and Stress Team's white paper on scalability and performance tuning.

2. The Dehydration Algorithm and Thresholds

So, how does the engine determine that an orchestration should be dehydrated? If an orchestration instance is idle, waiting at Receive, Listen, or Delay shapes, and the engine predicted that it will be idle for a longer period than the dehydration threshold, it will get dehydrated. The decision that an orchestration instance needs to be dehydrated and the prediction that it might become idle for a long period at the current shape is made based on the configurable maximum, minimum, and static thresholds. Those settings may be configured in the BTSNTSvc.exe.config file.^[] The estimated service idle time,^[] used to predict whether an orchestration instance should be dehydrated or not, is averaged out over time. As more instances of the same orchestration get instantiated, the more realistic that average becomes. If a constant dehydration threshold or a memory threshold is used, the check whether an orchestration instance should be dehydrated or not is simple, it is simply

^[] The estimated service idle time is calculated for instances of the same orchestration type. If a host instance is recycled or the server is rebooted, that value is reset and is averaged out again from scratch.

Dehydrate = (Estimated instance idle time > StaticThreshold)

or

Dehydrated = (Used host memory > MemoryThreshold)

If constant dehydration thresholds are not used, the engine checks whether the estimated instance idle time is greater than MinThreshold + Stress_scaling_factor^[] (MaxThreshold-MinThreshold).

^[] Stress_scaling_factor is a number between 0 and 1 that converges to zero with stress. This will ensure that orchestration instances get dehydrated at a much lower estimated idle time if the system is under stress.

In BizTalk 2006 and 2009, other than the check when an orchestration instance hits Receive, Listen, or Delay shapes, the engine checks periodically for instances that are passed the dehydration threshold by replacing the estimated instance idle time with the actual instance idle time in the preceding checks. Orchestration instances with actual instance idle time past the dehydration threshold are dehydrated immediately.