Delivery Notification Performance

I'm over in Redmond currently for a couple of weeks working with the Biztalk Design Wins team doing some performance tuning on a solution for one of my customers, I’ve also been having a lot of fun catching up with my colleagues and friends from the product group, and hearing about some of the great work they are doing for future versions. During this work we have gotton some interesting data that I thought was worth sharing.

As you will have seen from one of my previous post’s, marking a port as Delivery Notification = Transmitted provides a great mechansm to allow an orchestrations to know whether a message was actually transmitted successfully as opposed to simply being successfully published to the message box. There is of course a performance cost for using delivery notifications this goes without saying. The reasons for the performance hit being two fold, firstly, the load on the engine and the message box will be increased since for every transmittion an ACK or NACK will be created, published and routed to the orchestration instance that transmitted the message. Secondly, the execution of the orchestation instance is serialized whilst the message is being transmited, of course, some of the cost of this serialized processing will be recovered by the additional concurrency from other orchestration instances running whilst a particular insance is dehydrated waiting for an ACK/NACK.

In general the cost of using delivery notifications is of course dependant on the design of the orchestrations and ports, but as a rought rule of thumb, the performance cost is around 50%, though for one scenario we did see that using delivery notification gave approaximately 30% the performance of the same solution not using them.