Base on the same transaction name (load runner) and timer name (dynaTrace).
We just exclusion some picture (like .jpg, .png, .gif) and .js .css.
We already instrumented all the load testing environment with dynatrace.
We capture 100% request.
All stress testing script and transaction are web request. So, all entry point app tier is instrumnetd to start purepath.
But, the result was so different :
> LoadRunner_Report_PassCount.jpg is the result and the pass count of transaction of Load runner. (Same period. And only this test run at this time).
> DT_LoadTestOverview_Count.jpg is the count of timer name in dynaTrace. (Same period. And only this test run at this time).
> dynaTrace Count result was smaller than Load runner pass count.
TX_13_ccBillResndAdvise Loadrunner_Count=75 DT_Count=21
TX_17_ebFoxExRatelng Loadrunner_Count=64 DT_Count=51
TX_18_csBonusPtlnflng Loadrunner_Count=120 DT_Count=16
How to let it be same ?
Do you have a cache server, proxy or a CDN or something like that between your load runner and the app? in that case it could be that some of the load runner transactions are simply served from your caching layer and never make it to the app. That could explain the difference
Another explanation could be if you have a cluster of application servers and you have not instrumented all of the application servers with dynatrace. in that case you would only get PurePaths for those requests hitting the instrumetned servers
I have the same issue and we have all the app servers instrumented with dynaTrace and there is no caching layer between app server and LR. So, I feel your answer is not enough. I strongly feel that dynaTrace is not good to analyze Load Runner transactions
One other thing that can be checked is whether all transaction are getting the Load Runner ID. For example, requests that has as entry points the Websphere Message Broker do not have the header modified by Load Runner Tag.
To confirm that, the PurePath dashlet can be used to filter all transaction at the desired time.