This was a demonstration of how to optimize BizTalk 2010 (most of this also applies to BizTalk 2009). A baseline of performance in messages per second was recorded with the BizTalk Benchmark Wizard.
First steps should be to read the BizTalk Performance Optimization Guide and use the Best Practices Analyzer.
BizTalk relies heavily on SQL Server for performance, and SQL Server relies heavily on storage for performance.
Tweaks specific to SQL to optimize performance for BizTalk:
- PFS contention can impact performance. Split specific data files to multiple data files, one per processor core up to a maximum of 8.
- Locate file allocation groups to use different disk volumes
- Tune tempdb, and split it between multiple files (again one per processor core up to a maximum of 8). If these can be split on different volumes, do it.
- Set the T1118 trace flag
- Set Text In Row table option at 7000 bytes for specific tables. This will allow any record smaller than 7K to use it’s own data page rather than put multiple rows in the same 8K data page.
- Do the other disk optimizations for SQL as outlined in my optimal SQL storage post.
- Make sure virus scanners are not scanning database and log files.
- Verify the SQL Agent is running. There are jobs that need to run to keep the databases healthy.
- Do not create additional message box databases. This does not increase performance and creates additional overhead.
- For file adapters, watch for maximum connections reached on file shares
- Is message tracking on? This should be disabled for a production system unless tracing a production issue.
- Polling interval should be set in the host. Raise it for higher throughput, lower it for lower response time. In BizTalk 2009 this could only be set at the farm level.
- Tune orchestration dehydrations per the performance guide
- Keep orchestration state as small and local as possible, and remove unneeded context properties. Eliminate persistence points when possible.
0 comments:
Post a Comment