I didn't take any notes, but will write a short recap of the things that I remember the best from this evening. Some parts that I knew of, and some that I will explore further in some labs. So, here we go: BizTalk performance best practices:
- Plan your SQL storage
This is an entire bookshelf of information on its own and something that most of the BizTalk developers won't get in touch with. However, it is very crucial for the overall performance of the platform and time and money should be spent here. Arranging LUNs, RAID arrays and similar hardware configurations are the base. It is also quite possible to increase performance by splitting the datafiles to several files and filegroups as described in the following links: http://msdn.microsoft.com/en-us/library/ee377060%28BTS.10%29.aspx
- Optimize SQL Server settings
As the backbone of BizTalk, SQL Server optimizations is a way to gain performance boosts. The most prominent example from yesterdays session was enabling the T1118 flag. The only downside seems to be a possible increase in physical data allocation. http://support.microsoft.com/kb/328551
- Turn off antivirus
A risky move for some and might not play well with company policies. However, antivirus will eat a lot of the processing power and speed available.
- Use XslCompiledTransform for maps
The current implementation of the mapping engine in BizTalk uses the old and deprecated XslTransform class. By wrapping calls to XslCompiledTransform instead, a very noticable performance increase can be seen. At the session, about 2/3 of the execution time was removed from the first call to a map using a ~35MB XML file. The gain is made both for small files as well as larger ones. http://blogs.msdn.com/paolos/archive/2010/04/08/how-to-boost-message-transformations-using-the-xslcompiledtransform-class-extended.aspx
- Optimize the WCF endpoint bindings
This was covered in some part, but I'll take a different but short approach on the subject. Default is to fetch data in a buffered transfermode which enables the WCF message security and reliability. However, if performance is needed, examine using the streamed transfermode instead. On larger messages, this will have impact.
Changing message encoding can also give a performance boost. Default is text encoding which with binary attachments/messages will result in a base-64 encoding and an increase in message size. MTOM or binary encoding will solve this.
It is also interesting to look at the actual binding since NET.TCP can utilize binary encoding and also has the best performance. The penalty is severe though since it's both not interoperable and can be useless due to network restrictions.
- Watch those persistance points
If you have more complex orchestrations, take a look at optimizing the number of persistance points. I have orchestrations that can make up to thirty calls to external services. Each of these calls will result in a persistance point. I don't need to keep state and transactions in them, so by wrapping everything in an atomic scope, the number of writes to the database is vastly reduced. Sanket has a good explanation of persistance points on his blog: http://blogs.msdn.com/sanket/archive/2006/11/12/understanding-persistence-points-in-biztalk-orchestration.aspx