ASP.NET頁面性能

Question

我們有一個相當複雜的頁面，可以動態加載用戶控件（其中一些嵌套）。這是一個表現非常慢的頁面。

動態添加控件是否會增加瓶頸？如果我們在.NET緩存對象中添加控件，並且在緩存中已經存在的情況下不使用LoadControl，它會有幫助嗎？

任何其他提示/策略使頁面更快？

Answer 1

爲您的@Page指令添加Trace =「true」，您將能夠看到哪些方法花費的時間最長。

Answer 2

我懷疑它的動態加載控件的行爲是減慢它和更多的每個控件的行爲。他們全都碰到數據庫嗎？我會看看你是否可以在試圖優化它們的加載之前簡化控件的性能（緩存數據庫調用等）。

Answer 3

我們曾經將ASP.Net項目的性能提高了一個數量級。以下是我們嘗試的一些列表：

• 儘可能將SessionState設置爲false或ReadOnly。請注意，ASPages，Web服務和應用程序的會話狀態設置方法不同。
• 如果可能，將會話狀態存儲在進程中。
• 儘可能將EnableViewState設置爲false。
• 儘可能使用緩存。
• 如果您不需要從服務器訪問控件，請使用HTML控件而不是服務器端控件。
• 儘可能避免往返（向服務器提交數據並重新加載頁面）。請注意，您只需往返從服務器讀取數據或將數據寫入服務器即可。驗證和反饋可以在客戶端進行。使用Page_Load中的IsPostBack屬性可避免回發時重新生成數據。
• 使用StringBuilder類進行重複連接。
• 使用try/catch塊僅用於意外情況;不要將它們用作一般控制結構。
• 儘可能使用早期綁定。換句話說，避免反思。
• 避免非託管代碼，如COM。
• 禁用運輸應用程序的調試模式。
• 使用存儲過程進行數據庫訪問而不是SQL字符串。
• 使用DataReader類讀取數據而不是數據集。
• 儘可能使用限制性最強的類，如SqlDataReader而不是DbDataReader。

Answer 4

我會在頁面上做一些分析，看看真正的減速發生在哪裏。通常根據我的經驗，我認爲可能導致實際減速的不是最慢的點。當事情開始運行緩慢時，我發現最好能夠剖析我的應用程序/頁面，然後給我非常好的信息，說明哪些區域可以加速獲得戲劇性的改進。你可能會發現數據庫調用太多，或用戶控件加載，或者你沒有考慮過的其他東西。

Answer 5

如果簡單地加載控件動態地產生大的性能成本，我會有點驚訝。但是，如果有很多控件，並且它們深深嵌套，則ASP.NET有時會很慢地將它們呈現爲html。很顯然，按照其他人的建議來確定你的瓶頸究竟在哪裏。

對於一個複雜的頁面來說，檢查呈現的html的大小是一件事。有了許多服務器控件，頁面大小可以快速攀升到幾兆字節。打開或調整http壓縮可能是您正在尋找的答案。

Answer 6

調查性能問題的第一步是確定瓶頸：它是網絡流量（太多的HTTP請求？太多的HTML來自管道？）或CPU綁定在服務器上？或數據庫調用過多？

在許多情況下，頁面的大小會導致速度減慢。如果你在頁面上包含很多控件，那麼會有很多HTML，所以如果你在最終的渲染產品上查看源代碼並找到20000行HTML/javascript，那麼很可能是因爲減速太多數據通過網絡發送。

我建議使用像YSlow這樣的工具來幫助您更好地理解最終呈現的產品。

關鍵項目看：

• 管理視圖狀態的大小
• 製作所隱藏的設置。可見頁面的確定部分=假（而不只是風格=「顯示：無; 「）
• 集中和合並的javascript
• 最小化HTTP請求的數量

Answer 7

裝載用戶控制動態絕對不是性能下降的原因。通常阻礙ASPX頁面性能的一件事就是viewstate。我建議將視圖狀態從頁面中移出[即使您已經在某些控件上啓用了它]。

將完整的viewstate存儲爲服務器上的會話變量，並僅在viewstate字段中傳輸標識符。您可以查看完整的文章here，文章還提供了性能度量指標。

Answer 8

網頁的緩慢表現有很多原因。你真的需要使用一些像性能嚮導這樣的工具來開始瞭解正在發生的事情。

我們最新的性能問題歸結爲匿名類型和linq。由於所有的JIT編譯都在進行，所以用這兩件事情來殺死性能是非常容易的。