Most developers working with Microsoft BizTalk Server know that if you enable message body tracking it will severly impact your BizTalk performance. Typical numbers found online are around 30% impact on CPU but of course your mileage may vary. The impact will be visible on both the BizTalk SQL server and the BizTalk hosts.
"All tracking has an impact, even lightweight property tracking."
There are even companies dealing with BizTalk monitoring that claim that property tracking does not introduce any impact at all since this is functionality found in the BizTalk admin console. I think it is important for BizTalk devs to know that you can do a LOT of damage on performance from the admin console by running different queries on the BizTalk DBs, enabling functionality best used for debugging etc.
So, property tracking is more lightweight than message body tracking due to the amount of data being tracked. But still, if you run a lot of messages on your BizTalk we are talking about a lot of data that needs to be moved to the BizTalk tracking database. And the additional resources needed to move these data will for sure impact your low-latency messaging patterns or slow down other processes on your BizTalk server.
To verify what is really happening to performance, we tested this on two different setups:
Setup1: Single server setup, BizTalk server and SQL server on same machine
Setup2: Three server setup. Two BizTalk application servers, dedicated SQL server
Let's have a look on Setup 1 first.
We ran two different tests; one test with pipeline property tracking enabled, and then one test with no tracking (global tracking turned off). We ran around 120 messages per minute, each message is around 100KB. One single receiveport distributes the message to two different orchestrations and the messages are then sent out through four sendports. All messages use a flatfile pipeline for in / out. We then measured the highest average CPU for the sqlserv.exe process in both tests.
First screenshot shows average sqlserv.exe CPU average with pipeline tracking enabled.
Second screenshot below shows average sqlserv.exe CPU average with global tracking off.
So the testing on the single server environment shows that the SQL took quite a hit from enabling the property tracking on just pipelines.
To further verify the findings we ran the same test on the multi-server setup with a dedicated SQL server. Once again the sqlserv.exe was monitored for impact.
First test on the multi-server setup was run with property tracking enabled for pipelines, see screenshot below.
Then we ran the same test again without property tracking enabled for pipelines, see screenshot below.
Also on the multi-server setup there is a considerable performance hit from enabling the property tracking on the pipelines.
Keep in mind that it is not only the SQL that is impacted from enabling the property tracking. Also the hosts running these pipelines on the BizTalk servers will see a performance hit. Take a look at the host that is responsible for sending below, first out is with property tracking enabled.
Then we did the same exercise monitoring the sending host with property tracking disabled. Keep in mind that there are only 4 sendports using this specific pipeline.
All averages seen in these screenshots are the highest monitored from within 60 minutes, both with and without property tracking enabled.
So what to learn from this? ALL tracking has an impact, even the "lightweight" property tracking. It is important to know that the differences between tracking on / off would have been even higher if we had enabled property tracking for orchestrations etc. Also increasing the number of components tracked would have made a difference.
Keep ALL your tracking off unless you really need it, especially if you run a high throughput / low latency environment. Enable it only for debugging purposes or replicate your setup on another environment and enable tracking there. Tracking is a very nice feature but comes with a toll: performance impact.