15 Jan 2025 03:39 PM
Hello everyone.
I am trying to expand my understanding in the process so I wanted to pose this question to the community.
I have a group of DBA’s that are somewhat “dismissive” of the information Dynatrace one agent provides when it
comes to the response times shown for applications making DB calls.
Look at the instance below.
In the example below, we see 5 DB calls. 4 being made relatively quickly.
The middle call however, can take up to 5 seconds to complete.
When shows this information, the standard response from the DBA’s I receive is. “That’s all time on the network”
Based on my limited understanding of the OneAgent, it could be network time as well as DB processing time. However I would raise the question in response : “Then why aren’t the other calls seeing similar slow times immediately before and after it. “
So my question to the community is… how does the Dynatrace OneAgent actually determine the time that was spent on that call?
Does the 5 second instance below include both network travel time as well as DBA processing time?
How does Dynatrace determine this value?
Thank you!
-C
Solved! Go to Solution.
15 Jan 2025 03:57 PM
To make it easy, Dynatrace treats Databases as external services.
When your application starts the interaction with the database (select, update, etc) the trace has an initial time.
When your application receives the results from the database, you have the final time.
The network time is included because the oneagent only knows about starting and end time of the transaction.
16 Jan 2025 12:17 PM
Paco already summed it up nicely. I think it should be common sense for most people that if one DB statement always takes 5 seconds to complete and the other ones just some milliseconds, I don't see how anyone can argue that the "slow network" always happens to affect just that single call and not the others? Again, assuming that the above behavior is constant and not a one-off.
16 Jan 2025 05:38 PM
To add further information to the "discussion" with the DBAs you could chart that SQL Request to show that it's consistently taking a long time.
16 Jan 2025 09:50 PM
We've had these conversations internally as well. It's not 100% accurate to say it's ALL spent in network time...this is total round trip time from your client application to/from the database so will also include the DB's query execution time.
When comparing the response time in Dynatrace vs the actual execution time, it's also important to account for how much data is being transferred across the network. If this one query returns a huge amount of data it could explain why they would think it's all in the network.
17 Jan 2025 01:23 PM
I have to thank all of you for such complementing suggestions. Collectively, they make a really compelling argument
as to why the data is useful to the DBA's.
Thank you again!