Measuring Page Execution Times for ASP.NET Pages

Measuring Page Execution Times for ASP.NET Pages

Abstract - (Technical Article) Someone asked me about the page execution time shown at the bottom of this (and every) page. So I thought I would post an article on how to incorporate a page execution timer in your own ASP.NET pages. It’s fairly simple but requires an understanding of the ASP.NET page life cycle. (Dominic Pettifer)

Monday 27th November 2006 - 7:57pm

Understanding the Page Lifecycle

It measures the time taken to render this page to HTML, this includes all back end database access stuff, any user or server controls and their own database access, and data binding of web controls. Also the processing of any client side button clicks or other UI interaction and the server side code that fires in response to those events. Basically almost everything.

The ASP.NET page life cycle goes through several stages before HTML is rendered and sent to the client. First the Page.Init event is fired, all controls are initialised and have their default values set. After this the Page.Load event fires, this is where most developers put their code and do data access and data binding etc. Following this all other user or server controls are fired and go through their own lifecycle Init and Load events. Control events are then fired from UI interaction (eg. Button clicks, change events from selecting an item in a drop down list etc.). Then the Page.PreRender event fires, the last place we can make changes to control values. Finally the Page.Unload event is fired after everything gets rendered ready to be sent to the client, we use this for cleanup operations.

There are a few more that fire in between these, to do with Viewstate for instance, but a full explanation of how the ASP.NET page lifecycle works on beyond the scope of this article. Interested parties might want to look at an ASP.NET Page Lifecycle article from the Code Project.

Measuring Page Execution Times

The trick to accurately measure the page execution speed, is to start the timer as early as possible, and stop and record the time as late as possible in the page lifecycle. The earliest we can start the timer is in the Page.Init event, like so...

private int startTime;

protected void Page_Init(object sender, EventArgs e)

{

    startTime = Environment.TickCount;

}

We use the Environment class to retrieve the tick count (found in System namespace). The Tick Count is the number milliseconds that have passed since the web server computer was first switched on.

Now we need to get the end time as late as possible, so we can ensure everything else has been carried out (data access, binding, control events etc.). So we get the time in the Page.PreRender event like so...

protected void Page_PreRender(object sender, EventArgs e)

{

    int endTime = Environment.TickCount;

    double executionTime = (double)(endTime - startTime) / 1000.0;

    lblLabel.Text =

        "Page Execution time is " + executionTime + " seconds.";

}

We subtract the start time from the end time and divide by 1000 to get the execution time in seconds, as opposed to in milliseconds. We then assign the time to a label control, or any other control, somewhere in the page.

The reason we use the Page.PreRender event is because this is the last time we will have access to the page controls, before they are rendered to the page. We need to display the execution time on the page after all. You could possibly record the time in the Page.Unload event if you were recording the times into a database for instance, but by the time we reach this stage all HTML mark up has been rendered and we can't set anything any more.

Master Pages?

When using Master pages, the page events fire in the following order...

Page_Init in Master
Page_Init in Default.aspx
Page_Load in Default.aspx
Page_Load in Master
Page_PreRender in Default.aspx
Page_PreRender in Master

Therefore you can start and stop the timer in the Page.Init and Page.PreRender events for the Master page, and assign the result to a control on the Master page. This is handy in that it saves you rewriting the same boiler plate code for all your ASPX pages.

Conclusion

Page execution times are useful for developers wanting to optimise the performance of their aspx pages, as they provide a way to measure the difference in execution speed of the web application as they make those optimisations.