Slow ASP.NET app load times - Can I track/trace/time the whole load cycle?

Question

The ASP.NET web app project I'm currently working on is getting slower over time to re-load (In IIS or the .NET dev server). Currently it takes:

• 1:28 minutes to load via an F5 debug
• 41 seconds to refresh in browser, after a build (not rebuild)

The machine's reasonably fast - A Core 2 Quad 2.40ghz, 8 gig o' RAM, running the dev machine under HyperV with 2 gig o' RAM allocated to the dev VM.

Is there a way to trace / report on the the entire cycle of that initial load? If I could see how long it takes the basic IIS worker process to start, load DLLs, run the actual .NET code, that'd be great.

I know I can use a profiler on the code - which hasn't turned up any ultra-slow DB connection establishment times, but I'd like to have some insight on the performance of the stuff before the actual page is processed. I can see the CPU monitor hit 100% for a bit in the middle of the process, RAM usage jump a little - but am looking for better insight to hopefully trim things a little.

Though I didn't take any measurements at the start of the project (4 months ago), I'm entirely certain the reload was a relative breeze.

Any help much appreciated, Programmer-who-can-only-drink-so-much-coffee-while-a-build-occurs.

Update:

JetBrain's dotTrace was excellent (for this instance), thanks. It had the perfect interface to start a web project, and quickly highlighted that most of the time was being taken in Application_Start() (in Global.asax).

The other options wouldn't have picked this up, as:

• The Trace option only starts from PreInit, missing the Application_Start() call.

• The StopWatch calls would have required me to know where to look, or revert to the good old days of printf-style debugging...

• nprof wants to target a .exe, which would miss the target area when trying to attach to fresh w3wp.exe instances...

Answer 1

Why not use ASP.NET Trace functionality. Use trace.axd for analyzing the requests.

This might be of use:

http://msdn.microsoft.com/en-us/library/ms972204.aspx

http://msdn.microsoft.com/en-us/library/wwh16c6c.aspx

Answer 2

A profiler like JetBrains dotTrace should tell you where your bottleneck is... if you don't see anything out of the ordinary (ie. long process times on a method) then it's not your application. It must be the environment. It could be if you are using Active Directory and the call to Active Directory is hanging... Is there a web service call? Are you using Team Systems?Are there postbuild processes?

To me it sounds like something is timing out. That's why you are waiting so long.