捕获没有网络延迟的 ASP.Net 服务器执行时间
我需要捕获 ASP.net 在我的应用程序中执行每个页面请求所花费的时间，但我需要排除任何网络延迟。我目前正在使用 StopWatch 类捕获渲染时间，并在页面生命周期的 OnInit 方法期间启动秒表，并在 Unload 方法完成后停止它。 Unload 方法似乎包括将请求发送到客户端所需的时间，因此包括任何互联网/网络延迟。我可以停止页面生命周期中秒表的最后一个可能的点是什么，其中不包括将请求发送到客户端所需的时间。是在 Unload 事件之前吗？
相关问题：ASP.net 在开始发送到客户端之前是否完成了响应的构建？或者它是否在形成响应时开始异步发送？
我目前正在使用 ASP.Net 2.0 和 IIS 5。
我的所有页面都继承自一个类，其中包含此代码：
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
我尝试捕获 OnRender 方法结束时、OnUnload 方法开始时和 OnUnload 方法结束时的执行时间OnUnload 方法。在所有三种情况下，时间差异最多为 1 毫秒。即使从欧洲的客户端到美国的服务器进行测试，时间也是相同的。所以我认为我在这里遗漏了一些东西。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果 Response.BufferOutput 设置为 true，则 .Net 将等到页面处理完成后再将 html 发送回客户端。
如果为 false，则 .Net 会尽快开始发回数据。
Response.Flush 通常会刷新缓冲区。
我见过的在忽略延迟的情况下测试站点性能的最佳方法是让发出请求的计算机与服务器位于同一网段上。通常插入同一路由器/交换机。到那时，您将把延迟降低得足够低，以至于它只是您计算的一小部分。请注意，您不想直接在服务器本身上进行测试，因为这会导致处理时间被分开来运行客户端。
更新（来自评论）
这比评论长一点。
乔恩，您确定您还没有消除延迟这个因素吗？为了检测到它，您必须确保在运行每个测试之前清除本地 Web 缓存和 DNS 缓存。如果所有这些都被缓存并且剩余的数据量非常小，那么服务器所在的位置不会产生太大的影响。假设页面的不可缓存部分只有 4KB。您不会注意到 2MB 连接与 ISDN 线路在页面速度方面有太大差异。
您可以检查这个问题以了解如何测试各种延迟级别。我知道您希望消除所有延迟这一因素，但您可能会考虑从不同的角度来解决这个问题。即，检查高延迟和低延迟连接之间的差异。这应该为您提供相当多的信息，以便从您真正想要的值中提取出这些时间。
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.
只需打开 ASP.NET 跟踪： http://msdn.microsoft.com/en -us/library/ms972204.aspx
它显示每个方法和整个页面的执行时间。
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.
IIS 日志文件包含处理请求所花费的时间。这将包括调用 .Net 所需的任何时间，而您的方法不会记录这些时间。
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.