ASP.NET頁面優化,性能提升8倍的方法


今天與大家分享:一種優化頁面執行速度的方法。
采用這個方法,可以使用頁面的執行速度獲得【8倍】的提升效果。

為了讓您對優化的效果有個直觀的了解,我准備了下面的測試結果截圖:

測試環境:
1. Windows Server 2003 SP2
2. Viaual Studio 2008,使用自帶的WebDev.WebServer.EXE運行網站程序。
3. (ThinkPad SL510):Core2 T6670 2.2GHz, 4G內存

二個紅框中的數字反映了優化前后的執行時間。
數字表明:優化前后,執行時間有了8倍多的差別。

本文的測試結果也僅僅只是一個參考數字,這個結果也只是根據我所設計的測試頁面得出的。
優化的過程中,如果不使用服務器控件,那么給GC減少的壓力其實也是無法測試到的。
在測試過程中,我還發現測試結果並不是很穩定,因此截圖具有一定的偶然性。
測試頁面或許在某些方面存在一些片面性,因此,結果僅供參考。

測試背景

看過了優化結果,再來介紹一下:這個測試到底是在測試什么東西?

現在有很多做ASP.NET的開發人員,應該都是從ASP.NET的WebForm編程模型開始學習的。 大家都很喜歡用服務器控件,不管輸出什么,都會使用服務器控件。 有時候為了讓頁面呈現干凈的HTML代碼,有些人會選擇使用Repeater,Literal這類簡單的服務器控件。 或許有些人認為:我已不使用GridView這樣強大復雜的控件,頁面執行速度已經很快了。

真是這樣嗎?

今天測試的起點就從使用簡單的服務器開始,我會分二次對它做一系列的性能優化。
最終就是上圖中的3個結果,它們反映了二次優化的改進過程。

在繼續介紹之前,有一點我想有必要說明一下:

優化的過程涉及到ASP.NET服務器控件的使用,測試結果也僅僅只是一個參考數字。
如果您認為您的開發工作非常依賴於服務器控件的使用,
那么測試結果對您來說其實是無意義的,請不要在意這個結果。

測試方法

在這次優化過程中,我並沒有設計很復雜的測試頁面,而是一個很簡單的測試頁面,頁面顯示效果如下:

這個頁面其實就是顯示了一堆超鏈接,它們來自於我的博客側邊欄的【推薦排行榜】,總共有20條記錄, 我讓頁面重復5次輸出,也就是生成了100個超鏈接。

測試的數據是這樣獲取的:
我復制了我的博客側邊欄的【推薦排行榜】的那段HTML代碼,保存到一個文件中:

然后,網站在初始化時,從這段HTML代碼提取鏈接地址以及顯示文字,保存到一個BlogInfo的列表中,代碼如下:

public class BlogInfo
{
    public string Title;
    public string Href;
}

public static class XmlDb
{
    public static List<BlogInfo> Blogs { get; private set; }


    public static void LoadBlogs()
    {
        string filePath = Path.Combine(HttpRuntime.AppDomainAppPath, @"App_Data\RecommendList.html");

        XElement html = XElement.Parse(System.IO.File.ReadAllText(filePath));

        Blogs =
            (from a in html.Elements("li").Elements("a")
             select new BlogInfo { Title = a.Value, Href = a.Attribute("href").Value }).ToList();
    }
}

測試時,就把XmlDb.Blogs的內容顯示在網頁中。
我想這個測試還是比較接近於現實開發的。

這里又有一個問題:我如何測試頁面的執行速度?

雖然說創建HttpWebRequest訪問頁面是個很簡單的方法,但我並不打算這樣做。
因為從HttpWebRequest發起調用到獲取結果,這其中除了有頁面的執行時間,還混雜較多的額外調用開銷。 最終,我選擇了在一次HTTP請求中,循環調用Server.Execute來執行頁面,並統計時間的方式。 其實如何選擇測試方法,對於二個測試對象還說,都是公平的。 只是說:盡量減少一些額外的調用開銷,會讓測試結果的差異更大,也更明顯。

說明:為了測試代碼寫起來簡單,我使用了MyMVC框架

測試用例1:WebFromPage.aspx

前面介紹了測試背景以及測試方法。現在就來介紹第1個測試用例,它采用了WebForm編程模型中最經典的寫法。

頁面代碼:

頁面的CodeFile代碼:

測試代碼:

當我測試執行10000次時,耗時:00:00:07.5607229

測試用例2:InlinePage.aspx

與測試用例1不同,測試用例2則完全不使用服務器控件。

頁面代碼:

測試代碼:

當我測試執行10000次時,耗時:00:00:01.2345842

分析優化結果1

測試用例1執行相同次數所花費的時間是測試用例2的6倍,為什么會這樣呢?

為了回答這個問題,我們首先要知道前面二個頁面在執行時,它們是如何運行的。
說到這里,就不得不談ASP.NET的頁面編譯方式了。

