Geeks With Blogs
Abhijeet Raje BizTalk an EAI Tool.. an ETL Tool... its.. super framework to create any tool

BizTalk Server Performance Tuning...

 

Well…with every project whether it is a windows application, a web application or any integration project; performance tuning is the most sizzling area of debate.

 

Following are the findings from the performance carried out on heavily loaded message broker architect on Biztalk server 2004. I will not be going to talk about the hardware used or message volume (consider it as best and high respectively.)  You can also consider these points as Do and Don’t for any Biztalk solution.

 

  • Avoid extensive use of atomic scope

There are various scenarios where developer uses atomic scope unintentionally without knowing the impact.

 

A typical example is when you have to marked Orchestrations as long running because whenever there is invocation of the rules engine via the Orchestration ‘rules’ shape needs to be performed within an atomic scope, but an atomic scope may only be present in an orchestration that is marked as long running.

 

The best approach is to call the rules engine via custom code in an ‘expression’ shape, this would enable the removable of the atomic scope and also the orchestration could then be marked as transaction type = none. This gave a performance improvement in the order of 15%

 

  • Effect of Tracking via BAM

BAM is used across the business process to monitor business activities, as an general approach a user can track or raise BAM events at any point in orchestration but this will be a major performance issue.

 

The reason for this is due to the fact that the buffered event stream is called in a manner that forces it to be flushed to the data base on every BAM API call, a more performant approach would be to only flush the BAM stream at persistence points which would result in fewer database writes. However, in order to do this the BAM buffered event stream would need to be state in the Orchestration, to do this correctly would require it to be marked as seralizable, currently it is not. Alternatively the Tracking Profile Editor could be used to achieve this.

 

 

  • Delivery Notifications

The performance cost of using ‘delivery notifications’ in the Orchestration is the most remarkable discovery. Delivery notifications are Biztalk system level messages that are sent internally to the Biztalk engine; they enable an Orchestration to block on a send operation until the message has been successfully transmitted by the send adapter. This is important due to the nature of the scalable architecture of Biztalk, where, a send from Orchestration is always via persistence to the Message Box, which enables any send host to actually send the message. The down side of this approach is that a successful send from an Orchestration simply means the message was successfully persisted to the message box and does not necessarily mean the message was actually transmitted. For this reason the solution marks send ports in Orchestration as delivery notification required.

 

Delivery notifications effect performance in two ways, firstly the publication and routing of these internal messages adds additional load to the Message Box and the engine. Secondly, there is reduced concurrency of these Orchestrations which may lead to performance degradation.

 

Not using delivery notifications for this scenario gave a performance gain in the order of a 48% performance.

 

 

  • Inline Send to a physical Location (BizTalk 2006 goodies)   

On analysis of the performance data, particularly around the performance cost of the delivery notifications, it was determined that significant gains could be realised by executing the send pipeline within Orchestration and sending the message from the Orchestration, i.e. an inline-send from Orchestration. The benefit of doing this would be to eliminate two Message Box publications and routings for each send to an MQ queue, the performance gains alone for not using delivery notifications were in the order of 45%, it was felt that the removal of a further message box publication and routing would yield an additional performance gain that would be significant.

 

For this to be possible a mechanism to execute the send side pipeline from within the Orchestration would be required, in addition, code would need to be written to transactional write a message to the MQ queue, which would have the same effect as using delivery notifications. One problem here is that there is no way out of the box to execute a pipeline from within an Orchestration in Biztalk Server 2004.  

 

Also to be noted is that the next version of Biztalk is currently planned to natively support execution of pipelines from within an Orchestration, thus meaning only a custom component to send the message to an MQ queue would need to be developed.

 

Posted on Wednesday, March 29, 2006 3:30 AM | Back to top


Comments on this post: BizTalk Server Performance Tuning

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Abhijeet Raje | Powered by: GeeksWithBlogs.net