我在 MasterPage 构造函数中创建一个秒表并启动它。我在 PreRender 中更新了一个标签以显示服务器端渲染时间。 （我在客户端设置了 javascript 计时器，是的，与服务器端渲染相比，客户端渲染是巨大的——但是我可以对服务器端时间做更多的事情，如果它很高的话）
我在 MasterPage 中有计时器，以便在需要写入毫秒数时访问标签。
与我在 Page 构造函数上设置计时器并在 Page Unload 事件上将时间写入控制台时相比，时间始终要短得多。
那么是什么解释了这一切呢？我是否需要将计时器的开始/停止移动到不同的事件？从页面构建到页面卸载的覆盖时间是否不应计入在服务器上呈现该页面所需的时间？
【问题讨论】：
标签： asp.net performance
当您在主/页面构造函数中启动 Stopwatch 并在 Unload 上完成它时，这意味着您正在测量页面生命周期的时间，我很难同意这是渲染（但是是的，它包括渲染），因为在页面生命周期中循环你可以调用数据库/服务/其他东西到Thread.Sleep()。
如果我们将“页面呈现”视为控件向Response.OutputStream 写入数据的时间，那么我们应该采取其他方法。在ASP.NET Page Life Cycle Overview 之后的页面渲染在第一个Render 方法被调用时开始，在逻辑上它在最后一个Render 方法被调用时结束。
在渲染之前，会保存页面和所有控件的视图状态。 在渲染阶段，页面为每个页面调用 Render 方法 控件，提供一个文本编写器，将其输出写入 页面的 Response 属性的 OutputStream 对象。
在我看来，要衡量页面生命周期的渲染部分，最好在页面的重写 Render 方法中启动和完成秒表。
protected override void Render(HtmlTextWriter writer)
{
var stopwatch = Stopwatch.StartNew();
base.Render(writer);
stopwatch.Stop();
// Set the value of rendering time in Page.Master
}
再一次，为什么是Render？来自 ASP.NET 页面生命周期概述：
渲染：这不是一个事件；相反，在这个处理阶段， Page 对象在每个控件上调用此方法。所有 ASP.NET 网络 服务器控件有一个 Render 方法，可以写出控件的 标记发送到浏览器。
但无论如何，我不确定您为什么要手动测量。如果跟踪是enabled，那么您可以通过trace.axd 评估页面事件持续时间，如果您在配置中启用了pageOutput，则可以直接在页面上评估。
【讨论】：
Global.asax 中拦截BeginRequest 和EndRequest 事件，并写下响应时间。发现以前有人问过这样的问题，看看stackoverflow.com/questions/2962554/…。