2

I need to capture the amount of time that ASP.net takes to execute each page request in my application, but I need to exclude any network latency. I am currently capturing render times by using the StopWatch class and starting the stopwatch during the OnInit method of the page lifecycle and stopping it after the Unload method completes. It seems that the Unload method includes the time it takes send the request to the client, thus including any internet/network latency. What is the last possible point I could stop the stopwatch in the Page Life Cycle that would not include the time it takes to send the request to the client. Would it be directly before the Unload event?

Related question: Does ASP.net finish building the response before it starts sending to the client? Or does it start sending asynchronously, while the response is being formed?

I am using ASP.Net 2.0 with IIS 5 currently.

I have this code in a class that all of my pages inherit from:

readonly Stopwatch _serverExecutionTime = new Stopwatch();

protected override void OnInit(EventArgs e)
{
    _serverExecutionTime.Start();
    base.OnInit(e);
}    

protected override void OnUnload(EventArgs e)
{
    _serverExecutionTime.Stop();
    base.OnUnload(e);
}

UPDATE

I tried capturing the execution time at the end of the OnRender method, at the start of the OnUnload method and at the end of the OnUnload method. In all three cases the difference in times was at most 1 millisecond. Even when testing this from a client in Europe to a server in the USA, the times were identical. So I think that I am missing something here.

Jon
  • 2,129
  • 7
  • 23
  • 31

3 Answers3

1

If Response.BufferOutput is set to true, then .Net will wait until page processing is complete prior to emitting the html back to the client.

If it's false, then .Net starts sending data back as soon as it can.

Response.Flush will, usually, flush the buffer.

The best way I've seen to test site performance while ignoring latency is to have the machine that is making the request on the same network segment as the server. Usually plugged into the same router/switch. At that point you will have dropped latency down far enough that it will just be a tiny portion of your calculations. Note that you don't want to test directly on the server itself, as that causes processing time to be split off to run your client.

UPDATE (from comments)
This was a little longer than a comment.

Jon, Are you sure you haven't already eliminated latency as a factor? In order to detect it you'll have to make sure your local web cache and DNS cache are cleared prior to running each test. If all of that is cached and the amount of data remaining is pretty small, then it's not going to really make much of a difference where the server is. Let's say the non-cacheable part of the page is only 4KB. You wouldn't notice much difference between a 2MB connection versus a ISDN line in page speed.

You might check this question to see how to test various latency levels. I know you want to eliminate all latency as a factor, but you might consider attacking this from a different perspective. Namely, checking the difference between a high latency and a low latency connection. That should give you a fair amount of information in order to factor out those times from the values you really want.

Community
  • 1
  • 1
NotMe
  • 87,343
  • 27
  • 171
  • 245
  • I agree with about making the request on the same network segment. But as far as my code example is concerned, is the best place to capture the time before base.OnUnload? – Jon Nov 19 '10 at 18:54
  • @Jon: I would test it at the beginning of the unload event OR at the end of the Render event. – NotMe Nov 19 '10 at 20:16
  • I tried to capture the value before and after the unload event. Both times were almost identical even from servers in the US and UK. At most the times were 1 millisecond apart. Unfortunately this does not help me. Do you have any other ideas? – Jon Nov 22 '10 at 14:11
0

Just turn on ASP.NET Tracing: http://msdn.microsoft.com/en-us/library/ms972204.aspx It shows execution time on each method and for the whole page.

DarrellNorton
  • 3,901
  • 2
  • 21
  • 21
  • I know I can use trace, but I need to physically capture the execution times for my production site. I will be logging them to the database. I cannot use tracing in my production environment. – Jon Nov 19 '10 at 20:00
0

The IIS log file has the time spent processing the request. That would include any time needed to call .Net which your method wouldn't record.

David
  • 34,223
  • 3
  • 62
  • 80
  • Thanks, but I actually want to exclude a portion of the time. I want to eliminate all of the possible network latency. – Jon Nov 19 '10 at 21:07