Menu
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:
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.
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...
736
The best way to monitor the performance of your ASP.NET application is with an application performance management (APM) solution. Retrace tracks the performance of your application down to the code level and provides detailed reporting of ASP.NET application performance.
There can be numerous reasons why . NET applications can be slow. These include incorrect memory sizing, GC pauses, code-level errors, excessive logging of exceptions, high usage of synchronized blocks, IIS server bottlenecks, and so on.
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
102
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.
27
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
