When the BizTalk Best Practice Analyzer starts it tries to connect to the internet to get an update of the latest best practices. However, quite often servers do not have a direct internet connection. This will result in the following error:

 
Within time this will leave you with a BizTalk Best Practice Analyzer that uses outdated best practices.

Have you ever wanted to evaluate the performance of your Biztalk installation?
Evaluating your performance could be done by analyzing quite some counters in the performance monitor of Windows. Or maybe by using the Performance Analysis of Logs (PAL) Tool.

However I just found a recently released tool to benchmark your biztalk environments.
The tool is called blogical and can be found on codeplexe here.

One of the responsibilities of a BizTalk admin is to ensure that BizTalk performs according to business requirements. One of the aspects that can impact performance is hyper-threading. Hyper-threading is a technology that makes the server appear to have more processor cores than it actually has. It seems logical that more cores will give the server a better performance. However, it is not as simple as it seems. Some applications suffer from performance loss when hyper-threading is enabled. BizTalk Server is among the applications which encounter performance loss from hyper-threading. The Microsoft document “General Guidelines for Improving Operating System Performance” states that the overall performance will decrease when hyper-threading is enabled. This is because of the self-tuning algorithms within BizTalk (for more information see: http://msdn.microsoft.com/en-us/library/ee377075.aspx).

Here are some best practices tips on the usage of tracking for Biztalk:

• Determine the information you need to track during planning : You should decide during the planning stages which information you need to track, so that after you deploy the project you can set the tracking options and limit the amount of tracked data to give you only the information you need.
• Do not track all messages: We recommend that you not track all messages, because each time a message is touched, BizTalk Server makes another copy. You can instead narrow the scope by tracking only a specific port. This helps to maximize the performance of your system and to keep the databases uncluttered.
• Set tracking on send ports and receive ports instead of on a pipeline: If you set tracking options on pipelines, you will also set the tracking options globally for every port that uses the pipeline. This in turn may result in far more data being tracked than you intend, which will slow system performance. Instead, you can set tracking options on send ports and receive ports.
• Take into account various factors when you size the BizTalk Tracking database:
  • When sizing the BizTalk Tracking database, account for SQL Server factors, such as index size, by adding a contingency multiplier to your calculations.
  • When determining the size of messages in the BizTalk Tracking database, add the average size of the message context to the message size if it is significant compared to the message size.
  • To limit the size of messages in the BizTalk Tracking database, limit the number of properties that you promote. You should only use promoted properties if you need them for routing purposes, otherwise use distinguished fields.
  • If the orchestration Shape start and end option is enabled, take into account that a start and stop event for each shape in each orchestration instance is saved in the BizTalk Tracking database.

Also some additional best practices tips for message and instance data tracking can be found on http://technet.microsoft.com/en-us/library/aa559344.aspx