4 Different ways to process an XLANGMessage within an helper component invoked by an orchestration Part 2
Introduction
In the first part of the article we introduced and analyzed 4 different techniques to process an XLANGMessage within a business component invoked by an orchestration. In the second part we’ll compare these design patterns from a performance perspective. To this purpose I conducted some tests against the asynchronous version of each use case to measure and compare their latency and throughput. In particular, I used a floodgate approach when running test cases in order to isolate orchestration processing from message receiving and sending. To achieve this result I used BizTalk LoadGen 2007 followed the steps below at each test run.
- I ran the bts_CleanupMsgbox stored procedure to delete any unprocessed or suspended messages and any pending service instances within the BizTalkMsgBoxDb.
- I stopped the BizTalkServerApplication host instance that is responsible for running orchestrations.
- I stopped the BizTalkServerSendHost host instance that is responsible for running send ports.
- I stopped the FILE Send Port which consumes response messages generated by orchestrations. This way the send port subscription remains active and the response documents published to the BizTalkMsgBoxDb by the asynchronous orchestrations become suspended (resumable) messages.
- I stopped all the orchestrations using the BizTalk Administration Console.
- I created and launched a script that exploited BizTalk LoadGen 2007 to generate a configurable amount of messages within a given folder.
- I started another in-process host instance called BizTalkServerReceiveHost.
- A OneWay FILE Receive Location hosted by BizTalkServerReceiveHost was used to read and publish those messages to the BizTalkMsgBoxDb.
- I started an instance of the Performance Monitor (perfmon.exe) to monitor performance counters. In particular, I used the \\.\BizTalk:Message Box:General Counters(biztalkmsgboxdb:babo)\Spool Size counter to confirm that all messages were successfully published to the BizTalkMsgBoxDb.
- At the this point, on the BizTalk Administration Console I started the orchestration used by the current test case.
- I clicked the Suspended Services Instances link on the Group Overview page within the BizTalk Administration Console to retrieve all suspended messages.
- I right-clicked the summary row containing the total number of resumable messages.
- I launched a script that:
- stopped the BizTalkServerReceiveHost;
- started the BizTalkServerApplication;
- started the performance log to measure relevant BizTalk, SQL and System performance counter.
- I resumed all messages. This operations started the real test run as each resumed message was processed by a separate orchestration instance.
In order to automate the steps above, I created a bunch of scripts that you can download here along with the code.
I conducted my tests using 3 different message sizes:
- Small Size Message: 10 operations, 3 KB.
- Medium Size Message: 1,000 operations, 249 KB.
- Large Size Message: 10,000 operations, 2,485 KB.
For the sake of completeness, I conducted tests on my laptop, not really the kind of harness that should be used for performance testing:
- Windows Server 2008 R2 64-bit.
- SQL Server 2008 SP1 EE 64-bit .
- BizTalk Server 2009 64-bit EE
- 1 dual-core CPU.
- 4 GB RAM
Results
The tables below report test results. I encourage you to perform long running tests on a production-like environment composed of multiple machines to obtain more significant and relevant results. Take into account that I had just the time to run a couple of tests for each use case. Nevertheless, the results obtained are quite interesting and in line with expectations: in fact they confirm that using an XmlDocument to process the content of an XLANGMessage is extremely handy and powerful, but it can easily lead to high memory usage and performance degradation, especially when dealing with large messages.
Small Size Messages
| Test Case | # Messages/Test | # Operations/Message | Message Size (Kb) | Elapsed Time (Sec) | Messages/Sec |
| AsyncXmlDocumentOrchestration | 5,000 | 10 | 3 | 104 | 47.204 |
| AsyncStreamOrchestration | 5,000 | 10 | 3 | 87 | 58.085 |
| AsyncMessageClassesOrchestration | 5,000 | 10 | 3 | 71 | 71.434 |
| AsyncCustomBTXMessageOrchestration | 5,000 | 10 | 3 | 66 | 75.099 |
Medium Size Messages
| Test Case | # Messages/Test | # Operations/Message | Message Size (Kb) | Elapsed Time (Sec) | Messages/Sec |
| AsyncXmlDocumentOrchestration | 10,000 | 1,000 | 249 | 240 | 42.009 |
| AsyncStreamOrchestration | 10,000 | 1,000 | 249 | 224 | 46.476 |
| AsyncMessageClassesOrchestration | 10,000 | 1,000 | 249 | 188 | 54.936 |
| AsyncCustomBTXMessageOrchestration | 10,000 | 1,000 | 249 | 181 | 61.396 |
Large Size Messages
| Test Case | # Messages/Test | # Operations/Message | Message Size (Kb) | Elapsed Time (Sec) | Messages/Sec |
| AsyncXmlDocumentOrchestration | 1,000 | 10,000 | 2,485 | 182 | 5.521 |
| AsyncStreamOrchestration | 1,000 | 10,000 | 2,485 | 84 | 11.905 |
| AsyncMessageClassesOrchestration | 1,000 | 10,000 | 2,485 | 93 | 10.964 |
| AsyncCustomBTXMessageOrchestration | 1,000 | 10,000 | 2,485 | 78 | 12.718 |
Diagrams
The following diagrams summarize the results contained in the tables above and visualize the differences among the various use cases in terms of latency (elapsed time) and scalability (messages/sec).
Latency
Throughput
