Jeremy Petersen

Subscribe to Jeremy Petersen: eMailAlertsEmail Alerts
Get Jeremy Petersen: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Microsoft Dynamics , Microsoft Developer, AJAX and ContinuousAPM

ajax-capm: Article

Identify Performance Bottlenecks in Your BizTalk Environment - Part 3

Orchestration and calling external services

In my last two articles I wrote about how to Use BizTalk Performance Counters and how to Analyze Adapter and Pipeline Performance. In this final article I focus on Orchestration and calling external services.

Step 4: Analyzing Orchestration
Orchestrations can be as simple as reading a file from a file system, transforming it and writing it out to a different file. They can also be much more complex such as calling external web services depending on certain conditions in the incoming messages, taking the response of these services and calling other services or writing a transformed version of the response to a file or the database. The following screenshot shows a rather simple Orchestration taken from one of the examples that ships with BizTalk:

Orchestration Example showing a message flow including a call to  an external service

Orchestration Example showing a message flow including a call to an external service

The process starts by receiving a file from the receiving port ReceivePO. The message then gets transformed using a mapping definition that maps individual fields from the original message to the destination message. The following screenshot shows such a mapping definition:

Business Mapping for Message Transformation

Business Mapping for Message Transformation

The Orchestration goes on by sending a message to port POWebServicePort. The response of this Web Service call is transformed again using another mapping definition. The final transformed message is then sent to the SendInvoicePort which in my case means writing it to the file system.

What about performance?
In BizTalk message processing there are different components involved. We already learned how to analyze Adapters and Pipelines in my previous blog entry and what we can do there to analyze whether these components have a negative impact on message processing performance.

The actual logic behind the Orchestration Definition is compiled into an assembly, loaded into BizTalk, and gets executed when messages are processed by that Orchestration Definition. Here is a sample PurePath that shows the execution of compiled orchestration code:

PurePath of Orchestration Logic Execution

PurePath of Orchestration Logic Execution

What can we observe here?
Applying the Transformation takes 444ms in this scenario
The SendMessage method puts the transformed message back into the MessageBox on SQL Server. The actual interaction with the MessageBox happens in the Commit method which takes 541ms in this scenario.

I ran some more load against my BizTalk environment analyzing all the PurePath’s that trace the logic of my orchestration. With increasing load the bottleneck in my environment clearly is the MessageBox, indicated by the Commit method that takes up to 99% of the transaction execution time.

Commit taking 99% of execution time with huge transaction time  variance

Commit taking 99% of execution time with huge transaction time variance

Not only is Commit taking 99% of the time for the slowest transaction, it also has a huge variance in execution time – meaning, it doesn’t scale in my environment. If you look at the PurePath duration in the screenshot above we see execution times ranging from 1.1 to 6.9 seconds. Analyzing the methods that were executed in these transactions gives me the following information:

Non Scaling Methods in my BizTalk Environment

Non Scaling Methods in my BizTalk Environment

I added min and max execution time of the methods involved in these transactions. Not surprisingly do we see a huge range from several milliseconds to 6.9 seconds for the Commit method. The execute method on top is a transaction I haven’t yet shown you. It is thread that pulls out information from the MessageBox to further process the message.

Problem: In my scenario the MessageBox is clearly my bottleneck in my environment. Putting messages into the box and getting them out again doesn’t scale with the load I want to put on it.

What about performance counters?

Performance counters are always a great source of information. BizTalk provides a set of counters for the Orchestration Engine as well as for the MessageBox. Check out the two previous links for a description on these counters.

HINT: BizTalk MessageBox Viewer Tool

Jean-Pierre Auconie is the creator of the BizTalk MessageBox Viewer. Check out his blog and the download site for this tool. This tool runs a set of tests and queries against the MessageBox database. The results will be displayed in the tool and can also be exported as HTML reports including links. The following screenshot shows the output in the tool on my installation:

Analysis Output in BizTalk MessageBox Viewer Tool

Analysis Output in BizTalk MessageBox Viewer Tool

The tool gives an overview of what might be wrong in your installation. In my case it seems that I ran into a “classical” BizTalk MessageBox issue: My Sql Agent Jobs don’t run on my machine to clear up the database. Also check out this MSDN forum thread that talks about the same scenario somebody else ran into.

Step 5: Analyzing External Service Calls (SendPorts)
The last thing I want to show you is when my BizTalk Orchestration makes a call to the external Web Service. The following image shows a PurePath that shows the Orchestration engine making the call to the web service. The PurePath shows the web service client proxy as well as the execution of the web service on the server that implements the web service:

Distributed PurePath showing a Web Service call from BizTalk to  the Web Service implementation

Distributed PurePath showing a Web Service call from BizTalk to the Web Service implementation

The 2nd call in this trace is the call to the generated web service proxy within my BizTalk Host Instance. The web service is executed synchronously in the ASPX implementation hosted in IIS. The interesting thing here is that I have huge execution differences of this web service call. The method that varies greatly in execution time is the client side call to the proxy that is doing all the marshalling of data.

Final Words
This is the final article in my series on BizTalk. The key take away is to make sure you monitor your BizTalk performance counters. Use the BizTalk MessageBox Viewer to run checks against your individual MessageBox databases. In case you are interested in in-depth tracing of messages through BizTalk using dynaTrace you should check out Managing BizTalk Performance and The Business Process It Automates, our Community Downloads to get access to the BizTalk Fast Pack (registered users only), and a White Paper I wrote about Performance Management in Enterprise .NET Systems.

Related reading:

  1. Identify Performance Bottlenecks in your BizTalk Environment – Part I Microsoft BizTalk enables companies to integrate and automate their business...
  2. Identify Performance Bottlenecks in your BizTalk Environment – Part II In Part I of this blog series I gave a...
  3. Performance Analysis: Identify GC bottlenecks in distributed heterogeneous environments Garbage Collection can have a major impact on application performance....
  4. Performance Analysis: How to identify synchronization issues under load? Synchronization is a necessary mechanism to control access to shared...
  5. Performance Analysis: How to identify “bad” methods messing up the GC Whenever the Garbage Collector kicks in to free up memory...

More Stories By Andreas Grabner

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi