2009-07-08 84 views
9

我很困惑。我查看了按照我的老闆加載「緩慢」的頁面調用的軌跡,導致頁面部分加載,然後「跳轉」到回發上的記憶滾動位置。是什麼導致頁面渲染緩慢?

我最終發現,使用我的蹤跡,我的整個加載從Begin PreInit到End Render花費了1.94秒,其中1.5個花費在Begin PreRender和End PreRender之間。

任何想法可能會導致什麼?對於End PreRenderComplete,下一個最大的加載時間是0.14秒。

這個問題是否可以源於我對SQL Server的查詢,或者頁面上的控件數量過大,即使大多數都是「隱藏」的?

[編輯]看來,當我展示某種形式時,我的頁面加載時間很長。我的總體渲染大小爲91537字節,其中44483個專用於該特定表單。我的視圖狀態似乎非常巨大。另外:404的JS文件可以導致這種負載滯後?

[update:]所以我找到了運行時間最長的查詢,看起來即使它看起來很笨重,它甚至在頁面被加載之前就已經結束運行了。 作爲補充信息:我使用了相當多的SqlDataSources來控制整個下拉列表和其他有趣的東西。這是混亂我的應用程序?

+0

在閱讀您的更新之後,我仍然認爲您需要在探查器中查看此信息以確定。 – 2009-07-09 12:40:26

回答

6

根據我的經驗(與您的問題相同),這是90%的SQL問題。

在您正在調用的查詢周圍添加一些秒錶,以查明哪些查詢運行緩慢。

渲染asp.net控制不能這麼長時間....

4

爲了找出瓶頸的原因,你真的應該用ANTS Profiler之類的工具來分析你的代碼。

分析器將允許您通過向您顯示哪些代碼行比其他代碼更慢來查明問題區域。

+2

任何我不必花費400美元就可以在此應用程序中找到單個問題?:P – 2009-07-08 12:56:34

+2

我以爲你可以通過下載它來試用螞蟻探查器:)。 同樣,您可以下載Visual Studio試用版,並免費提供VS分析器。 – 2009-07-08 13:01:20

+1

我已經使用了螞蟻探查器以及Visual Studio的性能嚮導的試用版,並發現它們在許多方面具有可比性。 – 2009-07-08 13:03:36

3

我會用YSlow,以確定其是否從客戶端或服務器端的東西。我們有時會將一些定時器添加到某些查詢中,然後輸出時間在html註釋中執行......當然,在測試完成後刪除它們。

頁面調用託管在外部網站上的任何東西嗎?

0

最好的選擇是使用Perfomance Wizard in Visual Studio並查看您的頁面的調用樹。它會給你更多的細節到確切的性能瓶頸。

當頁面上聲明瞭太多複雜的控件時,我已經看到了這種類型的性能。儘管它也很容易與SQL相關。要了解確切的情況,您需要查看Call Tree並查明最昂貴的通話。

0

當然,如果是sql相關的,正如很多人所指出的那樣,「sql server profiler」是使用的工具(假設您運行的是mssql)。 mysql有「jetprofiler」(.com),我還沒有試過。一旦你發現緩慢的查詢,這不是一個索引問題。