ASP.NET的頁面編譯過程是個復雜的操作,其實我們可以不用關心頁面是如何編譯的,
但要知道:頁面編譯后是什么樣的。

為了能直觀地了解頁面編譯后的樣子,我編譯了整個網站,並生成到一個DLL文件中, 然后使用Reflector.exe來分析這個DLL的源代碼。

將網站編譯成一個DLL文件有二個方法:
1. 安裝WebDeployment插件。
2. 使用我的工具:FishAspnetTool。

在編譯網站之后,我就可以知道網站在運行時如何運行頁面了。

測試用例1的頁面,最后被編譯成這樣了:

從這個編譯結果我們可以看出:頁面上的所有文字最后也被包裝到LiteralControl中。
頁面中呈現時,就是循環調用每個控件的Render方法來最終生成HTML結果。

測試用例2的頁面被編譯成這個樣了:

請注意下面這段關鍵的代碼:它們實在太重要了。


private void __BuildControlTree(testpage_inlinepage_aspx __ctrl)
{
   // ....... 
    __ctrl.SetRenderMethodDelegate(new RenderMethod(this.__Render__control1));
}

private void __Render__control1(HtmlTextWriter __w, Control parameterContainer)
{

testpage_inlinepage_aspx與testpage_webfrompage_aspx的編譯結果完全不同。
最大的差別在testpage_inlinepage_aspx有個方法:__Render__control1
在這個方法中,頁面的內容將直接被寫入到HtmlTextWriter對象中。
還有一點我要告訴您:每個Control的輸出最后還是要將自己的顯示代碼寫入到HtmlTextWriter對象中。
因此,從這里就可以明顯地看出testpage_inlinepage_aspx的執行速度要快很多,
因為:
1. 它沒有服務器控件。
2. 不再需要遞歸循環每個控件,每個控件的生命周期的調用開銷也節省了。
3. 不用再創建那些服務器控件對象,GC的壓力會小很多。
4. 輸出方式更高效。

通過前面的分析,您現在明白了為什么二個頁面的執行速度相差6倍了原因了吧。

好像還有一點沒有解釋:__Render__control1如何被調用?

我們都知道:以ASPX頁面為代表的WebForm編程模型在執行時有一個特點:遞歸循環每個控件。
頁面是在Render階段輸出的,頁面的HTML代碼也是在那個階段輸出到HtmlTextWriter對象中的。
可是,testpage_inlinepage_aspx沒有任何控件,那又該如何遞歸呢?

的確,很多書籍以及技術資料都是說:在Render階段會遞歸循環每個控件並調用控件的Render方法。

其實這種說法是不准確的。Control的Render方法在運行時,會調用下面這個方法:

這段代碼中,有個重要的if...else...判斷,簡單說來,就是說要不要調用前面所說的__Render__control1方法。
從代碼可以看出,如果是進入了if語句塊,則不用遞歸循環每個控件並調用控件的Render方法。

那么如何能進入if語句塊呢?
答案是:調用Control.SetRenderMethodDelegate方法。
testpage_inlinepage_aspx的編譯生成代碼中就有這個調用。
對於這個方法,MSDN的解釋很含糊:

此 API 支持 .NET Framework 基礎結構,不適合在代碼中直接使用。

分配事件處理程序委托,以將服務器控件及其內容呈現到父控件中。

測試用例3:InlineUserControl.ascx

在測試用例3中,我將頁面中用於輸出的代碼移到一個用戶控件中。
用戶控件的代碼此處省略,與測試用例2的代碼基本上一致。編譯后的結果也基本差不多。

測試代碼:

當我測試執行10000次時,耗時:00:00:00.9132738

又快了一點。

說明:為了這次的性能優化,MyMVC框架也做了一點調整。如果您以前下載過這個框架,請重新下載。

分析優化結果2

經過前面的分析,我們知道:不創建服務器控件對象以及不調用它們的生命周期,可以讓頁面的執行速度快很多。

有沒有再想像一下:頁面也有生命周期啊,而且生命周期的步驟更長,省略它,會不會更快呢?

不過,Render方法並不是個public方法,我們還不能直接調用,但可以調用RenderControl方法來實現這一過程。

由於跳過頁面的生命周期,任何服務器控件都不能使用了,包括母板頁。所以我選擇將前面測試用的那段代碼移到用戶控件中, 然后將用戶控件加載到Page中來測試。

測試用例3與測試用例2相比,在測試過程中,由於跳過了頁面的生命周期,因此速度也就更快了。
注意:事實上,動態加載用戶控件也會有一定的調用開銷。這種方法也僅供參考,可以根據實際情況來選擇。

嗯,基本上,就是這個簡單的原因吧。

由於這種方法沒有任何的控件生命周期,因此速度是最快的。

經過這一系列的優化,頁面的執行時間最終由 00:00:07.5607229 減少到 00:00:00.9132738

再次申明:測試結果也僅僅只是一個參考數字。
事實上,使用服務器控件產生的對象涉及到GC的回收以及內存占用的影響也是不可忽視的。

點擊此處下載示例代碼


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM