I just spent a couple of hours working with another developer on a weird request latency problem in certain ASP.NET requests. We've got an aspx page with a number of images that are themselves fetched via an aspx page (because they are being pulled out of the DB). When looking at the timeline for these requests in Chrome, most of them would complete quite quickly (less than 200 ms) but typically there were 2 that took much longer; one usually around 1 sec, and then other usually around 500 ms. We already had logging in place that was measuring the time from BeginRequest() to EndRequest(), and the logs showed a consistent processing time for all of the image requests, even the two that were taking much longer to get back the browser.
So, we added a bunch more logging so that we could timestamp each step in the ASP.NET pipeline. This allowed us to pinpoint that the extra time was being taken between PostMapRequestHandler() and AcquireRequestState(). A little searching on the net led us to this article which suggested that the problem was blocking due to the need to obtain a lock on session state. We use session state in a couple of places, so it is enabled throughout the application. However, in most places, including the code for fetching images from the DB, it is not used. So we changed the @Page directive on the image grabbing page so that EnableSessionState was set to ReadOnly.
Voila! All the image fetching requests now took roughly the same time.
To be fair, Microsoft's documentation on session state actually warns you of this issue. And in general, I'm not a big fan of using session state anyways. Nonetheless, I was a little surprised that pages that don't actually use session state can end up having their performance degraded just because sessions state is being used at all.