1

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.

Justin
  • 84,773
  • 49
  • 224
  • 367
Nial
  • 321
  • 1
  • 5
  • 13

2 Answers2

2

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.

Community
  • 1
  • 1
Peter Short
  • 762
  • 6
  • 17
  • please let me know if this helped, if its not the answer it would be good to know why :) – Peter Short Aug 31 '11 at 23:03
  • Indeed, the website uses a lot of dll's. Around 50 and plenty of JavaScripts and CSS files. I will investigate if any of the javascript cause any bottlenecks. Fortunately, this doesn't happen too often, most of the time the speed is good. Like, one big duration for a customer and then everything goes back to normal, like a spike. So I'm considering, either this happens after a IIS reset, recycle or something similar or temporary network problems. Does the start/end request also count the time needed to send the page to the client's browsers? – Nial Sep 02 '11 at 07:24
  • Yes, the start and end request events are done on the server so the client will still be waiting but these events are really quite fast. What you are describing sound like just in time compilation so maybe you should look at pre compiling your website. If its not a dll loading thing then tracing will help you narrow your search to see where the slow code is. – Peter Short Sep 02 '11 at 10:21
  • I will update the answer with some expansion on more client side considerations as well – Peter Short Sep 02 '11 at 10:22
0

The stopwatch is actually a fairly cumbersome object by itself. You may actually be adding to the load time by using it to record the time. A slightly more efficient method would be to use a simple datetime comparison.

protected void Pre_Init(object sender, EventArgs e)
    DateTime started = DateTime.Now;

    // .... some code

    lblDisplayComment.Text = DateTime.Now.Subtract(started).TotalMilliseconds.ToString();
}

This would give you the time in ms it took to execute that method only.

Joel Etherton
  • 37,325
  • 10
  • 89
  • 104