網站性能越來越差怎麼辦

    新的一年你的老板或客戶是否曾和你抱怨公司的網站性能愈來愈差？網站大家都會寫自從有了 Visual Studio 之後連你家樓下的正妹小喵和隔壁的王大嬸都會寫 ASPNET但同樣的一個畫面背後的性能卻可能是天差地遠更惶論多人同時上線的企業網站而程序員的身價也因此有所差別本帖提供一些改善網站性能的點子從硬件軟件程序技巧的層面都有也歡迎大家分享自己的經驗或秘技
    （） 重新調整或重新設計 DB schema索引 （index）
    一個在線系統的性能不佳主要原因都是來自於數據庫規劃及 SQL 語句層面至於 NET 程序撰寫不良都還在其次
    先將數據庫適度地做正規化如一個 Table 中避免把常用的字段很少用的字段都塞在同一個表中而影響數據掃描的速度
    應該將很少用的字段另切割出來成為另一個表
   
    （） 改寫 SQL 語句注意 index 是否在查詢時有真的被用到
    * 同樣的功能一個不良的「關聯子查詢」和良好的「獨立子查詢」之間的 SQL 性能差距是不到一秒鐘和好幾分鐘以上的差距
    * 一些 SQL 關鍵詞只要一出現在 SQL 語句中就可能造成表的「索引 （index）」完全失效或部分失效變成要整個表去逐行逐列地掃描
    例如 NOTNOT IN！=<>OR …等關鍵詞
    還有「LIKE %關鍵詞」的模糊查詢也會造成索引失效但「LIKE 關鍵詞%」就不會造成索引失效
   
    （） 使用 Native 的 DataProvider
    放棄 OleDb改用 ADONET Native 的 DataProvider如 SqlClientOracleClient但若您公司堅持要用 Sybase 這種從 年之後就不曾更新 DB driver 的數據庫就只好繼續用性能不佳的 OleDb 去聯機了
    據版工我用 Visual Studio 內建的 stress test 工具測試 OleDb 和 SqlClient 的性能差距模擬 人同時上線用浏覽器撷取一萬筆數據兩者的速度就差了一秒鐘且當數據庫的數據越多或越多人同時上線時性能差距會更明顯
   
    （） 用程序或軟件做緩存
    用程序做緩存如 ASPNET 從 x 時代就已內建的 Cache （緩存） 機制或用一些第三方的輔助軟件Framework這方面若有其它網友知道好用的軟件亦懇請留言告知
   
    （） 用硬件做快取或緩沖砸錢加裝 AP Server
    ITHome 游戲基地網頁效能提升的關鍵人物
    以下引用自原文
    種種缺失使得網站的使用人數銳減面對網站一堆問題陳xx也決定要將網站再次大幅度調整將之前的網頁程序以及 SQL 查詢語句全部重寫他們花了三個月的時間執行
    陳xx還在原本的網頁服務器與數據庫服務器的架構中加入一組應用程序服務器作為網頁服務器 cache 數據的來源
    改版之後的新網站搜尋速度提升許多先前每日的統計數據中處理速度超過 秒的數據超過 萬筆而改版後每星期超過 秒的查詢不到 筆而這少數反應速度不夠快的查詢也多是內部作業執行大量批處理導致的
    由於原本使用的 L Switch 較為老舊負載量比較差因此陳xx選擇將它汰換新的設備加強負載量恰好那時正好准備將應用服務器的架構上線就藉此機會將網絡架構更新陳xx說這樣的架構搭配負載較強的 L 交換器強化網站的處理性能並憑借此抵御網絡攻擊在此之後網站依然會受到零星攻擊但都不會對造成太大影響
   

    （） 用硬件做快取或緩沖砸錢加裝 AP Server
    數字之牆 網站外銷的個人實踐（二）運營
    以下引用自原文
    全盛時期來自美國 blog 的流量每天達 萬次這個數字其實不高對程序高手來說是小菜一碟但筆者是半吊子工程師知識有限也因此可能程序寫得不好頻頻被主機供貨商發信警告要求改善網站系統性能最後我決定開發 cache system
    cache system 緩存系統上線後將數據庫讀寫從每天 萬次降低到每天 萬次這期間也請高手朋友幫忙進行數據庫結構優化幫助很大筆者在過程中學習到一個良好的「緩存系統 （cache system）」對於提供 Widget 功能的網站來說非常重要
    …中間略…
    能夠做到隨時搬遷整個網站到另一家主機供貨商除了程序本身的調整外還要歸功於網站管理軟件的盛行在此要推薦的一套稱為 Plesk 的網站管理軟件有的主機供貨商會直接幫你安裝 Plesk 免費或另外付費 Plesk 的所有管理功能都是透過 Web 界面方便到無以復加大大降低對技術能力的要求
    除了 Plesk 以外網站管理軟件還有其它選擇還有 WHM 加上 cPanel 的組合也是常見的網站管理解決方案不過筆者還是比較偏好使用 Plesk畢竟使用起來容易也難怪他們的市場占有率一直是獨大只是功力高的工程師可能會喜歡 WHM + cPanel因為彈性比較大不論選擇哪一種都可以幫助你節省許多時間
   
    （） 加裝實體機器做 Loading Balance （負載平衡）一些 Server OS 亦內建此類設定功能
   
    （） 程序技巧 ADONET
    能用 DataReader 就不要用 DataSet / DataTable前者讀取速度快又不耗內存後者雖較有彈性但速度較慢又會每個使用者消耗許多內存若您連 DropDownList 控件的數據來源都用 SqlDataSource 控件的默認值 DataSet則當頁面裡塞了一堆下拉選單時性能當然會受影響
    但前提是程序員對 ADONET 要有一定程度的了解若只會用 Visual Studio 透過圖形界面拖拉 TableAdapterDataTablexsd 就免談了
    若為 DataTable 建立 Primary KeyDataTable 會建立一個索引追蹤新增到 DataTable 中的數據是否符合此條件約束 （constraint）ADONET 會使用 algorithm 的「紅黑樹算法 （RedBlack Tree是一種「平衡樹」算法） 去處理索引讓 DataTable 的數據量大時較方便維護索引但缺點是建立索引時會降低一些性能
    此外數據庫的訪問和撈值應該盡量在一次 DB connection 做完一個 connection 可搭配多個 DbCommand 對象使用不用每次都一個 DbConnection 配一個 DbCommand
   
    （） 程序技巧 NET 語法
    * 避免一些書上教的把 DataTable 或大量數據直接塞進 Session 裡此舉在真正要上線的系統必死無疑Session 在多人同時上線時內存的消耗是很可觀的因為 Session 是每個用戶各存一份在服務器的內存裡而非像「緩存 （cache）」是所有的用戶共享服務器的一塊內存在很多 ASPNET 的需求中可用 HiddenField 控件或  ViewState 取代 Session
    * 能用「泛型 （Generics）」就不要用舊版的寫法Generics 除了安全外亦可避免 NET 類型在 Boxing / Unboxing 轉型時影響性能例如
    能用 List<string> 就不要用舊的 ArrayList能用 Dictionary<TKeyTValue> 就不要用 Hashtable 或跑雙層的循環 （loop）因 ArrayListHashtable 的 element 屬於 object 類在存儲或檢索如 int 等「值類型 （Value Type）」時會引發 Boxing / Unboxing
    在大多數的情況下ListDictionary 等泛型類擁有較佳的效率而且是類型安全的
    當然上述前提是系統要用 NET 開發還在靠 ASP 或非 OOP 語言硬撐的舊系統就免談了
   
    （） 程序技巧 數據庫「事務 （Transaction）」
    您是否知道 SQL Server 的默認「事務隔離等級 （Isolation Level）」是「ReadCommitted」當您在寫 ADONET 用了 SqlTransaction 時默認是當某個人在修改某一筆記錄時其它所有讀取這一筆記錄的人都會被「鎖定 （lock）」住造成其它全部用戶的浏覽器都在等待中無法做其它工作
    而 Oracle 事務的特性是絕不會有類似無法讀取的情形至少會用類似 SQL Server 新增的「快照隔離 （Snapshot Isolation）」讓用戶至少能先讀取到未 Commit 或 Rollback 的記錄而不用呆坐在浏覽器前面傻等
    不過 SQL Server 的「快照隔離」默認未啟用用 SQL Server 開發的系統若怕用戶被鎖定的問題可視 project 需求改用最寬松的「ReadUncommitted」事務隔離等級其特性為不會造成任何鎖定但可能會造成 Dirty ReadSQL Server 有下列七種「事務隔離等級」有興趣的網友可去查詢 ADONET 書籍或 MSDN Library:
    Chaos
    ReadCommitted　　// SQL Server 默認值
    ReadUncommitted　// 最寬松會有 Dirty Read
    RepeatableRead
    Serializable　　　　// 最嚴會有大量的鎖定
    Snapshot
    Unspecified
   
    （） ASPNET 分頁
    GridView + SqlDataSource 的默認行為就是每次換頁或排序時不管數據庫有幾筆記錄都全部重撈一次當數據庫有一百萬筆數據就在每個用戶換頁時都一百萬筆全部重撈出來此舉消耗了大量的 Web server/ AP server 內存數據庫系統資源網絡頻寬結果網站性能可想而知
    很多企業內的小型網站為了省錢隨便外包給低價搶標的工作室或沒經驗的學生和 SOHO 族可能因此埋下了恐怖的後遺症最可怕的是這些未爆彈在開發期間和系統剛上線數據量還很少時都感覺不出來有如癌症一樣會在將來忽然爆發
   
    （） ASPNET AJAX 的 UpdatePanel 控件不是萬能的
    以下引用自 MSDN Magazine:
    不論好壞UpdatePanel 控件都是 ASPNET AJAX 社區所喜愛的我說好是因為 UpdatePanel 使部分頁面呈現變得相當簡單而說壞是因為它的簡便和易用性是以效率和令人啼笑皆非的帶寬為代價的
    UpdatePanel 可以為一般的網頁帶來 AJAX 神奇的好處但是它不能提供我們與 AJAX 正常關聯的高效性例如您是否知道當 UpdatePanel 控件對服務器執行異步 AJAX 回調以更新其內容時這個請求包含了常規 ASPNET 回發所包含的一切其中還包括 ViewState 呢？具有太多 ViewState 的頁面會降低性能並且具有太多 ViewState 的頁面在 ASPNET 應用程序中都太常見
    如果您准備使用 UpdatePanel 控件您需要清楚您在准備干什麼在許多情況下從性能的角度而言應用程序最好是不使用 UpdatePanel而是使用對 WebMethods 或頁面方法的異步調用
    …中間略…
    當您使用 UpdatePanel 在一個頁面上執行無閃爍更新時您可能會認為您在進行高效構建畢竟UpdatePanel 使用的是 AJAX不是嗎？不幸的是如果您在 UpdatePanel 更新時檢驗一下網絡中的通信您會發現您根本就沒有保存什麼東西至少是在發送的時候沒有保存通常在回發期間傳送到服務器的 ViewState 數據（與其他數據）也會在 UpdatePanel 回調期間傳送事實上來自 UpdatePanel 的異步 XMLHTTP 請求中所增長的數據幾乎與在標准 ASP NET 回發中增長的數據相同下面是有關 ASPNET AJAX 不可告人的秘密UpdatePanel 雖易於使用但是通信效率不高
    幾乎沒有什麼辦法可讓您提高 UpdatePanel 的效率但是您可以放棄使用 UpdatePanel並轉而使用 ASPNET AJAX 的其他功能來更新頁面內容它不僅同樣流暢而且更加高效它只需要多一點點力氣但是最後的結果往往讓人覺得是值得付出的因為您可以大大降低在客戶端與服務器之間傳輸的數據量
   
    （） Design Patterns
    雖然「設計模式」不是為解決性能問題而誕生的但可適度防止沒經驗的新人做出蠢事多學一些 NET 技術敵營注重的系統架構OOADDesign Patterns 和相關的 Framework對提升自己的身價和薪資也有幫助
    本文來自CSDN博客轉載請標明出處

From:http://tw.wingwit.com/Article/program/net/201311/13555.html