Question

I need to measure the total time a page takes to fully load, from clicking a menu button to fully rendered. I did that, by using BeginRequest and EndRequest events. Because some numbers were too big, I started measuring the time for every method and event the page executed when loading. Using a stopwatch I timed Preinit, Init, Load etc, all the events in the page life cylcle plus all other methods I created. My surprise was that adding these numbers I didn’t even get close to the numbers I got using begin/end request. The last one was even double, triple, eg 7 seconds comparing with the 2 seconds I got from each event/methods.

So I’m wondering, where does this extra time come from? Between my timings, which are showed in the debug window, I could see all sort of “loading jhfggdfaasdf.dll”, probably some temporay file. Could this dll loading take this time?

I noticed that from time to time, my timings match, so maybe there is some cache mechanism, but I need some confirmation from someone more experienced.

Answer 1

EDIT: From reading your question again, you might be using the asp.net web site solution type. This is not pre compiled when you are debugging and the first time you request a page it compiles it into a class in your asp.net directory. The dll for the class is then loaded into the app domain with a funny name like the one you mentioned. This happens the first time you request one of these pages and when you want to deploy you can pre compile your site to increase performance.

If you are seeing “loading xyz.dll” it means the app domain is loading in stuff to be used by the application. This happens when you need to run code from required dlls (in your case probably third party libs) that have not yet been loaded into the app domain. This is good because it means a page that uses a library but has never been called, never loads that assembly into memory. You could move this hit from first page request to application load by pre loading all the assemblies in your bin into the app domain on application start. It is a trade off between use of memory against speed of requests. This question is a good place to start with that:

How to pre-load all deployed assemblies for an AppDomain

You can get a good overview of your page lifecycle times by using the trace functionality in asp.net. This can be set in the web.config file as described in this article:

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

Viewing the trace.axd page will tell you times off the various server events and make it really easy to see where you are slow.

If the page still takes a long time to render, there are client side considerations such as

• is your page very large
• are you interpreting javascript before all the html and css was written
• is your network slow
• are you sending many css and js files? most browsers limit the number of concurrent resource downloads. maybe consider rolling a few css files into one, on your production environment at least
• are you employing client cache. you can tell the browser to cache something for a period of time. there are ways to invalidate this cache if your content requires to be updated.

This can be debugged using client side tools such as firebug or the developer tools in chrome.