In my last two blog entries I wrote about how to Use BizTalk Performance Counters and how to Analyze Adapter and Pipeline Performance. In this final blog 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:
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:
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:
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.
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:
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:
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:
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.
This is the final entry of my blog series for 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.