網(wǎng)站性能越來越差怎么辦
新的一年，你的老板或客戶，是否曾和你抱怨公司的網(wǎng)站性能愈來愈差？網(wǎng)站大家都會(huì)寫，自從有了Visual Studio 之后，連你家樓下的正妹小喵和隔壁的王大嬸都會(huì)寫 ASP.NET。但同樣的一個(gè)畫面，背后的性能卻可能是天差地遠(yuǎn)，更惶論多人同時(shí)上線的企業(yè)網(wǎng)站，而程序員的身價(jià)也因此有所差別。本篇提供一些改善網(wǎng)站性能的點(diǎn)子，從硬件、軟件、程序技巧的層面都有，也歡迎大家分享自己的經(jīng)驗(yàn)或秘技。
1、重新調(diào)整或重新設(shè)計(jì)DB schema、索引 (index)
一個(gè)在線系統(tǒng)的性能不佳，主要原因都是來自于數(shù)據(jù)庫(kù)規(guī)劃及 SQL 語句層面，至于 .NET 程序撰寫不良都還在其次。
先將數(shù)據(jù)庫(kù)適度地做正規(guī)化，如：一個(gè) Table 中，避免把常用的字段、很少用的字段，都塞在同一個(gè)表中，而影響數(shù)據(jù)掃描的速度。
應(yīng)該將很少用的字段，另切割出來成為另一個(gè)表。
2、改寫 SQL 語句，注意 index 是否在查詢時(shí)有真的被用到
同樣的功能，一個(gè)不良的「關(guān)聯(lián)子查詢」和良好的「獨(dú)立子查詢」，之間的 SQL 性能差距，是不到一秒鐘和好幾分鐘以上的差距。
一些 SQL 關(guān)鍵詞，只要一出現(xiàn)在SQL 語句中，就可能造成表的「索引 (index)」完全失效或部分失效，變成要整個(gè)表去逐行逐列地掃描，
例如: NOT、NOT IN、!=、<>、OR ...等關(guān)鍵詞。
還有「LIKE '%關(guān)鍵詞'」的模糊查詢，也會(huì)造成索引失效，但「LIKE '關(guān)鍵詞%'」就不會(huì)造成索引失效。
3、使用 Native 的 DataProvider
放棄 OleDb，改用 ADO.NET Native 的 DataProvider，如: SqlClient、OracleClient。但若您公司堅(jiān)持要用 Sybase 這種從 2003 年之后，就不曾更新 DB driver 的數(shù)據(jù)庫(kù)，就只好繼續(xù)用性能不佳的 OleDb 去聯(lián)機(jī)了。
據(jù)版工我用 Visual Studio 內(nèi)建的 stress test 工具，測(cè)試 OleDb 和 SqlClient 的性能差距，模擬 30 人同時(shí)上線，用瀏覽器擷取一萬筆數(shù)據(jù)，兩者的速度就差了一秒鐘;且當(dāng)數(shù)據(jù)庫(kù)的數(shù)據(jù)越多，或越多人同時(shí)上線時(shí)，性能差距會(huì)更明顯。
4、用程序或軟件做緩存
用程序做緩存，如 ASP.NET 從 1.x 時(shí)代，就已內(nèi)建的 Cache (緩存) 機(jī)制，或用一些第三方的輔助軟件、Framework。
5、用硬件做快取或緩沖、砸錢加裝 AP Server
以下是網(wǎng)友提供的兩個(gè)實(shí)例：
（1）ITHome - 游戲基地網(wǎng)頁效能提升的關(guān)鍵人物
以下引用自原文:
種種缺失使得網(wǎng)站的使用人數(shù)銳減。面對(duì)網(wǎng)站一堆問題，陳xx也決定要將網(wǎng)站再次大幅度調(diào)整，將之前的網(wǎng)頁程序，以及 SQL 查詢語句全部重寫，他們花了三個(gè)月的時(shí)間執(zhí)行。
陳xx還在原本的網(wǎng)頁服務(wù)器，與數(shù)據(jù)庫(kù)服務(wù)器的架構(gòu)中，加入一組應(yīng)用程序服務(wù)器，作為網(wǎng)頁服務(wù)器 cache 數(shù)據(jù)的來源。
改版之后的新網(wǎng)站，搜尋速度提升許多，先前每日的統(tǒng)計(jì)數(shù)據(jù)中，處理速度超過 3 秒的數(shù)據(jù)超過 50 萬筆;而改版后，每星期超過 3 秒的查詢不到 10 筆，而這少數(shù)反應(yīng)速度不夠快的查詢，也多是內(nèi)部作業(yè)執(zhí)行大量批處理導(dǎo)致的。
由于原本使用的 L4 Switch 較為老舊，負(fù)載量比較差，因此陳xx選擇將它汰換新的設(shè)備，加強(qiáng)負(fù)載量;恰好那時(shí)正好準(zhǔn)備將應(yīng)用服務(wù)器的架構(gòu)上線，就藉此機(jī)會(huì)將網(wǎng)絡(luò)架構(gòu)更新。陳xx說，這樣的架構(gòu)搭配負(fù)載較強(qiáng)的 L4 交換器，強(qiáng)化網(wǎng)站的處理性能，并憑借此抵御網(wǎng)絡(luò)攻擊。在此之后，網(wǎng)站依然會(huì)受到零星攻擊，但都不會(huì)對(duì)造成太大影響。
（2）數(shù)字之墻 - 網(wǎng)站外銷的個(gè)人實(shí)踐(二)運(yùn)營(yíng)
以下引用自原文:
全盛時(shí)期，來自美國(guó) blog 的流量每天達(dá) 80 萬次。這個(gè)數(shù)字其實(shí)不高，對(duì)程序高手來說是小菜一碟，但筆者是半吊子工程師，知識(shí)有限也因此可能程序?qū)懙貌缓茫l頻被主機(jī)供貨商發(fā)信警告，要求改善網(wǎng)站系統(tǒng)性能。最后，我決定開發(fā) cache system。
cache system 緩存系統(tǒng)上線后，將數(shù)據(jù)庫(kù)讀寫，從每天 80 萬次降低到每天 16 萬次。這期間也請(qǐng)高手朋友幫忙進(jìn)行數(shù)據(jù)庫(kù)結(jié)構(gòu)優(yōu)化，幫助很大。筆者在過程中學(xué)習(xí)到，一個(gè)良好的「緩存系統(tǒng) (cache system)」對(duì)于提供 Widget 功能的網(wǎng)站來說非常重要。
能夠做到隨時(shí)搬遷整個(gè)網(wǎng)站到另一家主機(jī)供貨商，除了程序本身的調(diào)整外，還要?dú)w功于網(wǎng)站管理軟件的盛行。在此要推薦的一套稱為 Plesk 的網(wǎng)站管理軟件。有的主機(jī)供貨商會(huì)直接幫你安裝 Plesk ，免費(fèi)或另外付費(fèi)。 Plesk 的所有管理功能都是透過 Web 界面，方便到無以復(fù)加，大大降低對(duì)技術(shù)能力的要求。
除了 Plesk 以外，網(wǎng)站管理軟件還有其它選擇。還有 WHM 加上 cPanel 的組合，也是常見的網(wǎng)站管理解決方案。不過筆者還是比較偏好使用 Plesk，畢竟使用起來容易，也難怪他們的市場(chǎng)占有率一直是獨(dú)大。只是，功力高的工程師可能會(huì)喜歡 WHM + cPanel，因?yàn)閺椥员容^大。不論選擇哪一種，都可以幫助你節(jié)省許多時(shí)間。
6、加裝實(shí)體機(jī)器做 Loading Balance (負(fù)載平衡)。一些 Server OS 亦內(nèi)建此類設(shè)定功能。
7、 程序技巧 - ADO.NET
能用 DataReader 就不要用 DataSet / DataTable，前者讀取速度快又不耗內(nèi)存;后者雖較有彈性，但速度較慢又會(huì)每個(gè)使用者消耗許多內(nèi)存。若您連 DropDownList 控件的數(shù)據(jù)來源，都用 SqlDataSource 控件的默認(rèn)值 - DataSet，則當(dāng)頁面里塞了一堆下拉選單時(shí)，性能當(dāng)然會(huì)受影響。
但前提是程序員對(duì) ADO.NET 要有一定程度的了解，若只會(huì)用 Visual Studio 透過圖形界面，拖拉 TableAdapter、DataTable、.xsd 就免談了。
若為 DataTable 建立 Primary Key，DataTable 會(huì)建立一個(gè)索引，追蹤新增到 DataTable 中的數(shù)據(jù)是否符合此條件約束 (constraint)。ADO.NET 2.0 會(huì)使用 algorithm 的「紅黑樹算法 (Red-Black Tree，是一種「平衡樹」算法) 去處理索引，讓 DataTable 的數(shù)據(jù)量大時(shí)，較方便維護(hù)索引;但缺點(diǎn)是建立索引時(shí)會(huì)降低一些性能。
此外，數(shù)據(jù)庫(kù)的訪問和撈值，應(yīng)該盡量在一次 DB connection 做完，一個(gè) connection 可搭配多個(gè) DbCommand 對(duì)象使用，不用每次都一個(gè) DbConnection 配一個(gè) DbCommand。
在此推薦一本不錯(cuò)的 ADO.NET 原文書:
Programming Microsoft ADO.NET 2.0 Core Reference:
http://www.amazon.com/Programming-Microsoft%C2%AE-ADO-NET-Core-Reference/dp/073562206X/ref=sr_1_1?ie=UTF8&s=books&qid=1230971264&sr=1-1
有探討許多市面上書籍少見的深入內(nèi)容，像 Oracle + ADO.NET 的各種應(yīng)用、Connection Pooling 的特性、各種的數(shù)據(jù)庫(kù) Balk (批次) 作業(yè)應(yīng)用。
8、程序技巧 - .NET 語法
避免一些書上教的，把 DataTable 或大量數(shù)據(jù)，直接塞進(jìn) Session 里，此舉在真正要上線的系統(tǒng)必死無疑。Session 在多人同時(shí)上線時(shí)，內(nèi)存的消耗是很可觀的，因?yàn)?Session 是每個(gè)用戶各存一份在服務(wù)器的內(nèi)存里，而非像「緩存 (cache)」是所有的用戶共享服務(wù)器的一塊內(nèi)存。在很多 ASP.NET 的需求中，可用 HiddenField 控件或 ViewState 取代 Session。
能用「泛型 (Generics)」就不要用舊版的寫法，Generics 除了安全外，亦可避免 .NET 類型在 Boxing / Unboxing 轉(zhuǎn)型時(shí)影響性能，例如:
能用 List
在大多數(shù)的情況下，List、Dictionary 等泛型類，擁有較佳的效率，而且是類型安全的。
當(dāng)然上述前提，是系統(tǒng)要用 .NET 開發(fā)，還在靠 ASP 或非 OOP 語言硬撐的舊系統(tǒng)就免談了。
9、 程序技巧 - 數(shù)據(jù)庫(kù)「事務(wù) (Transaction)」
您是否知道 SQL Server 的默認(rèn)「事務(wù)隔離等級(jí) (Isolation Level)」，是「ReadCommitted」，當(dāng)您在寫 ADO.NET 用了 SqlTransaction 時(shí)，默認(rèn)是當(dāng)某個(gè)人在修改某一筆記錄時(shí)，其它所有讀取這一筆記錄的人，都會(huì)被「鎖定 (lock)」住，造成其它全部用戶的瀏覽器都在等待中，無法做其它工作。
而 Oracle 事務(wù)的特性，是絕不會(huì)有類似無法讀取的情形，至少會(huì)用類似 SQL Server 2005 新增的「快照隔離 (Snapshot Isolation)」，讓用戶至少能先讀取到未 Commit 或 Rollback 的記錄，而不用呆坐在瀏覽器前面傻等。
不過 SQL Server 2005 的「快照隔離」默認(rèn)未啟用。用 SQL Server 開發(fā)的系統(tǒng)，若怕用戶被鎖定的問題，可視 project 需求，改用最寬松的「ReadUncommitted」事務(wù)隔離等級(jí)，其特性為不會(huì)造成任何鎖定，但可能會(huì)造成 Dirty Read。SQL Server 有下列七種「事務(wù)隔離等級(jí)」，有興趣的網(wǎng)友可去查詢 ADO.NET 書籍或 MSDN Library:
Chaos
ReadCommitted // SQL Server 默認(rèn)值
ReadUncommitted // 最寬松，會(huì)有 Dirty Read
RepeatableRead
Serializable // 最嚴(yán)，會(huì)有大量的鎖定
Snapshot
Unspecified
10、ASP.NET 分頁
GridView + SqlDataSource 的默認(rèn)行為，就是每次換頁或排序時(shí)，不管數(shù)據(jù)庫(kù)有幾筆記錄都全部重?fù)埔淮?當(dāng)數(shù)據(jù)庫(kù)有一百萬筆數(shù)據(jù)，就在每個(gè)用戶換頁時(shí)，都一百萬筆全部重?fù)瞥鰜恚伺e消耗了大量的 Web server/ AP server 內(nèi)存、數(shù)據(jù)庫(kù)系統(tǒng)資源、網(wǎng)絡(luò)頻寬，結(jié)果網(wǎng)站性能可想而知。
很多企業(yè)內(nèi)的小型網(wǎng)站，為了省錢，隨便外包給低價(jià)搶標(biāo)的工作室，或沒經(jīng)驗(yàn)的學(xué)生和 SOHO 族，可能因此埋下了恐怖的后遺癥。最可怕的是這些未爆彈，在開發(fā)期間和系統(tǒng)剛上線、數(shù)據(jù)量還很少時(shí)，都感覺不出來，有如癌癥一樣，會(huì)在將來忽然爆發(fā)。
11、ASP.NET AJAX 的 UpdatePanel 控件不是萬能的
以下引用自 MSDN Magazine:
不論好壞，UpdatePanel 控件都是 ASP.NET AJAX 社區(qū)所喜愛的。我說“好”，是因?yàn)?UpdatePanel 使部分頁面呈現(xiàn)變得相當(dāng)簡(jiǎn)單，而說“壞”，是因?yàn)樗暮?jiǎn)便和易用性是以效率和令人啼笑皆非的帶寬為代價(jià)的。
UpdatePanel 可以為一般的網(wǎng)頁帶來 AJAX 神奇的好處，但是它不能提供我們與 AJAX 正常關(guān)聯(lián)的高效性。例如，您是否知道，當(dāng) UpdatePanel 控件對(duì)服務(wù)器執(zhí)行異步 AJAX 回調(diào)以更新其內(nèi)容時(shí)，這個(gè)請(qǐng)求包含了常規(guī) ASP.NET 回發(fā)所包含的一切，其中還包括 ViewState 呢?具有太多 ViewState 的頁面會(huì)降低性能，并且具有太多 ViewState 的頁面在 ASP.NET 應(yīng)用程序中都太常見。
如果您準(zhǔn)備使用 UpdatePanel 控件，您需要清楚您在準(zhǔn)備干什么。在許多情況下，從性能的角度而言，應(yīng)用程序最好是不使用 UpdatePanel，而是使用對(duì) WebMethods 或頁面方法的異步調(diào)用。
當(dāng)您使用 UpdatePanel 在一個(gè)頁面上執(zhí)行無閃爍更新時(shí)，您可能會(huì)認(rèn)為您在進(jìn)行高效構(gòu)建。畢竟，UpdatePanel 使用的是 AJAX，不是嗎?不幸的是，如果您在 UpdatePanel 更新時(shí)檢驗(yàn)一下網(wǎng)絡(luò)中的通信，您會(huì)發(fā)現(xiàn)您根本就沒有保存什么東西，至少是在發(fā)送的時(shí)候沒有保存。通常在回發(fā)期間傳送到服務(wù)器的 ViewState 數(shù)據(jù)(與其他數(shù)據(jù))也會(huì)在 UpdatePanel 回調(diào)期間傳送。事實(shí)上，來自 UpdatePanel 的異步 XML-HTTP 請(qǐng)求中所增長(zhǎng)的數(shù)據(jù)，幾乎與在標(biāo)準(zhǔn) ASP .NET 回發(fā)中增長(zhǎng)的數(shù)據(jù)相同。下面是有關(guān) ASP.NET AJAX 不可告人的秘密：UpdatePanel 雖易于使用，但是通信效率不高。
幾乎沒有什么辦法可讓您提高 UpdatePanel 的效率，但是您可以放棄使用 UpdatePanel，并轉(zhuǎn)而使用 ASP.NET AJAX 的其他功能來更新頁面內(nèi)容，它不僅同樣流暢，而且更加高效。它只需要多一點(diǎn)點(diǎn)力氣，但是最后的結(jié)果往往讓人覺得是值得付出的，因?yàn)槟梢源蟠蠼档驮诳蛻舳伺c服務(wù)器之間傳輸?shù)臄?shù)據(jù)量。
12、Design Patterns
雖然「設(shè)計(jì)模式」不是為解決性能問題而誕生的，但可適度防止沒經(jīng)驗(yàn)的新人做出蠢事。多學(xué)一些 .NET 技術(shù)敵營(yíng)注重的系統(tǒng)架構(gòu)、OOAD、Design Patterns 和相關(guān)的 Framework，對(duì)提升自己的身價(jià)和薪資也有幫助。
以上都是筆者的一些個(gè)人經(jīng)驗(yàn)和見解，感謝各位的閱讀，也歡迎大家分享自己的經(jīng)驗(yàn)或秘技。
【編輯推薦】
