IT tutorials
 
Applications Server
 

BizTalk Server 2009 : Threading and Persistence

5/2/2013 1:53:14 AM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

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.

The checks for constant dehydration thresholds do not use the Stress_scaling_factor. This means that the thresholds do not decrease as the server is under increasing stress!

 
Others
 
- Monitoring Microsoft Lync Server 2010 : How to Use OpsMgr
- Monitoring Microsoft Lync Server 2010 : OpsMgr Architecture
- Microsoft Dynamics Ax 2009 : Developing Role Centers - Role Center Web Parts
- Microsoft Dynamics Ax 2009 : Role Centers - Introduction
- Microsoft Dynamics Ax 2009 : Enterprise Portal - Securing Web Elements, Developing the Navigation
- Microsoft SharePoint 2010 : WebParts and SharePoint Pages - Writing Visual WebParts
- Microsoft SharePoint 2010 : WebParts and SharePoint Pages - Using SharePoint Designer with WebParts
- BizTalk Server 2009 : Do You Really Need an Orchestration?
- BizTalk Server 2009 : What the Orchestration Engine Provides
- SharePoint 2010 : Setting up Visio Services
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS