Home Page › Forums › BizTalk 2004 – BizTalk 2010 › Orchestration Process slower than .NET Assemblies
- This topic has 9 replies, 1 voice, and was last updated 8 years, 3 months ago by
community-content.
-
AuthorPosts
-
-
June 14, 2006 at 8:04 AM #13850
Hi,
I’ve created a small Biztalk Orchestration that runs a Loop on it.
I’ve also created a class (in C#.net) which has same functionality as the loop of the Biztalk Orchestration. This class will become an assembly to be used by the biztalk.I tried comparing the time it takes to run Biztalk on using Biztalk Orchestration Loop, and the time it takes when using the loop in the assembly.
The assembly loop seems to be faster than the Orchestration loop. Why is that so?
The reason why I am asking this is because I am trying to optimize the speed of my Orchestration and I realized that processes inside Biztalk Orchestration is slower than the process done inside the Assembly. I want to know the reason why so I would be able to know what to do next?
Regards,
Fred -
June 15, 2006 at 2:03 AM #13851
Hi,
No, there is no send/receive shapes inside the loop.
Actually the reason why I was asking this is because I have an actual biztalk application that I need to optimize because it is taking too much time.
The biztalk application that I was talking about in this question was a simplified Biztalk application to test and compare the speed when using Biztalk Orchestration and using assembly with the same process.
Inside the loop of the really Biztalk application that I am trying to optimize contains processes, repetitive processesing the Message using xmlDocument. The Message contains multiple Line Items, which I need to process, so I need to loop through each line items.
Now, upon creating the simplified Biztalk App, which does nothing but to loop 300 times and do only one thing and that is to replace a value of a node, I also created this assembly which does the same thing, looping 300 times and replacing a value of a node. It appears that assembly is faster than biztalk app.
So I am wondering why is that so…In knowing the reason, I would be able to know how should I handle this situation.
Regards,
Fred-
June 15, 2006 at 4:34 AM #13852
No, the loop is not inside the Atomic Transaction. The Loop is in a Long Running Transaction Orchestration. The Orchestration is a long transaction because it calls some atomic transactions, then there were also Map Transformation inside the loop too. What difference does it make if the loop is inside the atomic transaction and the long running transaction? Is atomic transaction more advisable than long running transaction?
Well, on the difference side, my sample biztalk took about 4 millisecond difference between Biztalk & assembly however on actual Biztalk application, the difference was pretty big. I’ve tried the actual change on another Biztalk project by putting the loop from Biztalk to Assembly. It takes 5 to 7 seconds to run through per line time in Biztalk, and in the end it would take more than 1 minute for 20 line items. I’ve tried it in assembly it was less than a minute, even less than about 30 sec as a whole. My point here is that what if the line items would go over 500, then it would take more 30 minutes to process 500 records on Biztalk, that would be bad.
-
June 15, 2006 at 5:37 AM #13853
Hi,
Well, inside the loop, I am doing XPaths and Mapping some.
Ah i see…
Thanks for clearing out some issues for me…
Many Thanks,
Fred-
June 19, 2006 at 2:30 AM #13854
Hi Stephen & Neal,
Thank you very much for your quick and helpful replies.
I’ll be looking into your suggestions and I’m sure I’ll be able to get a great result.
Many Thanks,
Fred-
June 15, 2006 at 3:33 AM #13855
Are you running the whole loop inside an Atomic Transaction? If so, there shouldn’t be that much of a difference I would guess.
What kind of a difference are we talking about? One takes 3 seconds and the other 2 or more like one takes 60 seconds and the other 1?
In general, BizTalk will run slower than any .net code. Due to persistence and database interactions. No way to get around that. But, BizTalk adds value in other ways other then pure speed.
-
June 15, 2006 at 4:41 AM #13856
Atomic transactions reduce persistence points. Those are when the Orchestration saves it state back to the database.
Depending on how you are looping, you could see poor performance due to the persistence points.
Are you XPathing out the message to map within the loop?Without seeing your Orchestration, it’s hard to say what’s really causing the problem.
All in all, I do not think you will match or even come close to the pure .net component in this scenario.
-
June 15, 2006 at 2:53 PM #13857
You might want to take a look at some of my debatching items on this site.
http://www.biztalkgurus.com/WhitePapers/Debatching-Options-Performance-BizTalk2004.html
XPath really sucks inside a Loop in an Orchestration.
-
June 14, 2006 at 3:06 PM #13858
Are there any send/receive shapes inside the loop? That would involve all Biztalk’s logging and database interaction. If no sends/receives, what are you doing inside the loop?
There is a \”File Dumper\” utility that will show you the C# code generated by a Biztalk compile:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=1a57f0a5-3c3d-4a97-a762-0825daf15ab0
This might give you a rough idea of what Biztalk is actually doing – but it may call many Bitalk functions which you won’t have source code for.-
June 15, 2006 at 4:51 PM #13859
What about the Orchestraiton Debugger itself?
Every execution of every expression gets written to dta_DebugTrace table of the tracking database (with the start/end time of each shape).
Not sure there is any way to turn this off. So there is at least one database I/O per shape.
Neal
-
-
-
-
-
-
-
-
-
-
AuthorPosts
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.