Long hand off between Web Server to CLR?
We are seeing some strange behavior on some of web page responses. A lot of our purepaths are indicating a long time between Web Server and the CLR.
Is there any way to tell what is happening in-between the arrows below? In the example it is a total of 6 seconds. I'm assuming its the handoff between IIS and the CLR... just a guess.
Hi Scott
I just worked on this with a customer that also runs ASP.NET There are different thread pools involved when IIS handles requests and forwards them to ASP.NET. When these requests are pooled between IIS and ASP.NET they show up as time spent on IIS just like in your screenshot. Here is a link to a blog post that I found on this: http://blog.leansentry.com/2013/07/all-about-iis-asp-net-request-queues/
What I suggest is to monitor these windows performance counters to see whether requests are being queued giving an indication of either overloaded IIS or incorrectly configured IIS/ASP.NET Worker Processes:
- Requests current
- Requests Queued
- Requests Executing (APS.NET)
- Requests Executing (APS.NET Apps v4.0.30319)
Another explanation is that you have native modules in IIS, e.g: authentication handling, URL Rewrite, ... -> these modules are executed as part of the request in IIS. As they are native we dont see "into" them and therefore show the time as I/O spent on IS.
I hope this helps
We've seen similar issues where requests were longer-running than expected and the time was spent pre-CLR, so the extent of the information provided by dynaTrace was "not code in the CLR".
In these cases, we enabled Failed Request Tracing (FRT) to identify where in the IIS pipeline the time was being spent. (The FRT name is a misnomer; it can trace any request, e.g., long-running requests.)
From what I recall, the guilty party responsible for our mystery latency was an IIS auth module.
If you haven't tried it yet, it might help.
Thanks for the response Andreas and Adam. We're still battling this problem and can't seem to gather much info. Even during low traffic periods, we see the same issue. For example, this one PP I'm looking at shows 15.4sec in IIS, and 2.69msec in CLR. None of the perfmon metrics are showing any kind of blocking or stacking up in queues.
I added some extra tracking to modules (see picture below) and it doesn't seem to show any indication that its slowness in the IIS module section. The PP even indicates that the module execution is done inside the CLR.
Does anyone with IIS and .NET have this issue? Our developers are asking a lot of questions as to what this means.. and I'm not sure how to answer it.
Scott, if you attach an FRT log corresponding to one of the long-running requests and the associated PP, I'd be happy to take a look. No promises!
Does anyone have additional insight as to why so much time is spent on the Web Server tier? I am seeing the same issue and there are no queues backed up on IIS or ASP.NET.
I also enabled FRT on one of my IIS servers and there is no significant amount of time spent in IIS either.
Hi Melanie
any luck with issue? i got a similar one and trying to find out the root cause for the time spent between web server agent and .net server and these agents are on the same server. any suggestion is appreciated,thanks
