Sitecore的sublayout呈現統計信息是否不正確？

內置的Sitecore渲染統計信息http://<sitename>/sitecore/admin/stats.aspx對於識別效率低下且緩慢加載的XSLT渲染真的很有幫助。最近我已經開始切換到.ascx子佈局，以利用Sitecore C＃API，它可以在正確使用時幫助提高性能。Sitecore的sublayout呈現統計信息是否不正確？

不過，我已經注意到，子佈局（而不是XSLT渲染）未在統計頁面上正確的報道。請參閱下面的屏幕截圖....

Example sublayout stats

我知道一個事實，這個子佈局約需1.8秒生成（我在後臺代碼計算此）。緩存已關閉。我已經刷新了該頁面20次，以確保我獲得平均水平。你會看到，「平均項目。」始終是0 - 我可以這樣生活 - 但「平均時間（毫秒）。」是小於1ms這僅僅是明顯錯誤的。

沒有人有任何見解呢？有沒有人找到一種方法讓它正常工作？

來源

2013-05-09 theyetiman

我現在正在做類似的練習。我注意到，我的一些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

來看一個統計值是否正確/錯誤是要依靠理解它到底是什麼測量。

使用反射我注意以下掘Sitecore.Diagnostics.Statistics各地：

Sitecore.Web.UI.Webcontrol包含字段m_timer
這在BeforeRender '開始'（）方法在AfterRender階段（）方法
數據從該定時器被髮送到Statistics.AddRenderingData（和「停止」）和記錄相對於對照

這意味着它是measuri納克採取的時間呈現控制，這對於一個XSLT包括用於在其製備中的所有數據的處理時間，但作爲多正常ASCX的工作之前渲染階段完成的統計量是少得多有用。在時間中加入Load階段將無意中包含所有子組件的處理時間，因爲Load序列是鏈式遞歸調用的，所以可能也沒有多大幫助。

我懷疑有測量處理時間爲特定ASCX控制（不包括兒童），而不第一獲取累積數據，則處理後的調用鏈和分開分裂時間的好方法。這是RedGate ANTS確實做得很好的事情，但如果它在現場生產系統上執行，那麼可能不是那麼好，因爲開銷太大。

來源

2013-05-10 02:41:00

感謝您關注@Richard。我認爲你關於衡量子元素累積時間的觀點是有效的，但是在宏觀計劃中，它比無統計數據（目前的現狀）要好得多。如果是這種情況，您可以在Sitecore內置的調試/追蹤視圖上將其準確映射出來。 – theyetiman 2013-05-10 09:29:22

同意。我們使用ANTS。也許配置中打開/關閉機制是有道理的。我可能會與Sc開發者討論這個問題，嘗試在路線圖上找到它。 – 2013-05-11 21:08:42

Sitecore的sublayout呈現統計信息是否不正確？

回答

相關問題