cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Response time analysis doesn't provide detailed breakdown

rfeiock
Newcomer

I am setting up Dynatrace for the first time, and as part of it, I am trying to diagnose an issue in our pre-prod environment. According to the Waterfall Analysis, there is a Document Request that is taking 94 seconds. When I click on Pure Path for the call, it shows "service execution" with two Top Findings, ASP.Net and IIS Internals (both showing 1.56 min). If I click on IIS Internals, it shows nothing. If I click on ASP.Net, it shows that 100% of the time is in ExecuteRequestHandler (screenshot attached). Is this expected behavior? Per the documentation, it shows that there should be a detailed breakdown of calls under the ASP.Net Modules, but I am not getting them. Is that due to a configuration error, or is that a result of the application being monitored?

7 REPLIES 7

dave_mauney
Dynatrace Champion
Dynatrace Champion

Hi Ryan,

I have seen similar behavior. I believe the ASP.NET time often will show up only under "ExecuteRequestHandler", but that seems to always be the end of the clue trail every time I have had this type of bottleneck.

Thanks,

dave

niklas_pederse1
Newcomer

I see the same at our side, did you figure something out?

rfeiock
Newcomer

Yeah, a while back, our application was encountering issues when Dynatrace was running and I was in a long troubleshooting session (multiple months) with Dynatrace support. Along the way, they flipped a number of switches in an attempt to isolate and troubleshoot the issue. Along the way, they set this flag for our managed instance on their side:

sampling.dotnet.enabled = false

And it was left that way. This was restricting a lot of data we should have been receiving from our applications.

In addition, it sounds like a recent policy change dictates that .Net Framework and .Net Core .dlls will not have the deep monitoring enabled by default, so that needs to be enabled manually. Once we had them change the above flag and enabled the monitoring on the handful of suspect .dlls, we started getting a lot more information.

waikeat_chan
DynaMight Pro
DynaMight Pro

Me too, it SEEMS like 'IIS Internal' not only has no code, but also somehow not being calculated into the response time? I see many such instances in my Managed Environment something like this (where the IIS Internal's time alone is way more than the response time):

Anyone also encountered this?

Saw that too , already asked about it https://answers.dynatrace.com/questions/203318/view.html with no answer till now 😞

Yos


dynatrace certificated professional - dynatrace primer partner - Matrix Soft Ware Division - Israel

rpichardo
Inactive

hi there,

we also have this same issues. we also noticed the framework version for .NET is 3.5 can this be an issue of this version? could it be that newer versions of .NET can will show detailed info?

just asking... i cannot find any info about what framework version is supported to give this detailed info about IIS Internals.

RKPO


.NET 3.5 is still supported (you can find it here: https://www.dynatrace.com/support/help/technology-support/supported-versions-and-environments/which-...). It also has CPU Sampling technology enabled, so you should see method hotspots for .NET.

As to the "IIS Internals". This usually is the time a request is processing/waiting in IIS, before it is actually picked up by a CLR thread to be processed. In my experience this time is usually spent if all .NET thread pools threads are busy and IIS needs to wait for them. Of course the reason could as well be another native IIS module consuming time.