Does dynaTrace IIS Agent do any ASP.NET Session State Locking?
Hello,
I have a general question regarding how dynaTrace web server agent interacts with ASP.NET session state.
First off, we only have dynaTrace web server agents installed on our web front end servers (no .NET agents).
Recently, we have had several users complain about performance on our web application.
What we have observed through dT is that a user would be interacting with our application seamlessly, when all of a sudden, they click on a page and the the request just hangs there.
This behavior has been observed on many different pages, not a specific page.
What we can see from dT and also from our home grown response time measurement tool is that these requests are taking 2+ hours to complete. From the user's perspective, they've already gotten the system time out page.
From what we understand about session state is that it will only allow one request to access it at a time. So if some request has a lock on session state that is taking 2 hours, all other requests will have to wait until the first request releases the lock. What we are trying to rule out here is if the dT web server agent does any read or write lock on ASP.NET session state.
What is also interesting is that right before each 2 hour long request, there is always an HTTP 500 Internal Server error that dT captures BUT does not show up anywhere on our IIS logs. We have configured IIS to capture every request so I can't understand why the 500 is only showing up in dT and not on our IIS logs.
1. If IIS isn't logging the 500, then how is dT able to capture the 500?
2. Does the dT web server agent do any read or write lock on ASP.NET session state?
Hi Melanie
We see this quite often that time is spent in IIS. What that actually means is that it is spent in one of the other native modules that you have in IIS. Unfortunately we do not see into these native modules as we cant instrument the code. In that case I would look at log outputs from these modules that you use - contact these vendors on any additional performance information these modules provide and check whether there are any windows performance counters that might help here to analyze what is going on.
If you need help in figuring out how to use dynaTrace to analyze problems I suggest to look into the educational material we have on the community as well as on APM University. Click on Education and go from there.
We also offer professional services that can help you as well. Here I would reach out to your sales rep
Thanks for your reply Christoph.
I did go ahead and add a .NET agent to one of our web servers. The issue is that the PurePath times out after 1 hour, even though I changed the timeout in the dtserver.ini file to 3 hours. So I don't see anything useful in my PurePath tree.
I think that all the time is being spent on the IIS tier, and not the .NET layer. Does dT have any sensor packs that can help me diagnose what IIS is doing?
For the purepaths where I get an HTTP 500 error, I currently have no indication to why the server threw the 500 error. Can dT help diagnose this?
Hi Melanie,
1. That's an interesting case. Maybe they are somehow excluded in the IIS log? Adding the .NET agent to your system would give you more insight on why these errors occur.
2. The dT web server agent does not do any ASP.NET session state locking. In fact it does not access the session state at all. The .NET agent on the other hand has the capability to capture session state variables and therefore does an iteration on these values if necessary. However, it accesses the collection optimistically, no locking is done. According to this page [0], session state locking is usually done via the "EnableSessionState" attribute on a Page. Maybe setting EnableSessionState="ReadOnly", if applicable, would ease your issue.
In order to find the root cause of your problem I would suggest:
# Add the .NET agent to your system. When the 2+ hour request happen, AutoSensors will show you where these requests are blocking.
# Run a dT-CPU sampling (.NET agent presumed) and see where your threads are spending most of their time. A CPU sampling is not transaction-bound, so you can also see threads that did not start transactions (maybe one of them is blocking in any way).
Best regards,
Christoph
