Asp.Net頁面請求效能大隱患 你是否做了這樣的事情

  項目測試中，客戶向我們反應，某個頁面請求速度特別慢，簡直無法忍受。這裡簡單插一些情況的描述：對於一個使用人數、並行作業並不多的項目，客戶不會過多的在效能上提出要求，對他們來說，多幾百ms的等待時間，不會帶來更多情緒。

    但是，當你請求某個頁面後，去泡杯茶回來，發現頁面還死死的在那裡，進度條不緊不慢的一點一點增長，就無法忍受了。利用Firefox的debug[ debug ?]測了一下，平均請求時間19s左右，而光import那個頁面所需要的時間就是18s多，問題肯定出在頁面上。

    那個頁面是被IFrame包含進來的，包含5個TextBox、4個DropdownList、3個CheckBox、3個Button（作為分頁的查詢條件），下面就是分頁的DataGrid（每頁10條資料）。我注意到其中有一個DropdownList的ListItem有200多項，查了一下Response，發現ViewState黑壓壓一塊。顯然，這也是影響效能的一個原因[一次取一頁資料]。

    在跟客戶商量後，將這個DropdownList改成了TextBox，做成模糊查詢。恩，速度到了15s左右，快了3到4秒。這樣的改善已經是很不錯的成績了，但是我們還要等待15s，顯然無法讓客戶滿意。 [DropDownList 資料項目不要太多]

    這下問題就不明顯了，我禁用了viewstate，發現並沒有多少效果。頁面資料量也不是很大啊，幾個DropdownList的初始化，分頁的實現是利用預存程序，在伺服器資料庫中，利用遊標取記錄條數。傳遞過來，也僅僅是10條而已。

    查看頁面原始碼發現N長的JS，是不是問題出在載入日期控制項上呢？我將日期控制項屏蔽了，再測，問題依舊，還是15s！！

    感覺有點束手了，測試其他頁面，沒有問題，響應速度很理想，甚至是一些控制項N多的頁面。

    不經意間點分頁的“下一頁”，恩，時間很漫長！可是我下一頁的操作，唯讀取了下一個10條資料啊！我在伺服器查詢分析器下測試了預存程序，反應沒問題。那問題應該是出在DataGrid的綁定了，這時候，我注意到，datagird中包含不少模板列，其中有不少LinkButton，涉及到顯示不顯示的邏輯操作，例如：

<asp:TemplateColumn>
        <HeaderStyle Width="50px"></HeaderStyle>                        
        <ItemTemplate>
                <asp:LinkButton id="lbtnEdit1" runat="server" CausesValidation="false" CommandName="Disabled" Visible=''<%# DataBinder. Eval(Container.DataItem, "IsDisable").ToString()=="1"  %>''> <span onclick="return confirm(''確認作廢？'')">作廢</span></asp:LinkButton>                                     
                <asp:LinkButton ID="lbtnEdit2" runat="server" CausesValidation="false" CommandName="Able" Visible=''<%# DataBinder.Eval(Container.DataItem,"IsDisable").ToString()=="2"  %>''><span onclick="return confirm(''確認恢複？'')">恢複</span></asp:LinkButton>                   
                <asp:LinkButton ID="lbtnEdit3" runat="server" CausesValidation="false"-

CommandName="Disabling" Visible=''<%# DataBinder.Eval(Container.DataItem,"IsDisable").ToString()=="0"  %>''><span onclick="return confirm(''確認待報廢？'')">待報廢</span></asp:LinkButton>
        </ItemTemplate>
</asp:TemplateColumn>

    頓時，有了個想法，會不會是觸發ItemDataBind事件，遍曆表格控制項時，消耗系統資源呢？

    將這部分功能屏蔽，果然！效果理想，回應時間到了3s左右，速度差強人意。我暗舒口氣......

    總結：

    viewstate利弊共存，怎麼使用，值得權衡。有時候，沒有辦法，不妨跟客戶溝通一下，變換一些實現方法。

    永遠不要在ItemDataBind時，做太多事情。不妨，將資料處理放在資料庫（視圖、預存程序）、或者是在綁定之前，寫方法處理。

    效能永遠是一個隱形的需求，而我在這方面經驗匱乏。尤其是，目前的項目規模小，那些在code時，留下的揮霍記憶體的變數聲明、佔用CPU的迴圈、遍曆演算法的行為隨處可見。現在，我們能做的，就是在意識到這些後，一點點的改變這些習慣把。

from: http://www.diybl.com/course/4_webprogram/asp.net/asp_netshl/2008313/104552.html