Yossi Dahan [BizTalk]

Google
 

Saturday, October 11, 2008

Fun with Message Creation in BizTalk

Back in Match I posted this entry about creating messages "from scratch" in BizTalk.

The post started a bit of an online discussion and a slightly more intensive offline discussion about the various ways to create messages and the differences between them.

As part of that discussion, Randal van Splunteren and I have exchanged some emails and Randal took the time and effort to create a test solution to compare the performance characteristics of the various methods which I have helped validating.

Randal has been kind enough to let me summarise our findings in this blog (and it only took me 6 months...buy I have my excuses) so here it is -

The scenario we've used to test is as follows -

There is one main orchestration that takes in a ‘command’ message using a file receive location; in this command message you can define the method to create a message:

  • Map with Defaults (1)
  • Map with xsl (2)
  • Assignment with serialization (3)
  • Assignment with resource file (4)
  • Using undocumented API (5)

The first four options create messages according to the four methods I described in my blog post; the fifth one uses the CreateXmlInstance API suggested by Randal as a comment on my original post.

In the command message you can also set the number of messages that must be created;

Finally you can set if the method should use caching; we've implemented a very simple caching mechanism for the assignment and undocumented API methods (caching the generated instance in all three methods so it can be re-used in subsequent calls); for the map methods the caching parameter is ignored because BizTalk has its own caching for those methods.

When a particular test is finished the main orchestration writes out a ‘report’ message (again using file adapter) which contains the number of elapsed ticks the test took.

I've ran all the scenarios 5 times and averaged the results, between each test I have restarted the host to get as much like-for-like comparison as I could, so these numbers would not reflect true runtime performance of a live server but only the difference between the approaches; initially I ran all the tests creating 1 message at a time, here are the results:

msgs Map using defaults Map using xsl Assign using serialisation Assign using resource Assign using API
1

13,243,663

12,687,314

8,153,346

8,135,461

36,374,565

1

13,385,005

12,888,630

6,905,139

8,620,287

36,468,805

1

12,837,338

13,943,338

9,272,362

8,815,033

37,723,069

1

15,630,602

13,298,954

6,679,173

8,027,708

35,877,260

1

12,729,576

12,765,337

7,113,975

9,174,668

36,919,198

Avg

13,565,237

13,116,715

7,624,799

8,554,631

36,672,579

or to put it graphically - image

Then I ran all the tests again, this time creating 100 messages at a time -

msgs Map using defaults Map using xsl Assign using serialisation Assign using resource Assign using API
100

15,195,199

15,254,912

9,158,223

8,951,018

231,352,547

100

14,421,621

16,523,637

9,259,892

8,700,856

226,704,695

100

15,199,198

15,010,499

8,476,670

10,222,202

232,357,798

100

16,725,023

15,684,085

9,110,269

9,866,252

227,806,462

100

15,349,885

14,475,857

9,101,879

10,295,228

226,928,786

Avg

15,378,185

15,389,798

9,021,387

9,607,111

229,030,058

image

Last I ran the 3 non-mapper versions with the caching enabled -

# messages Assign using serialisation (cached) Assign using resource (Cached) Assign using API (cached)
100

9,696,044

9,478,015

41,350,100

100

8,288,120

10,087,574

37,410,620

100

9,156,289

10,473,718

36,493,118

100

8,715,621

10,001,671

40,628,198

100

8,289,295

9,951,817

37,919,237

Average

8,829,074

9,998,559

38,760,255

image

So, what I have spotted?

well, to start with, comparing my results with those Randal had I learnt that my laptop is much slower then his machine...(but you can't see that from the results, nor, I suspect, do you care...)

But seriously -

  • It is interesting to see how, with the exception of the API scenario, there is very little difference between the generation of 1 message and the generation of a 100.
  • It is quite obvious that the API call is much slower then the rest, but that does not surprise me considering the amount of work involved (getting the schema from the database, generating the instance off the XSD retrieved...)
  • For that reason, it is also quite obvious that this method was the most beneficial from the use of the cache (but was still significantly slower then the others) as the cache prevented the repeating access to the database and the xml generation.
  • On the same token, caching did not make a very significant difference in the other scenarios, but again- I wouldn't consider that surprising (as there's very little work involved)
  • And of course - it is clear that using assignment shape to create messages using either serialisation or a resource file is indeed the fastest way (serialisation being a little faster on my machine)

I hope you find this useful and again - many thanks to Randal for all his effort in helping me get this out.

Labels: , , ,

4 Comments:

  • certainly some surprises there! i often question whether using a "balnk" map to create an empty message is better than doing it in an assignment shape with a resource file. clearly not.

    would you mind sharing this solution with the community? i'd like to run it through some tests in our environment. also would like to add one or two other approaches with it too.

    By Anonymous Anonymous, at 23/10/2008, 08:06  

  • Certainly, I will need to take a few minutes to verify it again (it's been a while) and I will upload it; I will post a new entry with the link once I do, so watch out for it

    By Blogger Yossi Dahan, at 23/10/2008, 08:11  

  • Cool; that'll be swell!

    I would like to do a POC with using .NET (de)serialization to test that perf vs using a resource file to load the Xml fragment.

    By Blogger Ryan CrawCour, at 28/10/2008, 01:38  

  • Apologies folks, made it to PDC and it's mind blowing, so I can't really get much time to publish this before I come back. will try to get this up over the weekend.

    By Blogger Yossi Dahan, at 28/10/2008, 15:21  

Post a Comment

<< Home