内置的Sitecore渲染统计信息http://<sitename>/sitecore/admin/stats.aspx对于识别效率低下且缓慢加载的XSLT渲染真的很有帮助。最近我已经开始切换到.ascx子布局，以利用Sitecore C＃API，它可以在正确使用时帮助提高性能。Sitecore的sublayout呈现统计信息是否不正确？
不过，我已经注意到，子布局（而不是XSLT渲染）未在统计页面上正确的报道。请参阅下面的屏幕截图....
我知道一个事实，这个子布局约需1.8秒生成（我在后台代码计算此）。缓存已关闭。我已经刷新了该页面20次，以确保我获得平均水平。你会看到，“平均项目。”始终是0 - 我可以这样生活 - 但“平均时间（毫秒）。”是小于1ms这仅仅是明显错误的。
没有人有任何见解呢？有没有人找到一种方法让它正常工作？
来看一个统计值是否正确/错误是要依靠理解它到底是什么测量。
使用反射我注意以下掘Sitecore.Diagnostics.Statistics各地：
这意味着它是measuri纳克采取的时间呈现控制，这对于一个XSLT包括用于在其制备中的所有数据的处理时间，但作为多正常ASCX的工作之前渲染阶段完成的统计量是少得多有用。在时间中加入Load阶段将无意中包含所有子组件的处理时间，因为Load序列是链式递归调用的，所以可能也没有多大帮助。
我怀疑有测量处理时间为特定ASCX控制（不包括儿童），而不第一获取累积数据，则处理后的调用链和分开分裂时间的好方法。这是RedGate ANTS确实做得很好的事情，但如果它在现场生产系统上执行，那么可能不是那么好，因为开销太大。
感谢您关注@Richard。我认为你关于衡量子元素累积时间的观点是有效的，但是在宏观计划中，它比无统计数据（目前的现状）要好得多。如果是这种情况，您可以在Sitecore内置的调试/追踪视图上将其准确映射出来。 – theyetiman 2013-05-10 09:29:22
同意。我们使用ANTS。也许配置中打开/关闭机制是有道理的。我可能会与Sc开发者讨论这个问题，尝试在路线图上找到它。 – 2013-05-11 21:08:42
我现在正在做类似的练习。我注意到，我的一些ascx报告avg项目，而有些不。您是否尝试过运行调试并查看配置文件/跟踪的时间。我注意到一些差异。 – 2013-05-09 12:23:12
@WesleyLomax是的，我确切地知道你的意思。我认为显示avg项目的.ascx文件是包含XSLT作为子渲染的文件。换句话说，平均项目计数是针对XSLT的，而不是** ascx本身。在sitecore中运行调试给了我与统计页面类似的结果 - 0 - 10ms生成时间和0项。这真的很烦人。 – theyetiman 2013-05-09 14:45:05
XSLT在Sitecore开发人员社区中了解甚少。话虽如此，我肯定发现渲染统计不一定准确。 – 2013-05-09 19:29:35