Pipeline Component, XmlSerialization and Performance

Posted at: 5/29/2007 at 12:33 PM by saravana

I'm basically replying to Yossi's post here. I tried to leave it as a comment in his post but for some reasons my comments are not getting posted in his blog.

Myself and Yossi used to work together in a big public sector Healthcare BizTalk project for nearly 1.5 years.

First off all I need to thank Yossi for his complement about my white paper "Understanding Design-Time Properties for Custom Pipeline Components in BizTalk Server". Yossi mentioned in his post about the potential performance problem in using XmlSerializer inside pipeline component. Until now I thought his point is valid, but after reading the very first chapter from Professional BizTalk Server 2006 by (DJ, KS and EF) , where Darren explains about Serialization and performance hit, its clear there is NO PERFORMANCE HIT by using XmlSerialization in a BizTalk solution.

I thought the explanation will be helpful for readers to make the decision. The following extract is from the book (Page 11):

"When you first use the XmlSerializer in your application against a given type, a dynamic class is created and compiled on the fly to represent the serialized class. This has an obvious performance over head, but it will be cached for susbsequent requests

This cache is maintained per AppDomain, which is fine for applications like BizTalk, as there is by default only one AppDomain per BizTalk host.
"
.

So, eventually by using XmlSerialization inside the pipeline component, you'll hit the penalty only once during the lifetime of the component. That's until some one restarts the host.

Nandri!,
Saravana

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Tags: |  Categories: BizTalk General
Actions: Email this article Email | Kick it! | DZone it! | Save to del.icio.us | Technorati Links
Post Information: Permanent LinkPermalink | CommentsComments(6) | Comments RSS

Comments

Tuesday, May 29, 2007 11:49 PM
Tomas
I think this might be true in 2006, but I'm thinking this is *not* true in 2004. At least, there was no built-in caching of generated assemblies in the XMlSerializer in .NET 1.1, and I clearly remember spending a lot of time going through some of the code in BizTalk 2004 and seeing no caching at all being made... so one might still want to test just to be sure Smile
Wednesday, May 30, 2007 9:47 AM
Yossi Dahan
Thanks for the remark Saravana.

I've added a link to your post as a comment on the original www.sabratech.co.uk/.../...eline-component_30.html" REL="nofollow">blog post as well as a few words of my own.
Friday, June 01, 2007 3:45 PM
Darren Jefford
The standard XmlSerializer "appdomain" caching was there in .NET Framework 1.1, 2.0 introduced the ability to "pre-generate" these dyanmic assemblies which you can do by using sgen.exe - This pre-generated assembly is then used instead of dynamically creating one
Tuesday, August 21, 2007 12:00 PM
Aaron Kim
That's until some one restarts the host. -> I just want to make sure you mean host instance by host, right? Host is a logical container so you can't restart it, right? So does it mean there's only one AppDomain per BizTalk host instance?
Wednesday, August 22, 2007 7:09 AM
Saravana Kumar
Aaron. Yeah, that's right, it means restarting the host instance. My understanding is BizTalk got few subservices like EPM,XLANG, Caching, Tracking (TDDS) etc all running inside the host instance, so they all will have their own "AppDomains" inside the host instance. Your XmlSerializion code will be cached into the corresponding "AppDomain" based on where its running mainly under EPM or XLANG.
Monday, May 26, 2008 3:11 PM
Andrea Ramacciotti
The problem I have is when try to change settings of complex properties (collection) using BizTalk console.
No PropertyBag "Save" method is invoked and then all the following received message takes the old values.

Add comment


(Will show your Gravatar icon)  

  Country flag

biuquote
  • Comment
  • Preview
Loading