4

内置的 Sitecore 渲染统计信息http://<sitename>/sitecore/admin/stats.aspx对于识别低效且加载缓慢的 XSLT 渲染非常有帮助。最近，我开始切换到 .ascx 子布局，以利用 Sitecore C# API，如果正确使用它可以帮助提高性能。

但是，我注意到子布局（与 XSLT 渲染相反）在统计信息页面上没有正确报告。请看下面的截图......

示例子布局统计信息

我知道这个子布局大约需要1.8 秒才能生成（我在代码隐藏中计算了这个）。缓存已关闭。我已刷新页面 20 次以确保获得平均值。您会看到“平均项目”始终为 0——我可以忍受——但“平均时间（毫秒）”小于 1 毫秒，这显然是错误的。

有没有人对此有任何见解？有没有人找到让它正常工作的方法？

4

1 回答 1

3

Judging whether a statistic is right/wrong is going to rely on understanding exactly what it is measuring.

Digging around in Sitecore.Diagnostics.Statistics using Reflector I note the following:

  • Sitecore.Web.UI.Webcontrol contains a field m_timer
  • This is 'started' in the BeforeRender() method and 'stopped' in the AfterRender() method
  • Data from that timer is sent to Statistics.AddRenderingData() and is logged against the control

This means it is measuring the time taken to render the control, which for an XSLT includes the processing time for preparing all the data in it, but as much of the work of a normal ASCX is done prior to the Render-stage the statistic is much less useful. Incorporating the Load stage in the time would inadvertently include the processing time for all child components, since the Load sequence is chained and called recursively, so that probably doesn't help much either.

I suspect there is no good way of measuring the processing time for a specific ASCX control (excluding children) without first acquiring cumulative data then post-processing the call chain and splitting the time apart. This is the sort of thing RedGate ANTS does really well, but might not be so good if it was being executed on a live production system, given the overheads.

于 2013-05-10T02:41:00.663 回答